All this code does is reinitialise the values to what the original
ir_variable() call already set them too. This code is very old dating
to the initial glsl compiler support, it has probably been unrequired
for a long time now.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22846>
All this does is compilcate things such as forcing us to set
var->data.always_active_io in the glsl linker. Just let NIR clean
these up for us instead.
A Zink test hits a new assert but this is not a regression it just
uncovers an existing mesa bug.
Reviewed-by: Emma Anholt <emma@anholt.net>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22846>
These are currently removed by the GLSL IR DCE pass but we will
drop that in a following patch. Also there are scenarios where these
might not be detected as unused until the NIR optimisations have
been run so we really need to do it here too anyway.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Emma Anholt <emma@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22846>
Move all these lowering calls into the linker where they belong. This
makes future changes to the linker more flexible and is needed to
allow some following patches as we need to call things in a specific
order.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/22846>
Just like we do for everything else here, since we are going to realloc
them again right below. Notice this is not exactly a memory leak, since
all these arrays are allocated with ralloc using v3d_compile as context,
so all allocations will be eventually freed when the context is destroyed.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24001>
Indeed, util_blitter_clear() requires a call to
util_blitter_save_fragment_constant_buffer_slot(),
but most other blitter functions do not.
For instance, this issue is triggered with:
"piglit/bin/object-namespace-pollution glDrawPixels buffer -auto -fbo"
while setting GALLIUM_REFCNT_LOG=refcnt.log.
Fixes: 03bc7503d4 ("radeonsi: save the fs constant buffer to the util blitter context")
Signed-off-by: Patrick Lerda <patrick9876@free.fr>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23856>
Dead writes can lead to problems with regalloc, so add a safety assert
to catch such cases in the vertex shaders at least in the meantime.
Additionally we could think there are no readers due to some shortcoming
of out dataflow analysis or some other bug which we would also like to
know about.
Reviewed-by: Filip Gawin <filip.gawin@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23927>
We have much better regalloc in the backend, and additionally having
a close to ssa form means some optimizations can be more effective.
RV370:
total instructions in shared programs: 82500 -> 81645 (-1.04%)
instructions in affected programs: 32147 -> 31292 (-2.66%)
helped: 396
HURT: 1
total temps in shared programs: 12355 -> 12465 (0.89%)
temps in affected programs: 368 -> 478 (29.89%)
helped: 5
HURT: 96
GAINED: shaders/trine/vp-237.shader_test VS
GAINED: shaders/trine/vp-79.shader_test VS
RV530:
total instructions in shared programs: 130706 -> 129684 (-0.78%)
instructions in affected programs: 40902 -> 39880 (-2.50%)
helped: 428
HURT: 1
total temps in shared programs: 16811 -> 16920 (0.65%)
temps in affected programs: 421 -> 530 (25.89%)
helped: 7
HURT: 89
The instruction decrease is from the channel merging pass which can be
much more agressive when we have ssa-like form.
The temp regressions are cases where we merge something like
3: MAD output[1].xy, const[8].xy__, input[1].ww__, temp[0].xy__;
....
12: MOV output[1].zw, none.__00;
We always merge the first instruction into the second one, which means
the liverange for temp[0] will be unnecessarily extended here.
This can be fixed with the following draft MR
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19790
however if we ever get a VS pair scheduling support this will be solved
as well as a consequence, so let it be for now.
Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/7693
Reviewed-by: Filip Gawin <filip.gawin@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23927>
This is now done in NIR. The remaining one for ADD + 0 to MOV is kept
until we move some remaining part of FS lowering to NIR.
There single regressions is in one d3d->glsl shader from Wine.
Wine sets invariant for glPosition which translates to exact bit for all
calculations leading to it (or the TGSI PRECISE flag). r300 backend
ignores is completelly, so removing the backend optimizations should
even make us more correct in this regards.
RV530:
total instructions in shared programs: 130705 -> 130706 (<.01%)
instructions in affected programs: 16 -> 17 (6.25%)
helped: 0
HURT: 1
RV370: no change
Reviewed-by: Filip Gawin <filip.gawin@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23927>
This lowers some of the bool-producing comparisons and following bcsels
if the bool comparison results is only used in the bcsel.
This is a temporary solution before we can fork ntt and optimize
the pass sequence there. Right now if we have something like
bcsel(a,b,0.0) we lower it to flrp in nir_lower_bool_to_float. The
flrp goes to backend where it will be lowered to 2 MADs. However in this
case with one of the arguments being a constant one MAD is enough. The
backend can figure this out in the constant folding pass, however this
is actually one of the last things we need it for. So if we do early
translation of the bcsels, than the algebraic pass can clean it up and
we can remove more backend code in the next patch.
no significant change with RV370 shader-db:
total instructions in shared programs: 82497 -> 82496 (<.01%)
instructions in affected programs: 1029 -> 1028 (-0.10%)
helped: 4
HURT: 3
total temps in shared programs: 12351 -> 12355 (0.03%)
temps in affected programs: 10 -> 14 (40.00%)
helped: 0
HURT: 4
Reviewed-by: Filip Gawin <filip.gawin@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23927>
They will get translated to read from random register otherwise, which is
not problematic per se, but they will not be regalloced and if the
initial register index was too high, we can fail the shader compilation
because we think we run out of registers.
Almost no effect with shader-db on RV530:
total instructions in shared programs: 130707 -> 130705 (<.01%)
instructions in affected programs: 1012 -> 1010 (-0.20%)
helped: 2
HURT: 1
Reviewed-by: Filip Gawin <filip.gawin@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23927>
For stages where the capture/replay handle is only known after compiling
and uploading the shader, the shader needs to be relocated to the VA
corresponding to the capture/replay address.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23516>
radv_shader_nir_to_asm actually had 3 functions: compiling the NIR to
asm, uploading the shaders and generating debug info for them.
This reduces the functionality of radv_shader_nir_to_asm to only compile
NIR to asm. Uploading the shader and generating debug info is split into
separate functions.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23516>
