This might be nice to hook up at some point, but it's doing nothing at
the moment and it's not clear to me that it belongs as GL state instead
of winsys state.
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9817>
We never set this to anything interesting, and this is really winsys
state not GL state anyway.
Nota bene: __DRI_ATTRIB_TRANSPARENT_INDEX_VALUE is set to GLX_NONE
instead of the GLX_DONT_CARE we looked like we were doing before. This
is to preserve backward compatibility with older (technically, all
current) X servers, which when building their fbconfigs initialize a
field named 'transparentPixel' _twice_, and the second time from
__DRI_ATTRIB_TRANSPARENT_INDEX_VALUE, but then uses 'transparentPixel's
value for GLX_TRANSPARENT_TYPE. Which, GLX_DONT_CARE isn't a valid value
for that, so glx-fbconfig-sanity fails among much else.
This is harmless, in that I don't think any DRI driver has ever wired
this up (I can't find any evidence in r100 or mga history) and certainly
none that we can currently load have this working.
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9817>
pbuffers aren't a first-class object in mesa, they're just funnily-named
framebuffers. It's thus somewhat silly to track this state separately
when it's effectively identical to GL_MAX_RENDERBUFFER_SIZE, and there's
never been a DRI driver that's ever set these values to anything
interesting. Drop them from mesa (but leave the tokens defined for
compatibility).
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9817>
This table is mostly a mapping into struct gl_config, which is about to
get radically simplified, so we're going to need code to compute values
here instead of just looking up fields in a struct. Keeping the __ATTRIB
bit is somewhat ugly, but we'll expand it back out after the gl_config
changes settle.
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9817>
When more than 1 idr frames have been added to dpb list, there might be 2
frames with same poc in the dpb list. In this case, driver needs to search
the entire dpb list in order to get newly added reference frame with given poc
Signed-off-by: Boyuan Zhang <boyuan.zhang@amd.com>
Reviewed-by: Leo Liu <leo.liu@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9881>
When we encounter a bindless image here, lower_deref returns a
NULL-pointer, and calling record_images_used will try to dereference
that NULL-pointer.
So let's dig out the var from the source instruction instead of the
result of the lowering.
Fixes: 5910c938a2 ("nir/glsl: gather bitmask of images used by program")
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9895>
Do not assign to a variable that won't be used.
Fixes CID#1468098 "Unused value (UNUSED_VALUE)".
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9910>
Do not assign to a variable that won't be used.
Fixes CID#1451708 and CID#1451710 "Unused value (UNUSED_VALUE)".
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9910>
With compressed DCC writes supported, the image should still be
compressed after resolving using the compute path.
Fixes various dEQP-VK.api.copy_and_blit.core.resolve_image.*
failures with RADV_DEBUG=forcecompress on GFX10.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9908>
There is margin in the time budget to run the full GLES3 and GLES31 CTS
instead of only 50%.
Reviewed-by: Eric Anholt <eric@anholt.net>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9899>
Enabling this fast path, while making CPU side simpler
(and thus reducing driver's CPU overhead), forces us to
generate multiple VERTEX_BUFFER_STATE packets pointing to
the same buffer, but with slightly shifted BufferStartingAddress.
This is fine on GFX version >= 11 and < 8, but on version
8 and 9, thanks to internal details of the VF cache, vertex
data from each VERTEX_BUFFER_STATE is cached separately
and this results in a lot of cache misses.
Disabling this fast path restores previous performance levels.
On my SKL GT2 machine this improves performance in:
- GLB27 Egypt offscreen by 37%
- GLB27 TRex offscreen by 22%
- gfxbench5 Manhattan offscreen by 1.75%
- gfxbench5 Manhattan31 offscreen by 1.9%
- gfxbench5 Aztec Ruins high by 2.3%
In Intel performance CI on GFX version 9 it improves performance in:
- gfxbench5 Manhattan offscreen by 1.65%
- gfxbench5 Aztec Ruins normal offscreen by 1.33%
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/3277
Fixes: 42842306d3 ("mesa,st/mesa: add a fast path for non-static VAOs")
Signed-off-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9857>
Fixes: 42842306d3 ("mesa,st/mesa: add a fast path for non-static VAOs")
Signed-off-by: Marcin Ślusarz <marcin.slusarz@intel.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9857>
Avoids some copypaste and makes it easier to see how the different types
relate.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Gert Wollny <gert.wollny@collabora.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8847>
according to spec, unused clearvalues aren't accessed
> Only elements corresponding to cleared attachments are used. Other elements of pClearValues are ignored.
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/9900>