driFetchDrawable is only ever called from the MakeCurrent path, which
means it has to handle the case of pre-GLX-1.3 Windows being named as
the drawable. When it finds the drawable in the hash, it increments its
refcount before returning it, so for a GLXWindow it would be 2 on first
return, one from glXCreateWindow and one from glXMakeCurrent. But when
it does not find the drawable and creates one for the naked Window, the
reference count on first return would only be 1. As a result, if this
context was then ever bound to a different drawable, the old Window's
DRI drawable state (like the back buffer) would be destroyed.
Fixes piglit's glx-multi-window-single-context and glx-make-current for
a variety of drivers.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6713
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17479>
And also handle tess. In all cases, we want to use the VS lowering pass
on the last geometry stage. We don't make a special exception for GS
like other drivers, because GS gets lowered into a quasi-VS.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17341>
If we didn't EmitPrimitive() then the shadow (old) outputs would not
get copied to the emit temps (to eventually be copied back to the real
outputs. This isn't so bad except that means the realy vertex_flags
output has an undefined value.
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17341>
Fixed:
- VK_QUERY_TYPE_PRIMITIVES_GENERATED_EXT was able to stop prim counter
when pipeline stats query is running.
- This may have happened when prim gen query was in secondary cmdbuf.
- VK_QUERY_TYPE_PRIMITIVES_GENERATED_EXT counting geometry in each tile.
- VK_QUERY_TYPE_PRIMITIVES_GENERATED_EXT counting geometry in each tile
when pipeline stats query is started inside prim gen query and inside
a renderpass.
The matter of VK_QUERY_TYPE_PRIMITIVES_GENERATED_EXT and pipeline stats
interaction is solved by tracking whether pipeline stats query is
running both on CPU (for non secondary cmdbuf case) and on GPU (for
secondary cmdbuf).
Note, prim gen query is not allowed with secondary command buffers, so
only pipeline stats query is tracked on gpu.
See https://gitlab.khronos.org/vulkan/vulkan/-/issues/3142
Counting geometry per each tile is solved by:
- Conditionally executing START/STOP_PRIMITIVE_CTRS to not run in tiling
pass. Solves the case when prim gen query is inside a renderpass.
- Stop prim counters before executing `draw_cs` and restarting them
afterwards. Solves prim gen query being outside a renderpass.
Fixes GL CTS tests with Zink + `TU_DEBUG=gmem`:
GTF-GL46.gtf30.GL3Tests.transform_feedback.transform_feedback_max_separate
GTF-GL46.gtf40.GL3Tests.transform_feedback2.transform_feedback2_basic
GTF-GL46.gtf40.GL3Tests.transform_feedback2.transform_feedback2_framebuffer
GTF-GL46.gtf40.GL3Tests.transform_feedback3.transform_feedback3_streams_overflow
GTF-GL46.gtf40.GL3Tests.transform_feedback3.transform_feedback3_streams_queried
GTF-GL46.gtf40.GL3Tests.transform_feedback2.transform_feedback2_states
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6602
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17163>
For a5xx+ renamed:
- RST_PIX_CNT -> START_FRAGMENT_CTRS
- RST_VTX_CNT -> STOP_FRAGMENT_CTRS
- TILE_FLUSH -> START_COMPUTE_CTRS
- STAT_EVENT -> STOP_COMPUTE_CTRS
I'm not sure about a5xx itself but I'll take a chance of it being
similar to a6xx in this regard.
Knowing this emit_begin_stat_query/emit_end_stat_query can now emit
only events that are needed for the pool's flags.
Also primitive generated query clearly doesn't need fragment and
compute counters.
Passes tests:
dEQP-VK.query_pool.statistics_query.*
dEQP-VK.transform_feedback.primitives_generated_query.*
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17163>
This fixes tests using imageLoad/imageStore on texture
created using glEGLImageTargetTexture2DOES.
Before this change, the format was guessed as GL_RGBA,
which would be rejected by _mesa_get_shader_image_format.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16662>
New tests, dEQP line rasterization test fix that lets Intel pass.
Clears out bogus xfails from 1.3.2.0 uprev on a630, which I suspect were
"we lost the device twice on a full run once, and those fails got pasted
in without checking if it happened a full run again" (since we haven't
seen them in other full run attempts).
Also clears out the a630 vk asan xfails (essentially all tests run) by
turning off leak detection which was just catching leaks in vkcts.
Acked-by: Jason Ekstrand <jason@jlekstrand.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17304>
Before, we needed CP post-sched to copy-propagate references to NIR
registers produced by out-of-ssa. Now that we're in SSA, this pass ends
up not doing anything useful, and actually gets in the way by occasionally
creating a cycle in the DAG.
The entire shader-db impact is:
instructions HURT: shaders/closed/steam/tropico-5/78.shader_test FRAG: 238 -> 242 (1.68%)
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17320>
Not only runs less testing when only one driver is impacted, but also
makes sure zink+turnip is turned off when the farm is.
Reviewed-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Acked-by: Eric Engestrom <eric@engestrom.ch>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17287>
On a650+ we use the new Z24UINT_S8UINT format to sample the stencil
aspect of D24S8, which returns stencil in the second component and also
uses the second integer component for the border color. However Vulkan
mandates that the first component is used for the stencil border color.
There's no workaround we know of, so we have to fall back to the old
behavior where there is a workaround. If we know the format, we can
fixup the border color ourselves though.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17177>
From the API's point of view, border color replacement looks like this:
--------------------
| API Border Color |
--------------------
|
----------- | ---------------- ----------
| API fmt |-------->| User Swizzle |----->| Shader |
----------- ---------------- ----------
From the HW point of view, it looks like this:
-------------------
| HW Border Color |
-------------------
|
---------- ----------- | --------------- ----------
| HW fmt |-----| HW swap |------>| Tex Swizzle |----->| Shader |
---------- ----------- --------------- ----------
When the HW fmt + HW swap isn't enough to represent an API format, we
need to prepend our own swizzle to the the user's swizzle, so the tex
swizzle is a "format swizzle" composed with the user swizzle. However,
we don't want this format swizzle to be applied to border colors, so
there's a workaround in freedreno which is meant to undo the format
swizzle so that the HW border color with the format swizzle applied
equals the API border color, and everything is ok. However, on a6xx at
least it was incorrectly undoing the entire tex swizzle. This broke
border color with a user swizzle, because it was now effectively not
getting applied for the border color. It also made it seem like the user
swizzle is required for the workaround, which would have implications
for VK_EXT_border_color_swizzle with turnip, but it's not.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17177>
On-GPU LRZ direction tracking allows LRZ to support secondary cmdbufs,
reusing LRZ between renderpasses, and in future to support LRZ when
VK_KHR_dynamic_rendering is used.
With on-gpu tracking we have to be careful keeping LRZ state in sync
with underlying depth image, which means we should invalidate LRZ
when underlying image is changed or the view of image is different
from previous renderpass.
All of this resulted in LRZ logic being thinly spread through the code,
making it hard to understand. So most of it was moved to tu_lrz.c.
For more details on past and new LRZ features see comment at the
top of tu_lrz.c.
Note about blob:
- Blob is much more happy to do LRZ_FLUSH, it flushes at the start
of the renderpass, after binning, and at the end of the renderpass.
- Blob seem not to care about changes in depth image done via
vkCmdCopyImage.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6347
Signed-off-by: Danylo Piliaiev <dpiliaiev@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16251>
Adam Jackson
Georg Lehmann
Danylo Piliaiev
Emma Anholt
Connor Abbott
Eric Engestrom
İlhan Atahan
Marek Olšák
Rob Clark
Pierre-Eric Pelloux-Prayer
David Heidelberg
Jonathan Marek
Hyunjun Ko