This commit introduces a new way to zero-init variables but keep the
old one to not break any existing behavior.
With this change GLSLZeroInit becomes an integer, with the following
possible values:
- 0: no 0 init
- 1: current behavior
- 2: new behavior. Similar to 1, except ir_var_function_out type are
0 initialized but ir_var_shader_out.
The rationale behind 2 is: zero initializing ir_var_shader_out can
prevent some optimization where out variables are completely eliminated
when not written to.
On the other hand, zero initializing "ir_var_function_out" has no
effect on correct shaders but typically helps shadertoy since the main
function is:
void mainImage(out vec4 fragColor) { ... }
So with this change we're sure that fragColor will always get a value.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4607>
Shared globals and glsl_zero_init can cause linker errors if the
variable is only initialized in 1 place.
This commit adds a flag to variables that have been implicitely
initialized to be able in this situation to keep the explicit
initialization value.
Without this change the global-single-initializer-2-shaders piglit
test fails when using glsl_zero_init.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4607>
This commit makes zero_init a bitfield of types of variables to zeroinit.
This will allow some flexibility that will be used in the next commit.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4607>
It's not great to use shader_info for this information, because it
might have gone through lowering of uniforms to UBOs, which can change
the number of UBOs. So let's make sure we know the size of the
UniformBlocks array from when the shader was linked instead.
Reviewed-by: Alyssa Rosenzweig <alyssa@collabora.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4734>
There is no uint to int implicit conversion in glsl, this is just
a typo in the name of this function. The correct one would be:
has_implicit_int_to_uint_conversion.
Signed-off-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com>
Reviewed-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4884>
This fixes find_and_update_named_uniform_storage() for subroutines
and also updates num_shader_uniform_components for non opaque
uniforms.
The following patch will ensure this type of bug won't happen again.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4721>
This moves the fi_types to a new mesa_private.h and removes the
imports.c file. The vast majority of this patch is just removing
pound includes of imports.h and fixing up the recursive includes.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3024>
Version 4.4 of the GLSL spec changed the definition of noise*() to
always return zero and earlier versions of the spec allowed zero as a
valid implementation.
All drivers, as far as I can tell, unconditionally call lower_noise()
today which turns ir_unop_noise into zero. We've got a 10-year-old
comment in there saying "In the future, ir_unop_noise may be replaced by
a call to a function that implements noise." Well, it's the future now
and we've not yet gotten around to that. In the mean time, the GLSL
spec has made doing so illegal.
To make things worse, we then pretend to handle the opcode in
glsl_to_nir, ir_to_mesa, and st_glsl_to_tgsi even though it should never
get there given the lowering. The lowering in st_glsl_to_tgsi defines
noise*() to be 0.5 which is an illegal implementation of the noise
functions according to pre-4.4 specs. We also have opcodes for this in
NIR which are never used because, again, we always call lower_noise().
Let's just kill the whole opcode and make builtin_builder.cpp build a
bunch of functions that just return zero.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4624>
This updates the NIR uniform linker to behave like the GLSL IR
linker and fixes a number of CTS tests once we enable the NIR
linker for glsl.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4623>
This enables gl_Layer/gl_ViewportIndex when the ext is enabled, as well
as adding the new gl_ViewportMask[] array and viewport_relative layout
qualifier for gl_Layer.
Signed-off-by: Ilia Mirkin <imirkin@alum.mit.edu>
Acked-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4529>
These macros produced a lot of errors with ubsan preventing us from
expanding the ubsan coverage on CIs.
C++ spec has such clause:
"If the prvalue of type "pointer to cv1 B" points to a B that is
actually a subobject of an object of type D, the resulting pointer
points to the enclosing object of type D. Otherwise, the result
of the cast is undefined."
Ubsan error example:
../src/compiler/glsl/builtin_functions.cpp:4945:4: runtime error: downcast of address 0x559b926abb50 which does not point to an object of type 'ir_instruction'
0x559b926abb50: note: object has invalid vptr
9b 55 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 58 ba 6a 92 9b 55 00 00 01 00 00 00
^~~~~~~~~~~~~~~~~~~~~~~
invalid vptr
#0 0x559b914dbe1a in call ../src/compiler/glsl/builtin_functions.cpp:4945
Signed-off-by: Danylo Piliaiev <danylo.piliaiev@globallogic.com>
Acked-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4129>
The use of vector.end()[-1] seems to generate warnings in Coverity about
not allowing a negative argument to a parameter. The intention with the
code snippet is just to access the last element of the vector. The
vector.back() call acheives the same thing, is clearer and will
hopefully fix the Coverity warning.
I’m not exactly sure why Coverity thinks the array index can’t be
negative. cplusplus.com says that vector::end() returns a random access
iterator and that the type of the array index operator argument to that
should be the difference type for the container. It then also says that
difference_type for a vector is "a signed integral type".
Reviewed-by: Eric Anholt <eric@anholt.net>
Let's make it clear what includes are being added everywhere, so that
they can be cleaned up.
Signed-off-by: Eric Engestrom <eric@engestrom.ch>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4360>
Without this we can incorrectly end up marking things as making
use of ARB_enhanced_layouts style packing.
Cc: 19.3 20.0 <mesa-stable@lists.freedesktop.org>
Reviewed-by: Dave Airlie <airlied@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4328>
When an ir_call is encountered that invokes a builtin, it will now try
to generate a lowered version of the builtin. This only happens if all
of the arguments to the function are lowerable. Previously the builtin
would be inlined before the lowering pass is invoked and then the
implementation would be lowered as a consequence of the pass. However
this causes problems if the builtin has multiple arguments and the
implementation has operations on only a few of the arguments before
combining it with the others. In that case the entire builtin should
only be lowered if all of the arguments are lower precision. The
previous approach would end up lowering only parts of the
implementation.
The lowered implementations are cached in a hash table in case they can
be reused.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3885>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3885>
Previously, the ir_call functions for builtin functions were replaced
with the inline implementation immediately after being added to the
instruction list. This patch replaces that with a separate pass that
lowers them after the conversion from AST to IR is complete. This will
be useful to be able to insert some handling for the precision lowering
pass before the inlining. This needs to happen because the precision
of the operations in the inlined implementation depends on the highest
precision of all of the arguments to the call.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3885>
Adds a unit tests script that invokes the standalone compiler with
--lower-precision and verifies that lowered operations are being used.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3885>
Adds a --lower-precision option that just sets the LowerPrecision
compiler option. That way it can be used in unit tests to test the
precision lowering pass.
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3885>
This works by finding the first rvalue that it can lower using an
ir_rvalue_visitor. In that case it adds a conversion to float16
after each rvalue and a conversion back to float before storing
the assignment.
Also it uses a set to keep track of rvalues that have been
lowred already. The handle_rvalue method of the rvalue visitor doesn’t
provide any way to stop iteration. If we handle a value in
find_precision_visitor we want to be able to stop it from descending into
the lowered rvalue again.
Additionally this pass disallows converting nodes containing non-float.
The can_lower_rvalue function explicitly excludes any branches
that have non-float types except bools. This avoids the need to have
special handling for functions that convert to int or double.
Co-authored-by: Hyunjun Ko <zzoon@igalia.com>
v2. Adds lowering for texture samples
v3. Instead of checking whether each node can be lowered while walking the
tree, a separate tree walk is now done to check all of the nodes in a
single pass. The lowerable nodes are added to a set which is checked
during find_precision_visitor instead of calling can_lower_rvalue.
v4. Move the special case for temporaries to find_lowerable_rvalues. This
needs to be handled while checking for lowerable rvalues so that any
later dereferences of the variable will see the right precision.
v5. Add an override to visit ir_call instructions and apply the same
technique to override the precision of the temporary variable in the
same way as done for builtin temporaries and ir_assignment calls.
v6. Changes the pass so that it doesn’t need to lower an entire subtree in
order do perform a lowering. Instead, certain instructions can be
marked as being indepedent of their child instructions. For example,
this is the case with array dereferences. The precision of the array
index doesn’t have any bearing on whether things using the result of
the array deref can be lowered.
Now, only toplevel lowerable nodes are added to the lowerable_rvalues
instead instead of additionally adding all of the subnodes.
It now also only needs one hash table instead of two.
v7. Don’t try to lower sampler types. Instead, the sample instruction is
now treated as an independent point where the result of the sample can
be used in a lowered section. The precision of the sampler type
determines the precision of the sample instruction. This also means
the coordinates to the sampler can be lowered.
v8. Use f2fmp instead of f2f16.
v9. Disable lowering derivatives calcualtions, which might not work
properly on some hw backends.
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3885>
Previously for leaf ir_instructions only the enter callback was
called. This makes it a bit difficult to make a pass that wants to
visit every instruction using a stack. Making it call the leave
callback as well makes it behave less surprisingly.
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Acked-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3885>
Adds ir_dereference::precision(). For a normal variable dereference,
the precision comes from the variable. For a record member it comes
from the field within the record. For an array it can come from
either, depending on where the underlying array is stored. The method
recursively walks the derefs until it finds one of the first two.
Reviewed-by: Kristian H. Kristensen <hoegsberg@google.com>
Reviewed-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/3885>
This function has code like:
if (0x7FD <= zExp) {
if ((0x7FD < zExp) ||
((zExp == 0x7FD) &&
(0x001FFFFFu == zFrac0 && 0xFFFFFFFFu == zFrac1) &&
increment)) {
...
return ...;
}
if (zExp < 0) {
I saw that, and I thought, "Uh... what? Dead code?" I thought it was a
bit fishy, so I grabbed the Berkeley SoftFloat Library 3e code, and
there is similar code in softfloat_roundPackToF64
(source/s_roundPackToF64.c), but it has an extra (uint16_t) cast in the
first comparison. This is basicially a shortcut for
if (zExp < 0 || zExp >= 0x7FD) {
So, having the nesting kind of makes sense. On a CPU, nesting the flow
control can be an optimization. On a GPU, it's just fail. Split the
block so that we don't need the uint16_t cast magic.
Results on the 308 shaders extracted from the fp64 portion of the OpenGL
CTS:
Tiger Lake and Ice Lake had similar results. (Tiger Lake shown)
total instructions in shared programs: 683638 -> 658127 (-3.73%)
instructions in affected programs: 666839 -> 641328 (-3.83%)
helped: 92
HURT: 0
helped stats (abs) min: 26 max: 2456 x̄: 277.29 x̃: 144
helped stats (rel) min: 3.21% max: 4.22% x̄: 3.79% x̃: 3.90%
95% mean confidence interval for instructions value: -345.84 -208.75
95% mean confidence interval for instructions %-change: -3.86% -3.73%
Instructions are helped.
total cycles in shared programs: 5458858 -> 5344600 (-2.09%)
cycles in affected programs: 5360114 -> 5245856 (-2.13%)
helped: 92
HURT: 0
helped stats (abs) min: 126 max: 10300 x̄: 1241.93 x̃: 655
helped stats (rel) min: 1.71% max: 2.37% x̄: 2.12% x̃: 2.17%
95% mean confidence interval for cycles value: -1539.93 -943.94
95% mean confidence interval for cycles %-change: -2.16% -2.08%
Cycles are helped.
Fixes: f111d72596 ("glsl: Add "built-in" functions to do add(fp64, fp64)")
Reviewed-by: Matt Turner <mattst88@gmail.com>
Tested-by: Marge Bot <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4142>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4142>
The previous two commits were just setting the scene for this change.
The mix(..., __propagateFloat64NaN(a, b), propagate) statements are not
identical in the two halves, but they are equivalent. The first clause
of the mix in the else-branch is trivally ±Inf. The first clause in the
then-branch __packFloat64(aSign, aExp, aFracHi, aFracLo). The
preceeding conditions prove that aExp=0x7ff, aFracHi=0, and aFracLo=0.
Results on the 308 shaders extracted from the fp64 portion of the OpenGL
CTS:
Tiger Lake and Ice Lake had similar results. (Tiger Lake shown)
total instructions in shared programs: 819560 -> 787258 (-3.94%)
instructions in affected programs: 757737 -> 725435 (-4.26%)
helped: 74
HURT: 0
helped stats (abs) min: 43 max: 3545 x̄: 436.51 x̃: 296
helped stats (rel) min: 3.54% max: 6.16% x̄: 4.52% x̃: 4.36%
95% mean confidence interval for instructions value: -548.42 -324.61
95% mean confidence interval for instructions %-change: -4.68% -4.37%
Instructions are helped.
total cycles in shared programs: 6817254 -> 6483227 (-4.90%)
cycles in affected programs: 6385272 -> 6051245 (-5.23%)
helped: 74
HURT: 0
helped stats (abs) min: 430 max: 33271 x̄: 4513.88 x̃: 3047
helped stats (rel) min: 4.28% max: 7.45% x̄: 5.48% x̃: 5.31%
95% mean confidence interval for cycles value: -5610.46 -3417.30
95% mean confidence interval for cycles %-change: -5.65% -5.32%
Cycles are helped.
total spills in shared programs: 591 -> 553 (-6.43%)
spills in affected programs: 591 -> 553 (-6.43%)
helped: 1
HURT: 0
total fills in shared programs: 1353 -> 1307 (-3.40%)
fills in affected programs: 1353 -> 1307 (-3.40%)
helped: 1
HURT: 0
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4142>
In one branch we know that expDiff is already positive.
In the other branch we know the expDiff is negative. Previously in that
branch the code was -(expDiff + 1). This is equvialent to (-expDiff) -
1, and since expDiff is negative, abs(expDiff) - 1.
The main purpose of this commit is to prepare for "soft-fp64/fadd: Move
common code out of both branches of an if-statement".
Results on the 308 shaders extracted from the fp64 portion of the OpenGL
CTS:
Tiger Lake and Ice Lake had similar results. (Tiger Lake shown)
total instructions in shared programs: 818246 -> 819560 (0.16%)
instructions in affected programs: 756423 -> 757737 (0.17%)
helped: 1
HURT: 73
helped stats (abs) min: 1205 max: 1205 x̄: 1205.00 x̃: 1205
helped stats (rel) min: 1.36% max: 1.36% x̄: 1.36% x̃: 1.36%
HURT stats (abs) min: 2 max: 149 x̄: 34.51 x̃: 27
HURT stats (rel) min: 0.14% max: 1.09% x̄: 0.41% x̃: 0.30%
95% mean confidence interval for instructions value: -16.56 52.07
95% mean confidence interval for instructions %-change: 0.30% 0.47%
Inconclusive result (value mean confidence interval includes 0).
total cycles in shared programs: 6816686 -> 6817254 (<.01%)
cycles in affected programs: 6384704 -> 6385272 (<.01%)
helped: 37
HURT: 37
helped stats (abs) min: 30 max: 5790 x̄: 289.05 x̃: 102
helped stats (rel) min: 0.04% max: 0.86% x̄: 0.29% x̃: 0.31%
HURT stats (abs) min: 2 max: 1020 x̄: 304.41 x̃: 232
HURT stats (rel) min: <.01% max: 1.58% x̄: 0.55% x̃: 0.43%
95% mean confidence interval for cycles value: -165.37 180.72
95% mean confidence interval for cycles %-change: <.01% 0.27%
Inconclusive result (value mean confidence interval includes 0).
total spills in shared programs: 705 -> 591 (-16.17%)
spills in affected programs: 705 -> 591 (-16.17%)
helped: 1
HURT: 0
total fills in shared programs: 1501 -> 1353 (-9.86%)
fills in affected programs: 1501 -> 1353 (-9.86%)
helped: 1
HURT: 0
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4142>
Exchanging aFracHi / bFracHi and aFracLo / bFracLo should not affect the
result of the later call to __add64.
The main purpose of this commit is to prepare for "soft-fp64/fadd: Move
common code out of both branches of an if-statement".
v2: Fix a typo in a comment. Noticed by Matt.
Results on the 308 shaders extracted from the fp64 portion of the OpenGL
CTS:
Tiger Lake and Ice Lake had similar results. (Tiger Lake shown)
total instructions in shared programs: 812094 -> 818246 (0.76%)
instructions in affected programs: 750271 -> 756423 (0.82%)
helped: 0
HURT: 74
HURT stats (abs) min: 7 max: 520 x̄: 83.14 x̃: 59
HURT stats (rel) min: 0.52% max: 1.48% x̄: 0.89% x̃: 0.84%
95% mean confidence interval for instructions value: 63.96 102.31
95% mean confidence interval for instructions %-change: 0.83% 0.95%
Instructions are HURT.
total cycles in shared programs: 6797157 -> 6816686 (0.29%)
cycles in affected programs: 6365175 -> 6384704 (0.31%)
helped: 0
HURT: 74
HURT stats (abs) min: 16 max: 1690 x̄: 263.91 x̃: 181
HURT stats (rel) min: 0.14% max: 0.68% x̄: 0.32% x̃: 0.27%
95% mean confidence interval for cycles value: 199.74 328.07
95% mean confidence interval for cycles %-change: 0.29% 0.36%
Cycles are HURT.
total spills in shared programs: 703 -> 705 (0.28%)
spills in affected programs: 703 -> 705 (0.28%)
helped: 0
HURT: 1
total fills in shared programs: 1499 -> 1501 (0.13%)
fills in affected programs: 1499 -> 1501 (0.13%)
helped: 0
HURT: 1
Reviewed-by: Matt Turner <mattst88@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/4142>
