dEQP-GLES31.functional.image_load_store.buffer.image_size.writeonly_7
produces:
t7 opcode: CP_COMPUTE_CHECKPOINT (6e) (8 dwords)
{ ADDR_0_LO = 0x15000 }
{ ADDR_0_HI = 0x5 }
0x18
{ ADDR_1_LEN = 3 }
0xf
{ ADDR_1_LO = 0x2e010 }
{ ADDR_1_HI = 0x5 }
and it was asserting due to sizedwords==7. Without the assert, we were
dereffing a len past the end of the packet. This len value we were
loading is also suspiciously not the location of the ADDR_1_LEN field in
the packet's XML. But then, the command stream at ADDR_1 was clearly 0xf
long, and that puts ADDR_1_LEN at the spot we would expect compared to
SET_RENDER_MODE's ADDR_1.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24358>
A bunch of our piglit fails were due to failing to compile shaders due to
a lack of spilling support. I used a simple shader with a large local
array with tunable size to determine the MEMSIZEPERITEM increment and the
location of HWSTACKOFFSET (matching a3xx locations). Unfortunately
fibers_per_sp I had to guess by taking a big spilling shader and cranking
it up until it rendered correctly. The value I found made HWSTACKOFFSET's
shift value match a6xx's, as a bit of confirmation.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24358>
This now matches a6xx. This major border color flakiness in deqp -- when
a prior test in the caselist bound a VS and it didn't get unbound at the
gallium level, our FS border colors would be up at offset 8 instead of 0,
and the wrong padding would make FS sampler 0 get a junk border color.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24358>
When replaying a RT pipeline, RADEON_FLAG_REPLAYABLE should be set.
The idea is that for capture, RADEON_FLAG_REPLAYABLE should be passed
when allocating a BO (ie. replay_va would be 0), and then for replay
the VA would be non-zero but the flag is also required.
Fixes
dEQP-VK.ray_tracing_pipeline.pipeline_library.configurations.multithreaded_compilation.*.
Fixes: 744357477e ("radv: Add utilities to serialize and deserialize shader allocation info")
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24543>
This change allow us to insert the MI_SEMAPHORE_WAIT before/after
specific draw call. With GTX tool, we can always update the memory
address to unblock spinning wait.
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24308>
This change allow us to insert the MI_SEMAPHORE_WAIT before/after
specific draw call. With GTX tool, we can always update the memory
address to unblock spinning wait.
v2:
- Make sure draw_call_count is thread-safe (Lionel)
- Add static inline helper (Lionel)
Signed-off-by: Sagar Ghuge <sagar.ghuge@intel.com>
Reviewed-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24308>
We don't care about how long it takes since it's nightly.
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24546>
This gives us coverage back on panvk on Bifrost. There are a lot of
fails since it was last tested though.
[daniels: Updated with new expectations.]
Acked-by: Boris Brezillon <boris.brezillon@collabora.com>
Signed-off-by: David Heidelberg <david.heidelberg@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24546>
Export winsys function symbols of target va, even if the user
links with '-Bsymbolic-functions'.
It refers target vdpau, which commit is:
8c136b53b7
("fix vdpau interop when using -Bsymbolic-functions in ldflags")
Signed-off-by: Feng Jiang <jiangfeng@kylinos.cn>
Reviewed-by: Marek Olšák <marek.olsak@amd.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23177>
The assumption is the same issue that is plaguing Cyberpunk 2077 is
also at play here. That is the XeSS library is looking for the Windows
driver binary and not finding them in the Wine/Proton distribution.
Signed-off-by: Lionel Landwerlin <lionel.g.landwerlin@intel.com>
Cc: mesa-stable
Reviewed-by: Tapani Pälli <tapani.palli@intel.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24237>
The compute scratch size is computed later because the RT stack size
can be dynamic, but the number of waves shouldn't change.
Signed-off-by: Samuel Pitoiset <samuel.pitoiset@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/24502>
