glXMakeCurrent(dpy, None, NULL) would not correctly unbind the context
causing subsequent GLX requests to fail in peculiar ways
http://xquartz.macosforge.org/trac/ticket/514
Signed-off-by: Jeremy Huddleston <jeremyhu@apple.com>
A driver trying to set up builtin uniforms is faced with a problem:
How do I walk the ir_variable structure (representing an array of
structs, or array of matrices, or struct, or whatever), and set up
driver structures so that dereference of that uniform gets the
corresponding ParameterValues[] entry. The rule in general is that
each corresponding vector-sized field of an array of structs is one
builtin uniform state slot. i965 relied on another invariant: each
state slot has a number of unique channel swizzles corresponding to
the number of elements in the field's vector, to avoid needing to walk
the glsl_type in parallel to get at vector_elements.
All of the builtin uniforms followed this behavior, except for
gl_NormalMatrix. That's a mat3 (so 3 vec3s), but it was swizzled as 3
vec4s.
Fixes piglit glsl-fs-normalmatrix.
Reviewed-by: Paul Berry <stereotype441@gmail.com>
This is the new name for gl_MaxVaryingFloats now that non-float
varyings exist. Fixes piglit
glsl-1.30/execution/maximums/gl_MaxVaryingFloats
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
In commit 3e5d3626, Eric added a homebrew workaround to fix GPU hangs in
the Mesa "engine" demo and oglc's api-texcoord test.
Unfortunately, his PIPE_CONTROL contains a Depth Stall, which
necessitates the post-sync non-zero workaround,
Fixes GPU hangs in Civilization 4, PlaneShift, and 3DMMES.
Hopefully Heroes of Newerth as well, though I haven't tested that.
NOTE: This is candidate for the 7.11 branch.
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=40324
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=41096
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-and-tested-by: Eric Anholt <eric@anholt.net>
I had a colleague hitting issues compiling with an old gcc3.2
system. These patches got them through.
NOTE: This is a candidate for the 7.11 branch.
Reviewed-by: Brian Paul <brianp@vmware.com>
Use VRAM for static and immutable buffers. This restores the
recently removed r600g winsys behaviour for memory locations.
This also improoves rendering times on the gpu for some
OpenSceneGraph based test cases by about 15%.
Signed-off-by: Marek Olšák <maraeo@gmail.com>
Make sure we do not run into the classic ABA problem on buffer object bind,
reusing this name and may be never rebind since we get an new name
that was just deleted and never rebound in between.
The explicit rebinding to the debault object in the current context
prevents the above in the current context, but another context
sharing the same objects might suffer from this problem.
Minor var renaming and comments edited by Brian.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Signed-off-by: Brian Paul <brianp@vmware.com>
Buffer objects may be shared across contexts.
Rework the array attrib push/pop implementation
to be thread safe. Make use of more library functions
for this purpose.
Signed-off-by: Mathias Fröhlich <Mathias.Froehlich@web.de>
Reviewed-by: Brian Paul <brianp@vmware.com>
In the past, swrast_texture_image::Data has been overloaded. It could
either point to malloc'd memory storing texture data, or it could point
to a current mapping of GPU memory.
Now, Buffer always points to malloc'd memory (if we're not using GPU
memory) and Data always points to mapped memory. The next step would
be to rename Data -> Map.
This change also involves adding swrast functions for mapping textures
and renderbuffers prior to rendering to setup the Data pointer. Plus,
corresponding functions to unmap texures and renderbuffers. This is
very much like similar code in the dri drivers.
Only swrast and the drivers that fall back to swrast need these fields now.
This removes the last of the fields related to software rendering from
gl_texture_image.
In lp_build_stencil_op() the incoming 'stencil' var is a 2-element array.
There's a front-face writemask and a back-face writemask but we're ignoring
the later. This patch doesn't fix anything but at least points out the
problem.
v2: Avoid the C99 rounding functions, because I don't trust
get/setting the C99 rounding mode from inside our library not having
other side effects. Instead, open-code roundEven() behavior around
Mesa's IROUND, which we're already testing for C99 rounding mode
safety.
Fixes glsl-1.30/compiler/built-in-functions/round*
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
- Fix _GNUC__ typo in both checks
- Fix logic error in check for gcc < 3.4 that breaks for gcc 2.x & older
Without this fix, builds with gcc 3.4.x end up depending on undefined
_mesa_bitcount instead of gcc's __builtin_popcount.
NOTE: This is a candidate for the stable branches.
Signed-off-by: Alan Coopersmith <alan.coopersmith@oracle.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Should fall back to shader based decoding (g3dvl) for now.
This is probably broken on systems that support xvmc, because
nouveau_video_buffer_create has no way to know for what api
the buffer is created, so I think this call might need a
separate argument as workaround.
Signed-off-by: Maarten Lankhorst <m.b.lankhorst@gmail.com>
