some gnome tests are seeing this:
==4579== Invalid read of size 4
==4579== at 0x161B28FB: UnknownInlinedFun (simple_mtx.h:106)
==4579== by 0x161B28FB: st_save_zombie_sampler_view (st_context.c:213)
==4579== by 0x161D762A: st_texture_release_all_sampler_views.part.0 (st_sampler_view.c:272)
==4579== by 0x161D7CB6: st_texture_release_all_sampler_views (st_sampler_view.c:258)
==4579== by 0x161D7CB6: st_delete_texture_sampler_views (st_sampler_view.c:292)
==4579== by 0x16191B9E: _mesa_delete_texture_object (texobj.c:523)
==4579== by 0x16191CDC: _mesa_reference_texobj_ (texobj.c:637)
==4579== by 0x1619632F: _mesa_reference_texobj (texobj.h:92)
==4579== by 0x1619632F: _mesa_free_texture_data (texstate.c:1114)
==4579== by 0x162EEE1D: _mesa_free_context_data (context.c:1155)
==4579== by 0x161B3C0F: st_destroy_context (st_context.c:999)
==4579== by 0x160F155A: dri_destroy_context (dri_context.c:277)
==4579== by 0x1603C371: dri2_destroy_context (egl_dri2.c:1592)
==4579== by 0x1602EBF5: eglDestroyContext (eglapi.c:918)
==4579== by 0x502DF3C: gdk_gl_context_dispose (gdkglcontext.c:211)
==4579== Address 0x34dc9b08 is 7,016 bytes inside an unallocated block of size 10,336 in arena "client"
==4579==
It appears we destroy the mutex and zombie objects, but freeing
context data seems to add them back.
This might not be the complete answer.
Cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28565>
The two extensions are implemented natively but allow to leak structs to
renderer side to avoid deep copying huge driver side pNext chain. It
doesn't make things more robust if we hide the two behind core 1.3 and
drop the two from the protocol so that venus-protocol filters out the
leaked structs. e.g. we'd still have to flip some bits in the core
feature structs.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28532>
While looking for the first use of a def for spilling, we used to
iterate all sources of a use to determine which one refers to the def.
However, when the def was reloaded before, we would fail to find it
since the source was updated to refer to the reloaded def while we
searched the uses of the original def.
This patch fixes this by simply not iterating the sources of a use
anymore. We don't need to know which source exactly uses the def, the
instruction is enough.
Fixes: 21cd9b9557 ("ir3: implement RA for predicate registers")
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28148>
When calculating SSA uses after reloading a def for the first time, the
uses of the original def would not be complete anymore (since some of
its uses may be replaced by a reloaded def). This causes problems when
calculating the furthest first use to determine a value to be spilled.
For example, something like:
ssaX = foo # No free regs so this one is ignored
...
bar ssaX, ssaY So
Let's say we arrive at bar and neither ssaX nor ssaY are live and we
have one free register. First, ssaX will get reloaded. Then, since there
are no free registers left, we need to spill one. If we calculate SSA
uses now, the ones for ssaX will not include bar which might cause us to
select ssaX for spilling which shouldn't happen because it's used by the
current instruction.
This patch fixes this by calculating SSA uses at the start of RA. I
haven't been able to measure a significant performance improvement when
trying to postpone calculating the SSA uses.
Fixes: 21cd9b9557 ("ir3: implement RA for predicate registers")
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28148>
shaderdb expects to receive shader info via a glDebugMessageCallback
callback. This patch updates print_pipeline_stats to use the
zink_context::dbg callback.
The format of the shader info is also updated to match what the shaderdb
report.py script expects. In particular, we use what report.py calls
"nv_format" since that is the closest to the current format.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28542>
Explicit interpolation just loads raw vertex data as-is and lets the FS do
the interpolation manually.
This adds handling of nir_intrinsic_load_input_vertex, which has 2 different
behaviors: undefined vertex ordering and strict vertex ordering.
- dead IO removed correctly
- constants and uniform expressions are propagated normally
- outputs are deduplicated within their own category (strict and non-strict)
- outputs used by explicit interpolation are never treated as "convergent"
- backward inter-shader code motion is skipped
- compaction has 2 new types of vec4 slots:
- mixed 32-bit and 16-bit explicit strict (sharing the same vec4)
- mixed 32-bit and 16-bit explicit non-strict (sharing the same vec4)
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28247>
Not all code paths of this optimization depend on there being only
one user of the first operand; and those code paths already have
their own check for this.
Fossil DB stats on Navi 21:
Totals from 477 (0.60% of 79395) affected shaders:
Instrs: 995901 -> 995341 (-0.06%); split: -0.06%, +0.00%
CodeSize: 5218856 -> 5216816 (-0.04%); split: -0.04%, +0.00%
Latency: 16340256 -> 16338799 (-0.01%); split: -0.01%, +0.00%
InvThroughput: 3044975 -> 3044871 (-0.00%); split: -0.00%, +0.00%
Copies: 95047 -> 95071 (+0.03%)
SALU: 150345 -> 149785 (-0.37%); split: -0.38%, +0.01%
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28545>
We need invalidate CCHE when we optimize out an invalidation of UCHE,
for example a storage image write to texture read. We missed this
earlier because of the blob's tendency to always over-flush, but the
blob does use this when building acceleration structures.
Fixes: 95104707f1 ("tu: Basic a7xx support")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28445>