The optimizer shouldn't consider a lanemask to be a uniform boolean unless
it's either 0 or -1. Optimizations involving s_not/s_xor might not work
properly otherwise.
No fossil-db changes (navi21).
Signed-off-by: Rhys Perry <pendingchaos02@gmail.com>
Reviewed-by: Georg Lehmann <dadschoorse@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36177>
NULL was forgotten.
This issue was detected by the gcc sanitizer.
==30873==ERROR: AddressSanitizer: global-buffer-overflow on address 0x7f94f9ad14b0 at pc 0x7f94f04905bc bp 0x7ffe3b1ebcf0 sp 0x7ffe3b1ebce8
READ of size 8 at 0x7f94f9ad14b0 thread T0
#0 0x7f94f04905bb in loader_bind_extensions ../src/loader/loader.c:783
#1 0x7f94ee656232 in setupLoaderExtensions ../src/gallium/frontends/dri/dri_util.c:88
#2 0x7f94ee656232 in driCreateNewScreen3 ../src/gallium/frontends/dri/dri_util.c:111
#3 0x7f94f98d9a14 in dri2_create_screen ../src/egl/drivers/dri2/egl_dri2.c:774
#4 0x7f94f98dfbea in surfaceless_probe_device ../src/egl/drivers/dri2/platform_surfaceless.c:298
#5 0x7f94f98dfbea in dri2_initialize_surfaceless ../src/egl/drivers/dri2/platform_surfaceless.c:390
#6 0x7f94f98dbc4f in dri2_initialize ../src/egl/drivers/dri2/egl_dri2.c:861
#7 0x7f94f98dbc4f in dri2_initialize ../src/egl/drivers/dri2/egl_dri2.c:832
#8 0x7f94f9892843 in eglInitialize ../src/egl/main/eglapi.c:696
Fixes: 56ed5cf1bb ("dri: Get rid of __DRIbackgroundCallableExtension")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Eric Engestrom <eric@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36255>
* use tex builder (what I came for)
* use nir_create_variable_with_location
* drop redundant internal = true's, the shaders are already initialized that way
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36050>
this is already set when building the gs copy shader since it is a nir_builder
simple shader
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36050>
* use the tex builder (what I came for)
* use fmul_imm and fix weird wrapping
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36050>
for intrinsics, we have these really nice builders using designated initializers
+ macros to specify optional indices. texture instrs have even more craziness
involved, but we can do the same trick. this commit takes the existing "fixed
form" deref-centric tex builders and generalizes them to work with non-deref
textures, making it useful also for GL and late VK passes, while providing an
API that strives to be ergonomic and consistent.
this series only implements a subset of possible texture operations for now, but
more generalizing could be added as people have need.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Konstantin Seurer <konstantin.seurer@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36050>
mathemtically, associativity is only defined for binary operations. I have no
idea what "associativity" would even mean for imad. I can kinda see the idea for
iadd3 but iadd3 should not be formed until after reassociating adds so the point
is moot. Unmark the
"associative" ternary operations, and assert that associativity implies binary.
nothing uses associativity yet, so this doesn't cause any functional change.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36257>
nothing currently uses the associative flag, but they will change soon. we need
to stop incorrectly marking fmul/fadd/etc as associative, because they're not,
but they almost are. distinguish these properties so we can correctly
handle floating point rules without any opcode-based special casing.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36257>
this chain of fmul is deliberately chosen for floating point precision
reasons, it needs to be exact, or else we might try to reassociate it
and break subnormal handling.
avoids regressing dEQP-VK.glsl.builtin.precision.ldexp_subnormals.*
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Reviewed-by: Mel Henning <mhenning@darkrefraction.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36257>
As seen in the Vivante kernel driver context init, GPUs with the icache
feature have a new set of states to specify the shader ranges. While the
old state still seems to work, it limits the size of the shader that can
be executed to 64K instructions. The new range states holds up to 20 bits
according to the comment in the Vivante kernel driver, which allows up
to 1M instructions.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36114>
Cores with unified instruction memory get the start and end points of
the shaders via the shader range registers. Don't emit the unnecessary
START_PC and END_PC states on those cores.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36114>
When writing new shader instructions through the unified state area
we must tell the GPU which caches to flush by setting the appropriate
code steering bit. Failing to do this doesn't seem to have much of an
effect when only loading shaders through the state memory, but when
toggling between using icache (as in load shaders from memory) and
loading instructions from the state area, this fixes severe corruption
and GPU hangs due to old code being executed.
Programming the steering bits is only needed for GPUs with either
unified instruction or unified uniform states.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36114>
Bit 0 of the SH_CONTROL register does not control uniform cache
flushes so stop touching this bit when updating the uniforms.
While it is harmless to change the bit at this time in the emit
sequence, it's confusing and not needed.
Signed-off-by: Lucas Stach <l.stach@pengutronix.de>
Reviewed-by: Christian Gmeiner <cgmeiner@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/36114>
