This implements the common pattern of splitting-off a scalar value from
a vector. It handles both 64b (via ir3_64b) and normal register scalars.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33797>
64b values occupy 2 registers but we receive them as a single component
value from NIR. Since there are many places that assume a 1:1
relationship between components and instructions, this can be error
prone as we have to remember to double the number of components whenever
a 64b value is involved.
This commit tries to improve on this situation by representing 64b
values as a collect of 2 registers, restoring the 1:1 mapping between
NIR components and ir3 instructions. This commit only adds some helpers
to create 64b values and access their individual components but doesn't
actually use them yet. This will happen in a follow-up commit.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33797>
When creating a collect with a source that is itself a collect, flatten
the latter's sources into the new collect. This is mainly useful for
collects used for 64b values, as we can treat them just like non-64b
values when collecting them.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33797>
We want to start lowering certain NIR instructions to collects (e.g.,
instructions with a 64b def) which means that ir3_get_src_shared has to
support collects. Since we can't mov the result of a collect, implement
this by converting its sources and creating a new collect.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33797>
The HW specifications require the size of shader resource tables to be a
multiple of 4, otherwise correct behaviour is not guaranteed.
Fixes: 713f5c3600 ("panvk: Prepare the cmd_desc_state logic for Valhall")
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Reviewed-by: Lars-Ivar Hesselberg Simonsen <lars-ivar.simonsen@arm.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35553>
Fixes the following test on GC7000:
- dEQP-GLES3.functional.shaders.texture_functions.texture.sampler2darrayshadow_vertex
- dEQP-GLES3.functional.shaders.texture_functions.texturelod.sampler2dshadow_vertex
- dEQP-GLES3.functional.shaders.texture_functions.texturelod.sampler2dshadow_fragment
- dEQP-GLES3.functional.shaders.texture_functions.textureprojlod.sampler2dshadow_vertex
- dEQP-GLES3.functional.shaders.texture_functions.textureprojlod.sampler2dshadow_fragment
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35600>
When running `ffmpeg -vaapi_device /dev/dri/renderD128 -f lavfi -i smptebars=duration=5:size=1280x720:rate=30 -vf format=rgba,hwupload,scale_vaapi=format=nv12,hwdownload testout.mp4`,
the vpe is asked to transform into NV12, which cannot be done with a blit. `si_vpe_construct_blt` fails, but then it gracefully falls back into `vlVaPostProcCompositor` and finishes the task correctly, but not before logging the error:
SIVPE ERROR ../mesa-25.1.3/src/gallium/drivers/radeonsi/si_vpe.c:1095 si_vpe_construct_blt Failed in checking process operation and build settings(9)
for each frame that is processed. Since this is expected, my original thought was to demote this to a warning. But looking at all the reasons it could fail for, there already is a warning (or error) logged, so it seems to me the best thing to do is remove the error entirely
There may be a better approach here, and I'm all ears.
Fixes: e85a6b6a63 ("radeonsi/vpe: check reduction ratio")
Reviewed-by: Peyton Lee <peytolee@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35449>
Add an assert to catch cases where both nir_tex_src_comparator and
nir_tex_src_ddy attempt to use the same src2 slot in texture instructions.
This prevents silent overwrites that could cause incorrect shader
compilation.
The assertion helps catch potential issues in complex texture operations
like those found in dEQP textureGrad shadow tests, where multiple
texture sources compete for the same hardware slot.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35531>
Passes all dEQP-GLES3.functional.shaders.texture_functions.texturegrad.*
tests on GC7000.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35531>
The hardware expects textureGrad (txd) shadow comparator to be
specified as the w component of the coordinate, rather than as a
separate comparator source.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35531>
Implement support for the texldgpcf instruction, which handles texture
gradient sampling with shadow comparison.
Blob generates such txf's for
dEQP-GLES3.functional.shaders.texture_functions.texturegrad.*shadow*
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Lucas Stach <l.stach@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35531>
8f557b84f6 was done because `text` is sometimes just an int,
but the fix was only applies to the padding calculation.
Unfortunately, the padding direction is also different between strings
and integers, which means the behaviour is now incoherent.
Let's convert `text` to a string before we start doing anything so that
everything afterwards is coherent.
Fixes: 8f557b84f6 ("ci: crnm: fix hyperlink format")
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35587>
The GFX12 ISA doc describes other layouts for A/B, but they are identical
to the C layout with the exception of the order of the rows (columns for A).
And as long as these are swapped in the same way for both A and B, the muladd
result will be the same. So we use the C layout for all uses.
This will simplify conversions between uses, and allows A/B to use a single
memory access for load/store in wave32.
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35570>
The intel-adl-cl job was previously running on two DUTs, but the
runtime reported by deqp-runner was only about 3 minutes.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35574>
Introduce a new, pre-merge vkd3d-proton job on Alder Lake, and move the
VK_DRIVER variables to the .anv-test template.
Signed-off-by: Valentine Burley <valentine.burley@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35574>
This matches up with the native gl drivers as well as the media stack.
- VK_SAMPLER_YCBCR_RANGE_ITU_NARROW <=> EGL_YUV_NARROW_RANGE_EXT
Cc: mesa-stable
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35597>
This matches up with the native gl drivers as well as the media stack.
- VK_SAMPLER_YCBCR_RANGE_ITU_NARROW <=> EGL_YUV_NARROW_RANGE_EXT
Cc: mesa-stable
Acked-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35597>
This shouldn't matter if FDM is actually enabled, because in that case
the pipeline must enable the bit and we dirty FDM state at the
beginning, but pipelines can enable FDM even if the renderpass they're
used in doesn't use FDM and in that case we still need to use the FDM
path to duplicate the viewports. Fix the case where a different pipeline
is bound that enables FDM without actually using FDM.
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35581>
Will be used by Cuttlefish CI/CD, but also commonly used by
gfxstream developers.
meson setup gfxstream-build -Dvulkan-drivers="gfxstream" -Dgallium-drivers="" -Dvirtgpu_kumquat=true -Dopengl=false -Drust_std=2021
In distros, virtgpu_kumquat is not expected to be packaged since
it is a CI/CD tool.
Reviewed-by: Aaron Ruby <aruby@qnx.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/35210>
