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>
The dumb buffer backing the renderonly_scanout is only destroyed if the
refcount reaches zero. If a driver does not correctly initialize the
refcount, the refcount may be negative and the buffer will never be
freed.
Add an assert to ensure that drivers correctly initialize the refcount.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23743>
If the GEM is closed before setting the BO in the sparse array to zero,
a newly allocated GEM may be associated with a stale BO that is left in
the cache reusing an old BO.
Zero the BO before closing the GEM to make sure that the BO is removed
from the cache and won't be associated with a different GEM.
Signed-off-by: Michael Tretter <m.tretter@pengutronix.de>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23744>
Account for the possibility that the scissor is outside the render area. Fixes
the usual assertion fail:
glcts: ../src/gallium/drivers/asahi/agx_state.c:1015:
agx_upload_viewport_scissor: Assertion `maxx > minx && maxy > miny' failed.
on the following dEQP tests with my conformance build:
dEQP-GLES3.functional.fragment_ops.scissor.outside_render_line
dEQP-GLES3.functional.fragment_ops.scissor.outside_render_point
dEQP-GLES3.functional.fragment_ops.scissor.outside_render_tri
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23998>
The GPU ABI requires varyings to be grouped as follows:
- Position
- Smooth shaded fp32
- Flat shaded fp32
- Linear shaded fp32
- Smooth shaded fp16
- Flat shaded fp16
- Linear shaded fp16
- Point size
Use the flat shaded mask info we now have in the vertex shader key to
sort things properly, and pass the counts to the hardware.
FP16 is still TODO.
Signed-off-by: Asahi Lina <lina@asahilina.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23998>
We need to propagate shading model metadata from the FS to the VS in
order to correctly lay out the uniforms in the right order. This means
we need VS variants depending on this data.
We could use the existing shader info structure, but that applies to
compiled shaders which would introduce a dependency from the VS compile
to the FS compile. This information does not change with FS variants, so
we can introduce an agx_uncompiled_shader_info structure and gather it
early at precompilation time.
Signed-off-by: Asahi Lina <lina@asahilina.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23998>
