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>
Handle bfloat16 by converting sources to float, performing the
operation, and converting result back to bfloat16 if needed. This is
done because not all ALU ops have a `bf` version in NIR.
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34105>
Take the opportunity to add a comment about why the bit_size
comes from the NIR def and not the original type.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34105>
This will allow including types that don't have a nir_alu_type
equivalent, like bfloat16.
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34105>
SPV_KHR_bfloat16 requires a small set of operations,
since it doesn't support all the arithmetic ops.
This patch adds conversions to/from Float32 and also
the necessary ops (bfdot, bffma, bfmul) to implement
SpvOpDot using the same lowering approach than the
Float32 counterpart.
Reviewed-by: Rohan Garg <rohan.garg@intel.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34105>
Currently mesa-clc bundles OpenCL headers from Clang only if the static
LLVM is used (which means Clang / LLVM are not present on the target
system). In some cases (e.g. when building in OpenEmbedded environemnt)
it is desirable to have shared LLVM library, but skip installing the
whole Clang runtime just to compile shaders. Add an option that forces
OpenCL headers to be bundled with the mesa-clc binary.
Signed-off-by: Dmitry Baryshkov <dmitry.baryshkov@oss.qualcomm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34551>
If the optional flag is set, compaction groups TES inputs based on which
outputs they are used for:
- inputs generating only POS/CLIP outputs are first
- inputs generating both POS/CLIP and VAR outputs are next
- inputs generating only VAR outputs are last
shader-db with ACO:
143 shaders have -1.44% average decrease in code size.
There are fewer input loads and more of them are vec4 instead of vec1-3.
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32262>
The first pass computes which shader instructions contribute to each
output. It can be used to query how data flows within shaders towards
outputs.
The second pass computes which shader input components and which types of
memory loads are used to compute shader outputs.
The third pass uses the second pass to gather which input components are
used to compute pos and clip dist outputs, which input components are used
to compute all other outputs, and which input components are used to
compute both. This will be used by compaction in nir_opt_varyings for
drivers that split TES into a separate position cull shader and varying
shader to make it less likely that the same vec4 inputs are needed in both.
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/32262>
With a 64 bit pointer model, instead of doing -1 the pass ended up doing
+4294967295. The reason here was some implicit integer conversion going
horribly wrong, so just do the offset math in 64 bit to get a nice result.
Cc: mesa-stable
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/13023
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34669>
Adds image_bvh_dual_intersect_ray and image_bvh8_intersect_ray which can
handle the new BVH format. Both instructions write up to 10 VGPRs so
they need to use a vec16 definition in nir.
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34273>
