From: Mathias Fröhlich
Hi Jose,
This makes llvmpipe thread safe as mandated by the OpenGL standard.
The changes replace the use of two global data structures with
non global ones.
The changes pass piglit as of today without regressions.
The patchset now sticks to your initial suggestion and the
From: Mathias Fröhlich
This is one step to make llvmpipe thread safe as mandated by the OpenGL
standard. Using the global LLVMContext is obviously a problem for
that kind of use pattern. The patch introduces two LLVMContext
instances that are private to an OpenGL context and used for all
compiles
From: Mathias Fröhlich
This fixes the remaining problem with the recently introduced
global jit memory manager. This change again uses a memory manager
that is local to gallivm_state. This implementation still frees
the majority of the memory immediately after compilation.
Only the generated code
Signed-off-by: Matthew Waters
---
src/mapi/glapi/gen/KHR_debug.xml| 73 +
src/mesa/main/extensions.c | 2 +-
src/mesa/main/tests/dispatch_sanity.cpp | 25 +++
3 files changed, 99 insertions(+), 1 deletion(-)
diff --git a/src/mapi/glap
As of version 15 of the EGL_KHR_create_context spec, debug contexts
are allowed for ES contexts. We should allow creation instead of
erroring.
Signed-off-by: Matthew Waters
---
src/egl/main/eglcontext.c | 51 ++
src/mesa/drivers/dri/common/dri_util.c
v3:
- fix up the EGL_CONTEXT_OPENGL_ROBUST_ACCESS_BIT_KHR check
v2:
- replace &= with |=
- remove offset="assign" from the api xml
Matthew Waters (3):
egl: rework handling EGL_CONTEXT_FLAGS for ES debug contexts
glapi: add function pointers for KHR_debug for gles
main/get: make KHR_debug
Although GL_CONTEXT_FLAGS is not explicitly added by KHR_debug,
it contains,
"It is implementation defined how much debug output is generated if
the context was created without the CONTEXT_DEBUG_BIT set. This is a new
query bit added to the existing GL_CONTEXT_FLAGS state to specify wh
If point-releases don't give enough control, lets have Mesa maintain its fork
of LLVM, call it something completely different, like "mesa compiler
toolchain", to make it clear to distribution packagers that this fork of LLVM
has extra GPU goodness and, might not give the expected results for oth
If the ENDIF instruction was the only instruction in its block, we'd
leave the successors of the merged if+jump block in a bad state.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=83080
---
.../drivers/dri/i965/brw_fs_peephole_predicated_break.cpp | 13 +
1 file changed, 9
On 30/08/14 18:43, Jonathan Gray wrote:
> Signed-off-by: Jonathan Gray
Nice stuff, thanks! I'll add a line or two (commit message) and push it shortly.
-Emil
> ---
> src/gallium/state_trackers/xvmc/tests/test_blocks.c | 6 --
> src/gallium/state_trackers/xvmc/tests/test_context.c|
On 31/08/14 01:13, Ilia Mirkin wrote:
> On Sat, Aug 30, 2014 at 8:09 PM, Emil Velikov
> wrote:
>> On 31/08/14 00:34, Ilia Mirkin wrote:
>>> On Sat, Aug 30, 2014 at 7:30 PM, Emil Velikov
>>> wrote:
On 30/08/14 23:02, Ilia Mirkin wrote:
> Samplers are only defined up to num_samplers, so
Despite the comment above the function claiming otherwise, the function
did not reswizzle sources, which would lead to bad code generation.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=82932
---
src/mesa/drivers/dri/i965/brw_vec4.cpp | 32 +++-
src/mesa/drive
Before commit 04895f5c we would only reswizzle dot product instructions
(since they wrote the same value into all channels, and we didn't have
to think about anything else). That commit extended reswizzling to cases
when the swizzle was single valued -- i.e., writing the same result into
all channe
On 30/08/14 05:33, Matt Turner wrote:
> On Fri, Aug 29, 2014 at 4:44 PM, Emil Velikov
> wrote:
>> Hello list,
>>
>> Another boring yet important series, if we are to have properly working
>> solution to package a mesa release tarball via 'make dist'.
>>
>> This series covers a few state-tracker f
Signed-off-by: Glenn Kennard
---
Tested on radeon 6670, all sample shading piglits pass, no
regressions, as well as unigine valley basic, tesseract with
MSAA enabled.
It would be great if one or more people could test this
on pre-evergreen hardware, and cayman, since I don't
have any such hardwar
Mesa 10.3 release candidate 2 is now available for testing. The current
plan of record is to have an additional release candidate each Friday
until the 10.3 release on Friday, September 12th.
The tag in the GIT repository for Mesa 10.3-rc2 is 'mesa-10.3-rc2'. I
have verified that the tag is in t
On 28.08.2014 19:58, Henri Verbeet wrote:
On 28 August 2014 05:21, Michel Dänzer wrote:
Sure, it's not impossible, but is that really the kind of process you
want users to go through when bisecting a regression?
I appreciate your theoretical concern, but in practice, people don't seem to
have
Experimentally, the sampler doesn't appear to like these, neither as
buffer nor as rect textures. So remove 1D from the list of texture types
to make linear when used for staging.
This fixes the OSD in mplayer for VDPAU.
Signed-off-by: Ilia Mirkin
Cc: "10.2 10.3"
---
src/gallium/drivers/nouvea
18 matches
Mail list logo
