Some shaders contain back-to-back atomic accesses in SPIR-V with
AcquireRelease semantics. In NIR, we translate these to a release
memory barrier, the atomic, then an acquire memory barrier.
This results in a lot of unnecessary memory barriers in the middle
of the sequence of atomics:
0. Release barrier
1. Atomic
2. Acquire barrier
3. Release barrier
4. Atomic
5. Acquire barrier
6. Release barrier
7. Atomic
8. Acquire barrier
In the absence of loads/stores, and when the atomic destinations are
unused, these barriers in-between atomics shouldn't be required.
This optimization pass would drop them (lines 2-3 and 5-6 above) while
leaving the first and last barriers (0 and 8), so the sequence remains
synchronized against other access elsewhere in the program.
One common example where this occurs is a sequence of min and max
atomics to clamp a certain memory location's value within a range.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33504>
This is just a hint as far as I can tell. We're allowed to ignore it (as we do),
we just shouldn't be warning about it.
This quiets piles of annoying SPIR-V warnings when running CTS.
SPIR-V WARNING:
In file ../src/compiler/spirv/vtn_cfg.c:144
Function parameter Decoration not handled: SpvDecorationFPFastMathMode
1340 bytes into the SPIR-V binary
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34909>
for specifiers like %v4f, we need to store the whole vector. u_printf can
already handle this from OpenCL, we just need to match that here.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34909>
Kepler and earlier GPUs do not support the ISBERD instruction but have a
different VILD (Vertex Indirect Load) instruction that provides less
functionality. This commit adds support for the op in nak and nir,
needed for the upcoming encoder commit.
Signed-off-by: Lorenzo Rossi <snowycoder@gmail.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34329>
This handles basic operations where clang promotes integers to 32 bits
according to the C99 spec in OpenCL C source code.
This is its own opt_algerbraic pass, because we don't wanna fight with
nir_lower_bit_size.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34641>
Since we're not creating new output reads, just vectorizing existing
ones, this isn't the place to assert whether we can actually read
outputs.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Reviewed-by: Emma Anholt <anholt@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34784>
The spec text here is:
Image Type must be an OpTypeImage. It is the type of the image in the
combined sampler and image type. It must not have a Dim of SubpassData.
Additionally, starting with version 1.6, it must not have a Dim of Buffer.
For older SPIR-V versions, there is no analogous requirement. It is implicitly
valid to use a Dim of Buffer (even though it doesn't make much sense). Should
apps do it anyway? Probably not, but it doesn't matter and they do.
glslang considers this requirement relevant only for 1.6+:
if (glslangIntermediate->getSpv().spv >= glslang::EShTargetSpv_1_6 &&
texType.getSampler().isBuffer()) {
// SamplerBuffer is not supported in spirv1.6 so
// `samplerBuffer(textureBuffer, sampler)` is a no-op
// and textureBuffer is the result going forward
constructed = arguments[0];
} else
constructed = builder.createOp(spv::OpSampledImage, resultType(), arguments);
That means SPIR-V with an older declared version will warn even with a glslang
new enough to know about the 1.6 requirement. That includes a *lot* of SPIR-V's
built with the CTS.
I see no compelling reason to keep the warning for older than 1.6. Removing the
spurious warning silences a *huge* amount of noise from dEQP-VK (plus a bit from
KHR-GL46). In exchange I see very little tradeoff, it's not really our job to
lint for best practices not in the spec.
I see two viable options:
1. Try to convince the whole ecosystem outside of Mesa to pivot to our pedantic
reading of the spec and get them to update all the old SPIR-V binaries in the
wild, in the case of CTS being changed at the glslang level and then
trickling down into CTS.
2. Merge this patch, simplifying Mesa and immediately forget about this forever.
I'm spending all my FOSS political capital on kernel upstreaming so I have a
strong preference for #2, aka hitting Marge on this MR and then moving on with
all of our lives.
("Ignore the problem and make deqp-runner annoying to use" is the secret 3rd
option I'd rather not do.)
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34847>
this is useful across drivers for maint5 semantics on mobile hw.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34762>
../../../../../../../mesa/src/compiler/nir/nir_lower_gs_intrinsics.c: In function ‘nir_lower_gs_intrinsics’:
../../../../../../../mesa/src/compiler/nir/nir_lower_gs_intrinsics.c:523:93: warning: ‘state’ may be used uninitialized [-Wmaybe-uninitialized]
523 | state.decomposed_primitive_count_vars[i] = state.decomposed_primitive_count_vars[0];
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~
../../../../../../../mesa/src/compiler/nir/nir_lower_gs_intrinsics.c:464:17: note: ‘state’ declared here
464 | struct state state;
| ^~~~~
It's always initialized by the first iteration of the loop, but GCC
doesn't seem to know that.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34785>
../../../../../../../mesa/src/compiler/nir/nir_opt_shrink_vectors.c: In function ‘shrink_dest_to_read_mask’:
../../../../../../../mesa/src/compiler/nir/nir_opt_shrink_vectors.c:140:36: warning: writing 16 bytes into a region of size 15 [-Wstringop-overflow=]
140 | swizzle[first_bit + i] = i;
| ~~~~~~~~~~~~~~~~~~~~~~~^~~
../../../../../../../mesa/src/compiler/nir/nir_opt_shrink_vectors.c:138:18: note: at offset [1, 15] into destination object ‘swizzle’ of size 16
138 | uint8_t swizzle[NIR_MAX_VEC_COMPONENTS] = { 0 };
| ^~~~~~~
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34785>
Debugging with nir_printf_fmt can result in overwhelming information. This
allows us to filter for a pixel we care about.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34737>
I'm not sure how this was supposed to ensure padding was zero, and it
doesn't seem to work for me (GCC 15.0.1).
Fixes a NIR validation failure with dEQP-VK.glsl.bfloat16.constant.compute
and RADV.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Fixes: 90e1b12890 ("spirv: Add bfloat16 support to SpecConstantOp")
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34769>
This change relocates the fdot lowering from the generic NIR to the lima,
since lima is the only consumer of this particular lowering. This avoids
potential conflicts with the similar fdot lowering already present in
nir_lower_alu_width.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Erico Nunes <nunes.erico@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34757>
