The per-MRT blend enables are in RB_MRT_CONTROL regs, this field is a
bitmask of whether we need to read in the MRT's current color in order to
perform the blending/colormask/logicop.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/34991>
There are currently two places where we have to handle values that are
logically 64b: 64b atomics and 64b global addresses. For the former, we
ingest the values as 64b from NIR, while the latter uses 2x32b values.
This commit makes things more consistent by using 64b NIR values for
global addresses as well.
Of course, we could also go the other way around and use 2x32b values
everywhere, which would make things consistent as well. Given that ir3
doesn't actually have 64b registers, and 64b values are represented by
collected 2x32b registers, this could actually make more sense.
In the end, both methods are mostly equivalent and it probably doesn't
matter too much one way or the other. However, the reason I have a
slight preference for ingesting things as 64b is that it allows us to
use more of the generic NIR intrinsics, which use 1-component values for
64b addresses or atomic values. This commit already makes
global_atomic(_swap)_ir3 obsolete and I'm planning to create generic
intrinsics to support ldg.a/stg.a as well.
Signed-off-by: Job Noorman <jnoorman@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33797>
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>
