It is more or less just a code move, but I touched
is_only_used_by_iadd(..) to match the style of the other functions in
that file.
Signed-off-by: Christian Gmeiner <cgmeiner@igalia.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30099>
Just add a && to the condition. This is more readable to me.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25590>
Only VK_NV_mesh_shader allows this kind of access, and no driver
advertises that extension anymore.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25590>
nir_lower_io_to_temporaries is now done for all stages except TCS, and
nir_lower_io_to_temporaries with a TCS is a no-op.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25590>
It seems only radeonsi and v3d sets
CAN_READ_OUTPUTS/SupportsReadingOutputs, and v3d has
lower_all_io_to_temps=true. It looks like radeonsi basically lowers the
outputs to temporaries in the backend.
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25590>
We currently assume that the instruction is already inserted and we are
optimizing it away, but in the use case I have where we are hoisting
instructions into a preamble and deduplicating as we go along, that
isn't the case. Move this responsibility onto the caller, which also
makes it a bit clearer what's going on and turns this into something
more similar to an actual set.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29873>
This allows use cases where we copy over expression trees and
deduplicate as we go along. We can use the matching instruction to build
up the rest of the expression tree.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29873>
This fixes test_gl_lower_mediump to properly test linking, which also
means we can drop all the custom nir calls as we are now simply passing
the tests directly through the real nir linking code.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30034>
This updates the scaffolding to reflect init_shader_program() and
will be required in the following patch to avoid a segfault.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/30034>
Driver with compact_arrays=false (i.e. radeonsi) is broken when
tess factor is accessed indirectly, for example:
gl_TessLevelOuter[gl_InvocationID] = xxx;
This fix use nir_vectorize_tess_levels to lower array tess factor
access into direct vector access before nir_lower_io() like clip
and cull distance way.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29799>
Fix ANV and virpipe CI test fail when nir_fixup_deref_types
is used in nir_vectorize_tess_levels by later commits.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29799>
Replace the implementation with nir_lower_array_deref_of_vec.
This will be used by compact_array=false drivers to lower indirect
tess levels array access to direct vector access too.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29799>
The standalone compiler previously ran these tests through a hacked up
partial linker. When this partial linker was recently removed from the
standalone compiler the --link option was turned on because some tests
are testing linking not just compilation. However in a future patchset
we will switch the standalone linker to use the nir linking code and
when this is done all of these shaders will need to pass full linking,
so here we update them to do so.
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29991>
There are no more users of the glsl ir at this point in the standalone compiler
anymore for these optimisations. Later patches will also switch the
standalone compiler to the nir linker.
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29991>
We move this later so that we can call glsl_to_nir() on glsl ir that
has not set the array size on unsized ifc members. Later patches will
move sizing of the arrays out of glsl ir and into the nir linker.
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29991>
812b3415 added rules for upcasts with comparisons with a variety of
types. The float & unsigned rules should be ok, but the signed integer rules are
unsound as currently implemented. This can cause end-to-end miscompiles.
I originally hit this issue while debugging a large real world OpenCL kernel. I
found the bug symptoms changed when disabling loop unrolling, which tipped me
off to a compiler bug. I've reduced it to a minimal test case. Imagine my
surprise when I find out the NIR my backend ingested was already constant folded
to be wrong.
In the minimal test case, during optimization we have NIR:
32 %6 = ....
64 %9 = i2i64 %6
64 %44 = load_const (0x0000000000000001)
1 %45 = ilt %9, %44 (0x1)
This is a simple check (int64_t)%6 < 1.
nir_opt_algebraic turns this into:
32 %6 = ...
64 %9 = i2i64 %6
64 %44 = load_const (0x0000000000000001)
64 %55 = load_const (0x0000000080000000 = 2147483648)
1 %56 = ilt %55 (0x80000000), %44 (0x1)
64 %57 = load_const (0x000000007fffffff = 2147483647)
1 %58 = ilt %57 (0x7fffffff), %44 (0x1)
32 %59 = i2i32 %44 (0x1)
1 %60 = ilt %6, %59
1 %61 = ior %58, %60
1 %62 = iand %56, %61
This pile of math constant-folds to an unconditional "false"! The problem is
%56. At first glance, INT32_MIN < 1 is true so %56 should be true. Indeed, it
should. But here's the kicker: both constants are 64-bit here, so the ilt
operation is a 64-bit comparison -- that left-hand side is INT32_MIN
zero-extended to 64-bit for the signed comparison at 64-bit. So in fact, it
evaluates to false, causing the whole expression to go false. If we're going to
do a 64-bit comparison for %56, then we need to sign-extend the bound. So we'll
just adjust the Python and be on our way, right?
Unfortunately the issue is deeper. According to the comment in the generated
nir_opt_algebraic.c file, the guilty algebraic rule is:
('ilt', ('i2i64', 'a@32'), '#b') =>
('iand', ('ilt', -2147483648, 'b'), ('ior', ('ilt', 2147483647, 'b'), ('ilt', 'a', ('i2i32', 'b'))))
From a Python perspective? That rule is correct. -2147483648 < 1 is a true
statement. Adjusting the Python rule is not the appropriate solution here, since
the issue is more fundamental and might affect other rules. The real problem is
the translation of that Python replacement tree into C, incorrectly
zero-extending -2147483648 into 0x0000000080000000 instead of sign-extending to
0xffffffff80000000.
Crawling down the rabbit hole of the generated algebraic file, we see the
constant encoded as:
{ .constant = {
{ nir_search_value_constant, 64 },
nir_type_int, { -0x80000000 /* -2147483648 */ },
} },
NIR correctly translates the negative constant to a C level negate operation of
its absolute value. This maps to the correct sign-extension...
...for all constants except for INT_MIN. Because that constant lacks a ULL
suffix, it is a 32-bit integer. And for this integer (only), negating it hits
signed integer overflow (UB!) and then we end up with an effective
zero-extension when going to 64-bit.
This patch fixes the end-to-end miscompile.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Closes: #11402
Cc: mesa-stable
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29952>
Prevents regressions when removing input modifiers from a == 0.0.
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Reviewed-by: Ian Romanick <ian.d.romanick@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29467>
I see people open-coding this all over the tree and it makes nir_builder loops
really annoying. Make them slightly less annoying with a helper.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Daniel Schürmann <daniel@schuermann.dev>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29877>
For preambles, we don't actually care which invocation we get, so we
don't have to enable helper invocations when the preamble uses "getone."
Introduce a new intrinsic with the right semantics and plumb it through.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29914>
indirect store lowering will use if/else which changes
the control flow of the shader.
Fixes: 110887de2b ("nir: Add a new pass to lower array dereferences on vectors")
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29894>
indirect store lowering will change control flow,
so we should not preserve control flow metadate
when it's present.
Fixes: 35b8f6f40b ("nir: Add a new pass to lower array dereferences on vectors")
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29894>
The number of components for the second source is -1 to avoid validation of
its value. Some supported configurations will have the component count of
that matrix different than the others.
Reviewed-by: Caio Oliveira <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28834>
Compiler can't know that array_size() of the offsets parameter in
textureGatherOffsets is (at most) 4, so use a MIN2() to make the limit
visible. Just adding an assert() gets ignored in Release builds.
This fixes the following warning in Release compilation:
```
../src/compiler/glsl/glsl_to_nir.cpp: In member function ‘virtual void {anonymous}::nir_visitor::visit(ir_texture*)’:
../src/compiler/glsl/glsl_to_nir.cpp:2453:41: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
2453 | instr->tg4_offsets[i][j] = val;
| ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~
In file included from ../src/compiler/glsl/glsl_to_nir.h:31,
from ../src/compiler/glsl/glsl_to_nir.cpp:29:
../src/compiler/nir/nir.h:2470:11: note: at offset 8 into destination object ‘nir_tex_instr::tg4_offsets’ of size 8
2470 | int8_t tg4_offsets[4][2];
| ^~~~~~~~~~~
../src/compiler/glsl/glsl_to_nir.cpp:2453:41: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=]
2453 | instr->tg4_offsets[i][j] = val;
| ~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~
../src/compiler/nir/nir.h:2470:11: note: at offset 9 into destination object ‘nir_tex_instr::tg4_offsets’ of size 8
2470 | int8_t tg4_offsets[4][2];
| ^~~~~~~~~~~
```
This is from: `gcc (GCC) 14.1.1 20240522 (Red Hat 14.1.1-4)`.
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29508>
This fixes several downcasting of address to object types when the
original object types were either different or invalid.
This has been detected throught Undefined Behaviour Sanitizer (UBSan).
An example of such issue were:
`downcast of address 0x55559c0cbcc0 which does not point to an object of
type 'ir_variable' 0x55559c0cbcc0: note: object is of type 'ir_constant'
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29772>
Ensure unsigned integers are used instead of signed ones when performing
left bit shifts.
This has been detected by the Undefined Behaviour Sanitizer (UBSan).
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29772>
Undefined Behaviour Sanitizer (UBSan) detected the following when
running testing `dEQP-VK.graphicsfuzz.cov-fold-negate-min-int-value`:
`negation of -2147483648 cannot be represented in type 'int'; cast to an unsigned type to negate this value to itself`
SPIR-V spec states that OpSNegate(0x80000000) has to return 0x80000000;
in our case, -2147483648 should be -2147483648.
While this is not causing any issue because compilers seem to be
behaving like that, it is still undefined behaviour, so it expects to be
this handled explicitly, which is the purpose of this commit.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Signed-off-by: Juan A. Suarez Romero <jasuarez@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29772>
