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>
"Rewrite and remove" is a super common idiom in NIR passes. Let's add a helper
to make it more ergonomic.
More the point, I expect that /most/ of the time when a pass rewrites uses, they
also want to remove the parent instruction. The principle reason not to is
because it takes extra effort to add in the nir_instr_remove and nir_opt_dce
will clean up after you eventually, right? From a compile time perspective, it's
better to remove earlier to reduce the redundant processing between the pass and
the next DCE run. So ... we want to be doing *more* removes. From a UX
perspective - the way to nudge devs towards that is to make the
preferred "rewrite-and-remove" pattern more ergonomic than the "rewrite but
keep". That justifies the simple "replace" name rather than something silly like
"rewrite_uses_and_remove".
---
Something else I've wanted for a while.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29817>
Yes, we're losing precision if this assert fails and it's wrong. It's also
necessary to implement GL in a reasonable way on Asahi. Remove the assert that
was recently added and add more comment context on the mess.
Fixes debug build regression on asahi:
dEQP-GLES3.functional.vertex_arrays.single_attribute.normalize.int.components4_quads1
Fixes: 22f1b04a99 ("nir/format_convert: Assert that UNORM formats are <= 16 bits")
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Suggested-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29820>
The original code has a private helper called in one place doing a
lookup that it's parent has already done, which could be null, except
that the parent verified that it isn't. Instead, let's pass the pointer
from the parent and assert it's non-null in the child for good
measure/documentation.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29666>
Snce the *args parameter was added it's assumed to be non-null. If it is
null then the function is going off to UB land. As such, a later check
added for args being NULL is useless, and confuses coverity.
fixes: 3a752256f5
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29664>
Here we move anything that expects the IR to have already been linked
so that in a future patch we can use glsl_to_nir() to convert IR that
has only been compiled.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29761>
There's no good reason for this to be header-only besides laziness on my
part when I first wrote a few "small" helpers. Some of those are pretty
good sized and don't need to be inlined.
Keeping the original copyright since this is just moving code.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28793>
As long as drivers implement an fmin/fmax that do the right thing with
NaN, there's no reason for the integer comparison.
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28793>
I have no idea why I flipped the order of these to checks vs. the C
code when I wrote the NIR helper. We need to deal with NaN first or
else the fmin will smash NaN to MAX_RGB9E5 and it won't get handled as
NaN.
Fixes: 9981709d8f ("nir/format_convert: Add a function to pack RGB9_E5 formats")
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28793>
I thought this was just the funny GLES spelling of the extn name, but
there's also some ESSL bits you need to add. Most of which you could
probably yoink from the old Unity glsl-optimizer (which itself yoinked
most of the GLSL compiler from Mesa):
94a9b2959b
Signed-off-by: Adam Jackson <ajax@redhat.com>
Co-authored-by: Mike Blumenkrantz <michael.blumenkrantz@gmail.com>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/6691>
lima was the last user of this feature so lets remove it. This will
allow us to drop more soon to be unused glsl ir code once full nir
linker support lands.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29519>
The support is incomplete and largely untested, but more importantly
glsl ir is depreciated at this point. This feature was added to support
building additional passes but that shouldn't ever be needed from here
on.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29469>
Since nir_opt_varyings requires scalar IO and thus all drivers have to
scalarize it, this gives the option to re-vectorize IO after that.
Reviewed-by: Timur Kristóf <timur.kristof@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29406>
This came up while reviewing
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29398 ... Possibly
this intrinsic should be renamed to load_smem_constant_amd for consistency with
load_global_constant. But if we're not going to convey constantness in the
intrinsic name, let's at least document the restriction, because NIR's optimizer
relies on it.
(I didn't inspect every call site, but it looks like load_smem_amd is just used
for descriptor loads so there's no bug to fix.)
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Rhys Perry <pendingchaos02@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29743>
Most passes want to preserve this specific combination of metadata, so let's add
an alias for the combination. The alias communicates that the control flow graph
is preserved, rather than a particular statement about e.g. dominance
preservation.
You don't need to understand dominance to write a simple
nir_shader_instructions_pass. And since you were going to cargo cult the
metadata anyway, this way you'll cargo cult a version you're more likely to
understand.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Acked-by: Karol Herbst <kherbst@redhat.com>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29745>
This flag is mostly redundant with uses_discard and was only
introduced to implement demote with LLVM when it didn't have
that intrinsic.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27617>
The semantics of discard differ between GLSL and HLSL and
their various implementations. Subsequently, numerous application
bugs occurred and SPV_EXT_demote_to_helper_invocation was written
in order to clarify the behavior. In NIR, we now have 3 different
intrinsics for 2 things, and while demote and terminate have clear
semantics, discard still doesn't and can mean either of the two.
This patch entirely removes nir_intrinsic_discard and
nir_intrinsic_discard_if and replaces all occurences either with
nir_intrinsic_terminate{_if} or nir_intrinsic_demote{_if} in the
case that the NIR option 'discard_is_demote' is being set.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27617>
Non-volatile gl_HelperInvocation after demote is undefined.
In order to avoid application bugs, make it volatile if we use demote.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Faith Ekstrand <faith.ekstrand@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/27617>
We need to check the sample too. fixes on Honeykrisp with MSAA storage images:
dEQP-VK.robustness.robustness2.bind.notemplate.r32i.dontunroll.nonvolatile.storage_image.fmt_qual.img.samples_4.2d_array.comp
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Iago Toral Quiroga <itoral@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/29741>
