in a sequence where a driver saves 0 sampler/views before calling
u_blitter, the previous state of having 0 sampler/views bound would
not be restored as expected, resulting in stale sampler/views which
could affect behavior before new sampler/views were bound
cc: mesa-stable
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16178>
The NIR path through the frontend is effectively the only one maintained
for a quite a while now. We can see that effect with !15540, where the
TGSI generation path was regressed to assertion fail on real-world
shaders, and nobody noticed until I came along trying to test the
NIR-to-TGSI transition.
We already have a nir_to_tgsi() call for translating NIR representation
for ARB programs into TGSI before handing them off to the driver. This
change makes that path get taken for GLSL programs as well.
This is the minimum change to get all the drivers on NIR from GLSL, to
give a simple commit to bisect too. The dead code removal comes next.
Now every driver benefits from shared NIR optimizations for GLSL, and we
can start retiring GLSL optimizations.
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Reviewed-by: Timothy Arceri <tarceri@itsqueeze.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8044>
it's been flaking with "2022-05-05 16:29:49.055151: [0m[31mERROR - Failure
getting run results: parsing results: Reading from dEQP: timed out waiting
for fd to be ready (See \"//results/c32.r1.log\")" and a pile of missings
since the brief "whoops, HW CI failed to listen to the test exit code"
regression.
The only ways I know of to hit this case would be:
1) The deqp binary abruptly wedges on its own. This happens with NFS
failures sometimes, but the rest of the run went fine and we never got the
kernel complaining about NFS, so that seems unlikely.
2) The stderr pipe filled up before stdout was completed, and deqp got
wedged trying to output stderr (happens sometimes when you do like
NIR_DEBUG=print in your run).
Both of these seem unlikely, given that we've got a big .qpa file that
made it all the way to writing out test case durations at the end of the
run before abruptly terminating. Why didn't we have at least some of the
test results parsed?
The next deqp-runner release we integrate will solve #2, and cleans up
these error paths a bunch, so I'm hoping we get more information soon.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16350>
Required to avoid tiler heap out-of-memory condition on Valhall on tests
including:
dEQP-GLES31.functional.draw_indirect.compute_interop.large.drawelements_combined_grid_1200x1200_drawcount_8
This test passes on Bifrost without the fix because varyings are only allocated
from the tiler heap on Valhall.
Minimal perf or memory usage impacted is expected, as even old versions of
panfrost.ko support growable memory.
Signed-off-by: Alyssa Rosenzweig <alyssa@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16330>
Until now we have been enabling binning sync if we found a barrier
involving geometry stages (a bcl barrier), however, if the actual
binning shaders involved with the job don't access any external
buffers or images there is no reason to sync at the binning stage.
In this patch we don't immediately consume the bcl barrier flag from
the command buffer state when we create a new job. Instead, we check
this state when we are about to emit a draw call by checking if the
shaders involved with binning may access external resources, such as
vertex buffers, UBOs, or textures. If none of the draw calls in the
job use binning shaders that access external resources then we never
enable binning sync for the job.
It is possible that a binning shader uses resources that are not
synchronized through a barrier though, so we keep track of the
access masks used with barriers for both buffers and images separately
to better identify if the binning shader is affected by the barrier.
If a serialized job never consumes the bcl barrier flag because none
of its draw calls ever required a bcl sync, then the flag will be
cleared when the job is finished.
Reviewed-by: Alejandro Piñeiro <apinheiro@igalia.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16322>
For some days, the CI was bypassing LAVA and bare-metal jobs due to an
issue in the init-stage2.sh script. After the fix the neverball trace on
panfrost-t860 is producing a different image, due to a bugfix in
Mesa itself driver. This commit updates the neverball trace on that
device.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16325>
After a LAVA job submitter rework, the init-stage2.sh was changed to be
compatible with new LAVA job definitions, but the result from the script
represented by `HWCI_TEST_SCRIPT` variable is obfuscated by the `set -e`
command. So when the test script fails, `set` will override the exit
code and the jobs will pass when they should fail.
Signed-off-by: Guilherme Gallo <guilherme.gallo@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16325>
Mike Blumenkrantz