this pointer is only valid if length is valid
fixes dEQP-GL45-ES3.functional.negative_api.shader.shader_binary with
glthread enabled
fixes#10915
cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28501>
The ring cs shmem cache is already there. The external fence/sempahore
support will be eventually via adopting mesa common drm syncobj support.
Signed-off-by: Yiwei Zhang <zzyiwei@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28532>
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>
This helps fix a number of piglit tests that exercise this
functionality, such as:
- piglit.spec.arb_texture_rg.fbo-clear-formats
- piglit.spec.ext_framebuffer_object.fbo-clear-formats
- piglit.spec.ext_texture_snorm.fbo-clear-formats
Signed-off-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Nanley Chery <nanley.g.chery@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23030>
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>
Keeping the mask instead of the actual number will make it easier
later to transition to basing the information on I/O intrinsics
instead of I/O variables.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28172>
No functional changes.
Use const more, and rename some variables to make them clearer.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28172>
No functional changes.
Make the code look cleaner by handling the various stages
by different functions.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28172>
No functional changes.
The information in these structures will be needed
in a later commit. Done separately to help keep that
other commit cleaner.
Signed-off-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28172>
When we dispatch an indirect compute job, the buffer containing
the indirect parameters should be marked as read (since the GPU
will read the parameters from there). Without this there's a
race condition if the CPU later updates the buffer.
Signed-off-by: Eric R. Smith <eric.smith@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28512>
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>
This maches specification and better matches the gfx 125 definition.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28505>
It was using the wrong platform definition that only had 1 bit,
filtering by DG2/ACM it shows the correct definition.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28505>
Justing setting all zeroes to STATE_COMPUTE_MODE will do nothing,
the mask of each register must be set for it to change.
Signed-off-by: José Roberto de Souza <jose.souza@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28505>
According to spec 4.6 section 8.14 (TEXTURE MINIFICATION), λ(x, y) is clamped to minLod and maxLod first and then used to choose minification or magnification: “If λ(x, y) is less than or equal to zero the texture is said to be magnified; if it is greater, the texture is minified. “
Prior to this change, Zink hard-coded minLod and maxLod to be [0.0, 0.25]. Some problems can be seen here:
If lambda originally is 0.3, and app sets minLod = 0.0f, maxLod = 0.0f, and minFilter = Linear, magFilter = Nearest:
According to the spec, lambda is clamped to 0.0 first, so magnification should be chosen, but on Zink lambda was clamped to 0.25, minification was chosen incorrectly.
Similarly if app sets minLod = 3.0f and maxLod = 3.0f
According to the spec, minification should be used regardless of lambda, but Zink would allow magnification if lambda was less than or equal to zero.
This is fixed by individually clamping minLod and maxLod to [0, 0.25].
Signed-off-by: daoxiang.gong <daoxiang.gong@imgtec.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/26933>
Eric Engestrom
Mike Blumenkrantz
Yiwei Zhang
Job Noorman
Rohan Garg
Marek Olšák
Timur Kristóf
Ganesh Belgur Ramachandra
Eric R. Smith
Connor Abbott
José Roberto de Souza
daoxiang.gong
Corentin Noël