Now that we lower FAU correctly, we don't need to write the extra move
explicitly, it will be lowered in later.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8973>
Move and reshape bi_lower_fau to bi_schedule.c. This generalizes the
pass for FAU reads, allowing copyprop to work with FAU without problems.
The pass must run immediately before scheduling. Its post-conditions are
directly specified as the scheduler's pre-conditions. It momentarily
will depend on internal scheduler predicates. It is, for all intents and
purposes, part of the scheduler. Keep it all together.
Finally, adjust the 0 handling to avoid a move at the expense of
constrained scheduling of something like `FADD.v2f16.clamp_0_1 u0, #0`
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8973>
Will prevent failures when we start using FAU together with modifiers in
a few commits.
Fixes: fc7770b1dd ("pan/bi: Add trivial rewrite helpers")
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8973>
Ensure we don't fall over if we have an instruction like
FADD.f32 u0, #0
In this case, the tuple's FAU requirement implies the instruction can be
scheduler without lowering to the FMA slot but not the ADD slot.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8973>
Uses "u3, u3[1]" syntax which is close enough to the assembly syntax
"u3.w0, u3.w1".
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8973>
I keep open-coding this, incorrectly... Since bi_index contains both
"position" and "modifier" data, it's common to want to swap the position
while preserving modifiers.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8973>
We weren't reading it anywhere outside this function, no need to keep
the extra copy of the data around. Avoids a footgun since this field
isn't even used on Bifrost.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8973>
There's no "cutoff" to worry about on Bifrost, just do the simple thing.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8973>
Will be used to generalize RMU on Midgard and also to support Bifrost's
FAU (which is essentially the same thing).
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8973>
Will fix INSTR_INVALID_OPERAND faults when we push other UBOs.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8973>
This makes UBO 0 less special, allowing us to generalize uniform
optimization. Note this disables RMU on Midgard as we're about to
rewrite the RMU mechanism.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8973>
Previously not seen since mesa/st seems to leave this zero for uniforms.
Still wrong, though.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8973>
In theory, a compute shader (or transform feedback) could write to an
SSBO, rebind as a UBO, and then read as a UBO later in the same frame.
We would need to flush in this case so we don't push stale data to the
later shader. This seems sufficiently obscure, but if this is a
performance issue in a real workload, we could emit a small compute
shader to do the copies without flushing.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8973>
LD_UNIFORM supports constant shifts and biases, just like LD, so take
advantage of that. Will avoid a regression in code quality from lowering
uniforms to UBOs.
No shader-db changes.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8973>
Helpful to disable the scheduler when debugging, so the assembly can be
compared against the NIR directly when lost in a big dEQP test.
Signed-off-by: Alyssa Rosenzweig <alyssa.rosenzweig@collabora.com>
Reviewed-by: Boris Brezillon <boris.brezillon@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8973>
this is messy due to how we have to accumulate all the query results
in some cases
future patches will break things up into utility functions for reuse
Acked-by: Erik Faye-Lund <erik.faye-lund@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8944>
Since gitlab-ci cannot merge artifact lists, and the last entry a job
extends from overwrites the artifact list, we should ensure that we
artifact meson logs via the .ci-deqp-artifacts job.
Signed-off-by: Rohan Garg <rohan.garg@collabora.com>
Acked-by: Daniel Stone <daniels@collabora.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8937>
We can't shift up 1ull by more than 63 without triggering undefined
behavior here. But in that case, doing nothing is perfectly fine.
While we're at it, remove some needless parens.
This fixes the spec@ext_timer_query@time-elapsed piglit test on top of
Lavapipe.
Reviewed-by: Hoe Hao Cheng <haochengho12907@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8977>
To not overwrite the previous ones.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8960>
The buffer is resized when too small, the 150% limit is arbitrary and
works in most cases.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8960>
The total size is computed for all available SEs which is not always 4.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Reviewed-by: Bas Nieuwenhuizen <bas@basnieuwenhuizen.nl>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8960>
There's an oddity in the .lava-test:amd64 build rules; we depend on and
use the ARM images instead of the AMD64 images. The reason for this is
kind of silly; we need the Docker image to match the architecture of the
runner, which happens to be ARM.
So this isn't at all about the target architecture, but more of a Docker
detail.
Hopefully documenting this will prevent others from spending time being
puzzled about this in the future.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8967>
The i965_asm tests are randomly timing out. I've been able to find such
timeouts only on packet runners. This change should have either of these
results:
* The timeouts actually don't happen on gstreamer runners. There will
be no more spurious pipeline failures due to them for the time being,
and we'll know the timeouts are due to some kind of packet runner
specific issue.
* The timeouts happen on gstreamer runners as well. We'll know they're
not caused by a packet runner specific issue.
Win-win.
Reviewed-by: Eric Anholt <eric@anholt.net>
Reviewed-by: Daniel Stone <daniels@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8966>
asan on llvmpipe with piglit tests/spec/arb_gl_spirv/execution/ssbo/array-indirect.shader_test
reported.
=================================================================
==3288325==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 48 byte(s) in 1 object(s) allocated from:
#0 0x7f5b2d6513cf in __interceptor_malloc (/lib64/libasan.so.6+0xab3cf)
#1 0x7f5b2a1ae810 in ralloc_size ../src/util/ralloc.c:133
#2 0x7f5b2a1ae7e1 in ralloc_context ../src/util/ralloc.c:120
#3 0x7f5b2b210177 in gl_nir_link_uniform_blocks ../src/compiler/glsl/gl_nir_link_uniform_blocks.c:585
#4 0x7f5b2af7f52d in gl_nir_link_spirv ../src/compiler/glsl/gl_nir_linker.c:614
#5 0x7f5b2a3b76fa in st_link_nir ../src/mesa/state_tracker/st_glsl_to_nir.cpp:765
#6 0x7f5b2a3ace7b in st_link_shader ../src/mesa/state_tracker/st_glsl_to_ir.cpp:65
#7 0x7f5b2a471165 in _mesa_glsl_link_shader ../src/mesa/program/ir_to_mesa.cpp:3122
#8 0x7f5b2a97a6d8 in link_program ../src/mesa/main/shaderapi.c:1311
#9 0x7f5b2a97a6d8 in link_program_error ../src/mesa/main/shaderapi.c:1419
#10 0x7f5b2a97df45 in _mesa_LinkProgram ../src/mesa/main/shaderapi.c:1911
#11 0x7f5b299b59e5 in stub_glLinkProgram /mnt/devel/gl/piglit/tests/util/piglit-dispatch-gen.c:33956
#12 0x40a71a in link_and_use_shaders /mnt/devel/gl/piglit/tests/shaders/shader_runner.c:1604
#13 0x415722 in init_test /mnt/devel/gl/piglit/tests/shaders/shader_runner.c:5225
#14 0x4164ce in piglit_init /mnt/devel/gl/piglit/tests/shaders/shader_runner.c:5597
#15 0x7f5b29a214e9 in run_test /mnt/devel/gl/piglit/tests/util/piglit-framework-gl/piglit_winsys_framework.c:73
#16 0x7f5b29a103fe in piglit_gl_test_run /mnt/devel/gl/piglit/tests/util/piglit-framework-gl.c:229
#17 0x407847 in main /mnt/devel/gl/piglit/tests/shaders/shader_runner.c:72
#18 0x7f5b2928f1e1 in __libc_start_main (/lib64/libc.so.6+0x281e1)
SUMMARY: AddressSanitizer: 48 byte(s) leaked in 1 allocation(s).
Fixes: 57239192 ("nir/linker: add gl_nir_link_uniform_blocks.c")
Reviewed-by: Caio Marcelo de Oliveira Filho <caio.oliveira@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8974>