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>
Otherwise this leads to a use-after-free
dEQP-VK.synchronization.op.single_queue.fence.write_fill_buffer_read_ssbo_vertex.buffer_16384
when run after any test using a ubo in the fragment shader.
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8912>
item->base will be freed for the NULL reference write
so just use a temporary to avoid it.
This was found with asan and lavapipe:
dEQP-VK.api.copy_and_blit.core.blit_image*
Reviewed-by: Adam Jackson <ajax@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8912>
The debug resource tracking triggers an asan warning, add a mutex
around it to avoid multi-thread failures with vulkan CTS test:
dEQP-VK.api.object_management.multithreaded_per_thread_device.buffer_uniform_small
Reviewed-by: Adam Jackson <ajax@redhat.com>
Reviewed-by: Eric Anholt <eric@anholt.net>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8912>
Starting with GL 3.0 it's legal to have no drawable bound to the current
context. GLX_SGI_video_sync doesn't take a drawable for an argument so
it implicitly operates on... something. NVIDIA's driver throws
GLX_BAD_CONTEXT for GetVideoSync, but WaitVideoSync seems to actually
wait for the next MSC on the context's screen. We could work around this
by internally creating/destroying a GLXWindow for the root window, but
for Xwayland there's not necessarily a good answer it can return.
Just throw GLX_BAD_CONTEXT for both.
Fixes: mesa/mesa#1207
Reviewed-by: Michel Dänzer <mdaenzer@redhat.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8334>
Instead of calling iris_sample_with_depth_aux right before a sample
operation, call it at resource creation time. Unifies the code which
ensures that it's okay to sample with HiZ.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8853>
Instead of storing a bitfield of which resource levels will be accessed
with HiZ, compute this information on-demand. Makes the iris_resource
struct more generic.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8853>
Before this commit, various functions avoided calling
iris_resource_get_aux_state and iris_resource_set_aux_state for depth
buffers which lacked full HiZ support at certain levels. This was
because:
1. Some callers of prepare/finish neglected to use ISL_AUX_USAGE_NONE
for the levels which lacked full HiZ support.
2. The assertions within the getter and setter were too strict.
Now that both of these issues have been resolved, there's no obvious
reason to try to avoid these function calls. Delete the code for
avoiding them.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8853>
The aux state getter and setter currently assert
iris_resource_level_has_hiz() for depth surfaces.
This assertion is too strict however. In some cases where the assert
would fail, we can still correctly describe the aux state with the ISL
enums (using ISL_AUX_STATE_AUX_INVALID, for example).
When HiZ is enabled on a resource but disabled for a given level, allow
the getter to be called and allow the setter to set aux states that lack
compression. Enables code simplifications later on.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8853>
Prepare/finish a framebuffer's depth buffer with the aux usage that's
appropriate for the given miplevel instead of wrongly assuming that
compression is always enabled. Enables code simplifications later on.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8853>
Set dst_aux_usage to ISL_AUX_USAGE_NONE for the depth buffer blit if the
level doesn't fully support HiZ. Enables removing the code that masked
this issue later on.
Reviewed-by: Kenneth Graunke <kenneth@whitecape.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/8853>
