- Oct 27, 2023
-
-
This is the original definition for ANYOPMASK, until we found that clang raised a warning using the option shift-count-overflow, so we used an alternative. That warning was fixed with commit 6e2bb716, so let's restore previous version. Note that other good thing of that warning being fixed is that now we can use without warning OP_RANGE with bit 63 (in the case that any broadcom opcode used that bit) Reviewed-by: Eric Engestrom <eric@igalia.com> Part-of: <mesa/mesa!25776>
-
The range alignment didn't happen through GetDescriptorEXT as it called write_buffer_descriptor directly. So simply move the align from write_buffer_descriptor_impl into write_buffer_descriptor. Fixes: 46e0c775 ("radv: implement VK_EXT_descriptor_buffer") Signed-off-by: Karol Herbst <kherbst@redhat.com> Reviewed-by: Georg Lehmann <dadschoorse@gmail.com> Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Part-of: <mesa/mesa!25837>
-
I didn't check if it's a valid vulkan SPIR-V opcode and turns out it isn't Fixes: 82eed326 ("zink: support more nir opcodes") Signed-off-by: Karol Herbst <kherbst@redhat.com> Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com> Part-of: <mesa/mesa!25837>
-
This is required by OpenCL who relies on flushing behavior to match the runtimes advertized feature, but also later once rusticl does support denorms, to flush them if applications whish to do so. Signed-off-by: Karol Herbst <kherbst@redhat.com> Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com> Part-of: <mesa/mesa!25837>
-
This aliases each access as required by OpenCL. It's up to the vulkan driver to vectorize to wider loads/stores if possible. Signed-off-by: Karol Herbst <kherbst@redhat.com> Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com> Part-of: <mesa/mesa!25837>
-
Signed-off-by: Karol Herbst <kherbst@redhat.com> Acked-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com> Part-of: <mesa/mesa!25837>
-
Cc: mesa-stable Signed-off-by: Karol Herbst <kherbst@redhat.com> Part-of: <mesa/mesa!25837>
-
It's kinda pointless to have it too big, it also causes weird shaders to be generated and causes stack overflows in `nir_opt_gcm`. Nothing needs big values here anyway. Cc: mesa-stable Signed-off-by: Karol Herbst <kherbst@redhat.com> Part-of: <mesa/mesa!25837>
-
It's pointless to advertise more than CL_DEVICE_MAX_MEM_ALLOC_SIZE and also the CTS tests against this. Cc: mesa-stable Signed-off-by: Karol Herbst <kherbst@redhat.com> Part-of: <mesa/mesa!25837>
-
The nir/spirv variant is simply not precise enough and almost everybody lowers it anyway. Signed-off-by: Karol Herbst <kherbst@redhat.com> Part-of: <mesa/mesa!25837>
-
Lionel Landwerlin authored
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com> BSpec: 56890 Reviewed-by: Kenneth Graunke <kenneth@whitecape.org> Part-of: <mesa/mesa!25506>
-
The recommended OS flavour for RPI4 and onwards is 64 bits, and just keep the 32 bits for RPI3 and below. This makes all the V3D testing to be done with 64 bits. Acked-by: Iago Toral Quiroga <itoral@igalia.com> Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com> Part-of: <mesa/mesa!25904>
-
Signed-off-by: Yonggang Luo <luoyonggang@gmail.com> Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com> Part-of: <mesa/mesa!24462>
-
There is no neeed #include "main/menums.h" in nir.c, as it's belongs to gallium code Signed-off-by: Yonggang Luo <luoyonggang@gmail.com> Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com> Part-of: <mesa/mesa!24462>
-
some drivers require this cc: mesa-stable Part-of: <mesa/mesa!25914>
-
this catches duplicated xfb when generated geometry shaders are used cc: mesa-stable Part-of: <mesa/mesa!25914>
-
this matches other resources created with staging blit-like mechanics cc: mesa-stable Part-of: <mesa/mesa!25914>
-
this is otherwise illegal cc: mesa-stable Part-of: <mesa/mesa!25914>
-
exceeding src/dst extents is illegal cc: mesa-stable Part-of: <mesa/mesa!25914>
-
required by spec backport-to: 23.3 Part-of: <mesa/mesa!25914>
-
required by spec cc: mesa-stable Part-of: <mesa/mesa!25914>
-
Part-of: <mesa/mesa!25914>
-
The function is getting too big, let's add comments, docstrings to the most important function, new type hints and extract methods from it to make it easier to read. Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com> Part-of: <mesa/mesa!25858>
-
In Mesa MR pipelines, we have the sanity job. This job is not an explicit need for any one job, because only jobs with `- needs: []` ignores previous jobs. If no `needs` is specified, the job will wait until all the jobs of earlier stages are finished before starting. See additional details section at: https://docs.gitlab.com/ee/ci/yaml/index.html#stage-post Closes: mesa/mesa#10032 Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com> Part-of: <mesa/mesa!25858>
-
We were using sha to fetch the pipeline from GraphQL, but that leads to wrong results when MR and branch pipelines exist. For example, using pipeline-url as the MR pipeline: - https://gitlab.freedesktop.org/gallo/mesa/-/pipelines/1017182 This would lead into the branch pipeline: - https://gitlab.freedesktop.org/gallo/mesa/-/pipelines/1013189 Also simplify the GQL query, it had lots of unused data. Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com> Part-of: <mesa/mesa!25858>
-
- Oct 26, 2023
-
-
Without this, we replace vote_ieq(b) with vote_ieq(u2u32(b)) which is wonky because we're doing a u2u on a 1-bit type. With this, we now replace it with vote_ieq(b2b32(b)). For other subgroup ops, we replace things like *scan[op](b) with *scan[op](b2b32(b)). For scan ops, this assumes that b2b1(op(b1b32(x), b2b32(y))) = op(x, y) for all of the ops iand, ior, and ixor. This is true on all the back-ends I'm aware of. Reviewed-by: Daniel Schürmann <daniel@schuermann.dev> Reviewed-by: Timur Kristóf <timur.kristof@gmail.com> Part-of: <mesa/mesa!25894>
-
Without this, nir_type_conversion_op(bool, bool32, RND) will return u2u32 instead of b2b32 which is pretty unexpected behavior. Reviewed-by: Daniel Schürmann <daniel@schuermann.dev> Reviewed-by: Timur Kristóf <timur.kristof@gmail.com> Part-of: <mesa/mesa!25894>
-
On NVIDIA, we can do a vote_ieq on bool in one hardware op so we don't want that lowered. We do want to lower vote_feq and other vote_ieq, though. Reviewed-by: Daniel Schürmann <daniel@schuermann.dev> Reviewed-by: Timur Kristóf <timur.kristof@gmail.com> Part-of: <mesa/mesa!25894>
-
May as well clean it up while we're here. Reviewed-by: Daniel Schürmann <daniel@schuermann.dev> Reviewed-by: Timur Kristóf <timur.kristof@gmail.com> Part-of: <mesa/mesa!25894>
-
They're different enough from all the other subgroup ops so it's best to handle them as their own case. Reviewed-by: Daniel Schürmann <daniel@schuermann.dev> Reviewed-by: Timur Kristóf <timur.kristof@gmail.com> Part-of: <mesa/mesa!25894>
-
Using u2u is always correct for integers, including signed integers, because we're doing a down-cast. It's wrong for floats, though. Fixes: f95665cf ("nir/lower_bit_size: Add support for lowering subgroup ops") Reviewed-by: Daniel Schürmann <daniel@schuermann.dev> Reviewed-by: Timur Kristóf <timur.kristof@gmail.com> Part-of: <mesa/mesa!25894>
-
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev> Reviewed-by: Timur Kristóf <timur.kristof@gmail.com> Part-of: <mesa/mesa!25894>
-
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev> Reviewed-by: Timur Kristóf <timur.kristof@gmail.com> Part-of: <mesa/mesa!25894>
-
Part-of: <mesa/mesa!25624>
-
by not returning busy for non-HIC unsynchronized texture uploads, the GL frontend will fall through to directly access the unsynchronized cmdbuf Part-of: <mesa/mesa!25624>
-
this is needed to handle unsynchronized access Part-of: <mesa/mesa!25624>
-
this is unset any time a texture is accessed and must be explicitly re-set to preserve unsynchronized access Part-of: <mesa/mesa!25624>
-
this provides functionality for unsynchronized texture uploads without HIC support by adding a cmdbuf which can only be accessed directly by the frontend thread Part-of: <mesa/mesa!25624>
-
no functional changes Part-of: <mesa/mesa!25624>
-
the blitter path here was just wishful thinking anyway Part-of: <mesa/mesa!25624>
-