If we can't find an appropiate builtin in the libclc library, we add our
own wrapper at runtime executing the op in fp32 space.
Libclc has variying support for fp16 opcodes and with a libclc prior
llvm-19 it does not work as good as with the newer one.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34053>
Normal fmin doesn't make any promises about NaN, common additionally
doesn't make any promises about infinities. Would be nice to hook that
up to codegen but lowering them to normal works for now.
Cc: mesa-stable
Reviewed-by: Karol Herbst <kherbst@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34941>
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>
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>
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>
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>
Allocate space for the aliased region first, then allocate the
non-Aliased blocks in sequence after that.
SPV_KHR_workgroup_memory_explicit_layout extension added support for
having Blocks of workgroup (shared) memory, which include layout
decoration. For that extension all such blocks must be decorated with
Aliased.
SPV_KHR_untyped_pointers extension lifts that requirement, allowing
blocks that don't alias in workgroup memory. They are still explicitly
laid out.
The motivation is that untyped pointers provide a different
mechanism to obtain the same effect as the Aliased blocks. Instead of
having two Aliased variables with different types, have a single
variable and use an untyped pointer with a different type to access it.
This patch is a preparation for supporting untyped pointers.
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34139>
Move the calculation to nir_lower_vars_to_explicit_types(). This
consolidates the check of shader_info::shared_memory_explicit_layout
in a single place instead of in all drivers.
This is motivated by SPV_KHR_untyped_pointers. Before that extension
we had essentially two modes for shared memory variables
- No layout decorations in the SPIR-V, and both internal layout and
driver location was _given by the driver_.
- Explicitly laid out, i.e. they are blocks, and decorated with Aliased.
Because they all alias, we could assign them driver location directly
to the start of the shared memory.
With the untyped pointers extension, there's a third option, to be added
by a later commit
- Explicitly laid out, i.e. they are blocks, and NOT decorated
with Aliased. Driver location is _given by the driver_. Blocks
with and without Aliased can be mixed.
The driver location of multiple blocks that don't alias depend on
alignment that is driver-specific, which we can more easily do from
the nir_lower_vars_to_explicit_types() that already has access to
a function to obtain such value.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io> (hk)
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com> (v3dv)
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> (anv/hasvk)
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com> (panvk)
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> (radv)
Reviewed-by: Rob Clark <robdclark@gmail.com> (tu)
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34139>
A cooperative matrix conversion operation was represented in NIR by the
cmat_unary_op intrinsic with an nir_alu_op as extra parameter,
that was already lowered to a specific conversion operation
based on the matrix types.
Instead of that, add a new intrinsic `cmat_convert` that is specific
for that conversion. In addition to the src/dst matrix descriptions
already available, also include the signedness information in the
intrinsic (reuse nir_cmat_signed for that). This is needed because
different Convert operations define different interpretations for
integers, regardless their original type.
In this patch, both radv and intel were changed to use the same logic
that was previously used to pick the lowered ALU op.
This change will help represent cmat conversions involving BFloat16,
because it avoids having to create new NIR ALU ops for all the
combinations involving BFloat16.
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34511>
The vtn_ssa_value for a cmat is not backed by a nir_def, but by a nir_variable, so
can't be used directly when calling a function. In most cases the cmat is used by
reference so code will take the value of deref for it (which is a `nir_def`).
When passing a cooperative matrix to a function by value, let the caller pass the deref
value, and the callee copy to a new local variable from that deref.
Fixes: b98f87612b ("spirv: Implement SPV_KHR_cooperative_matrix")
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34364>
After 8fa70cfcfd ("spirv: Use the right bit-size for spec constant
ops") the bit-size will already be adjusted based on the sources, and
this will take care of Convert operations too.
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34119>
This is needed for SPIR-V 1.6 support in OpenCL. This capability enables
the Uniform and UniformId decorations which prior were Shader only.
The CTS ends up using those decorations on function arguments, but we can
just ignore handling them there for now.
Fixes the spirv16_uniformdecoration_uniform and
spirv16_uniformdecoration_uniformid CL CTS test inside test_spirv_new.
Fixes: bb6d371c0e ("rusticl: support SPIR-V 1.5 and 1.6")
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34004>
