It is incorrect to assume that pixel format is always in BGR byte order.
We need to check bitmask parameters (such as |redMask|) to determine whether
the RGB or BGR byte order is requested.
v2: reformat code to stay within 80 character per line limit.
v3: just fix the byte order problem first and investigate SRGB later.
v4: rebased on top of the GLES3 sRGB workaround fix.
v5: rebased on top of the GLES3 sRGB workaround fix v2.
Signed-off-by: Haixia Shi <hshi@chromium.org>
Reviewed-by: Stéphane Marchesin <marcheu@chromium.org>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
This fixes
dEQP-GLES31.functional.uniform_location.negative.atomic_fragment
dEQP-GLES31.functional.uniform_location.negative.atomic_vertex
Both of which have lines like
layout(location = 3, binding = 0, offset = 0) uniform atomic_uint uni0;
The ARB_explicit_uniform_location spec makes a very tangential mention
regarding atomic counters, but location isn't something that makes sense
with them.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Signed-off-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Timothy Arceri <timothy.arceri@collabora.com>
The XMesaVisual instances freed in the visuals table on display close
are being freed with a free() call, instead of XMesaDestroyVisual(),
causing a memory leak.
Signed-off-by: John Sheu <sheu@google.com>
Reviewed-by: Brian Paul <brianp@vmware.com>
GLvoid was used before in OpenGL but it has changed to just using void.
All GLvoids in mesa's state tracker has been changed to void in this patch.
Tested this with piglit and no problems were found. No compiler warnings.
Signed-off-by: Jakob Sinclair <sinclair.jakob@openmailbox.org>
Reviewed-by: Brian Paul <brianp@vmware.com>
Now it follows the compatibility criteria listed in section 2.1 of
the GLX 1.4 specification.
This is needed for post-process effects in SW:KotOR.
Signed-off-by: Miklós Máté <mtmkls@gmail.com>
Signed-off-by: Marek Olšák <marek.olsak@amd.com>
- Check for unused blocks every few frames or every 64K draws
- Delete data unused since the last check if total unused data is > 20MB
Doesn't seem to cause a perf degridation
Acked-by: Brian Paul <brianp@vmware.com>
If the glDrawPixels size changed, we leaked the previously cached
texture, if there was one. This patch fixes the reference counting,
adds a refcount assertion check, and better handles potential malloc()
failures.
Tested with a modified version of the drawpix Mesa demo which changed
the image size for each glDrawPixels call.
Cc: "11.2" <mesa-stable@lists.freedesktop.org>
Reviewed-by: José Fonseca <jfonseca@vmware.com>
Reviewed-by: Charmaine Lee <charmainel@vmware.com>
Guard band clipping speeds up rasterization for primitives that are
partially off-screen. This change in particular results in small
framerate improvements in a wide range of games.
Started by Grigori Goronzy <greg@chown.ath.cx>.
Reviewed-by: Edward O'Callaghan <eocallaghan@alterapraxis.com>
Reviewed-by: Grigori Goronzy <greg@chown.ath.cx>
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
The closed driver does this, but it looks at base_level and last_level
and uses a conditional assignment, which LLVM can't generate on SGPRs.
That led me to invent this solution that abuses the image descriptor.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Just for consistency. This is actually not a problem, because both addrlib
and radeon check and fix this.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
This is a remnant of the times when the DDX was allocating depth-stencil
buffers for windows. Now, st/dri allocates them and doesn't share them.
Reviewed-by: Nicolai Hähnle <nicolai.haehnle@amd.com>
Nicolai Hähnle