The address itself was already stable assuming that the memory itself was
allocated with capture/replay. Enable the feature flag and add an equality
check to return VK_ERROR_INVALID_OPAQUE_CAPTURE_ADDRESS_KHR on mismatch.
Tested with:
- dEQP-VK.ray_tracing_pipeline.capture_replay.*
- q2rtx gfxrecon replays correctly without major errors.
* There are debug logs about VkBuffers missing opaque address
for unknown reason, however the AS part is confirmed to be correctly
captured.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19841>
With the new memory type, this test timeout most of the time but it
always pass.
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/19808>
A valid but NULL descriptor set indicates a descriptor buffer.
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/19808>
These would be only exposed for descriptor buffers which need to be
CPU accessible and because descriptor pointers are 32-bit.
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/19808>
Fix defect reported by Coverity Scan.
Resource leak (RESOURCE_LEAK)
leaked_storage: Variable nresource going out of scope leaks the storage it points to.
Fixes: 7522f4f714 ("asahi: Make resource creation code modifier-aware")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19889>
Found when 16bit vec3 varying with llvm14 (not found
when llvm15), one 32bit vec4 slot is filled like this:
vec3[0] | undef
vec3[1] | undef
vec3[2] | undef
undef | undef
LLVM error is for the elements with undef:
%287 = insertelement float %280, half %279, i64 0
After this change, we get:
%287 = insertelement <2 x half> %280, half %279, i64 0
Fixes: 279eea5bda ("amd/llvm: Transition to LLVM "opaque pointers"")
Reviewed-by: Pierre-Eric Pelloux-Prayer <pierre-eric.pelloux-prayer@amd.com>
Signed-off-by: Qiang Yu <yuq825@gmail.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19848>
Fix defect reported by Coverity Scan.
Resource leak (RESOURCE_LEAK)
leaked_storage: Variable rsc going out of scope leaks the storage it points to.
Fixes: 01964625eb ("asahi: Implement agx_resource_from_handle")
Signed-off-by: Vinson Lee <vlee@freedesktop.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19887>
Now that we have the new tilebuffer infrastructure in place, all renderable
formats should be working.
This reverts commit 32ab63b4fcaaaf832d549ddcf7b3a225c5f73df4.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19871>
Flag day change to replace the previous hardcoded background/end-of-tile shaders
and the API-style load/store_output in fragment shaders with the generated
shaders and lowered *_agx intrinsics. This gets us working non-UNORM8 render
targets and working MRT. It's also a step in the direction of working MSAA but
that needs a lot more work, since the multisampling programming model on AGX is
quite different from any of the APIs (including Metal).
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19871>
With multiple render targets, it's not practical to generate all
variants of the background and end-of-tile programs at start up. Rather
than trying, add a hash table of meta program keys to background
programs, and compile variants as they're needed.
With the new infrastructure, it's sensible to handle clears with the
same code path as reloads. In addition to getting us closer to multiple
render target support, this gets us support for non-RGBA8 render
targets, as the u8norm tilebuffer format was baked into the hardcoded
clear shader and store shaders used before.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19871>
Multisampling uses different values of the dimension enum in tandem with a new
samples field. Handle this in agx_pack_texture (split off here) so we can use
the new functionality for texture descriptors in reloads too.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19871>
The compiler can't handle load/store_output directly for nontrivial tilebuffer
layouts. Add a NIR pass to lower these intrinsics, applying a given layout.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19871>
This hw instruction writes out an entire block from the tilebuffer to an
attached render target (PBE descriptor). It is used (only?) in end-of-tile
shaders to implement write out. We need to handle it in the compiler as a
prerequisite to compiling end-of-tile shaders ourselves, instead of hardcoding.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19871>
Mutlisampled texture fetch (txf_ms) is encoded like regular txf. However, we now
need to pack the multisample index in the right place, which we do by extending
our existing NIR texture source lowering pass. 2D MS arrays use a new value of
dim which requires tweaking the encoding slightly. Otherwise, everything is
bog standard.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19871>
It appears that multisampled textures on AGX have all samples of the same pixel
contiguous in memory, effectively using the layout of a single-sampled texture
with a larger block size. Handle in ail.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19871>
The track_alloc and track_free symbols are used, we need to link them in.
Depending on build flags / environment / etc, fixes the potential build error
hit by a CI job:
mold: error: undefined symbol: agxdecode_track_alloc
>>> referenced by agx_device.c
>>> src/asahi/lib/libasahi_lib.a(src/asahi/lib/libasahi_lib.a.p/agx_device.c.o):(agx_shmem_alloc)>>> referenced by agx_device.c
>>> src/asahi/lib/libasahi_lib.a(src/asahi/lib/libasahi_lib.a.p/agx_device.c.o):(agx_bo_create)
mold: error: undefined symbol: agxdecode_track_free
>>> referenced by agx_device.c
>>> src/asahi/lib/libasahi_lib.a(src/asahi/lib/libasahi_lib.a.p/agx_device.c.o):(agx_bo_unreference)
...when trying to link with libasahi_lib without libasahi_decode for unit tests.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19871>
This avoids exposing the ISA-internal agx_format to the driver, instead hiding
it behind a real PIPE_FORMAT. This lets us use real pipe formats in formatted
intrinsics in NIR, which is convenient; it will allow us to simplify the
compiler/driver ABI; and it lets us use common format helpers (e.g.
util_format_get_blocksize) for the internal formats in driver lowering.
Signed-off-by: Alyssa Rosenzweig <alyssa@rosenzweig.io>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19871>
On blob v512.490, using WRAP_GPU_ID to fake GPU versions, I see 0x41 used
everywhere, except for BLIT_OP_SCALE on a630. Define the magic number in
dev info so it can be reused in the two places that set the
non-BLIT_OP_SCALE value.
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19794>
For some reason the setup that comes after the scratch buffer
setup calls clobber the PS output configuration. Emitting the
scratch buffer setup as last action before the actual draw commands
seems to fix this.
Signed-off-by: Gert Wollny <gert.wollny@collabora.com>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19804>
Freeing BOs tends to be bursty (ie. when a submit is retired, or
expiring entries from BO cache). Sending lots of small SET_IOVA
messages to the host can quickly eat up the available virtqueue
slots, resulting in (eventually) starving the guest waiting for
free virtqueue space. By batching, we can avoid this and handle
things more efficiently on the host (ie. in a single wakeup rather
than many).
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19832>
Batch up handles before closing them to give the drm backend a chance to
batch up any extra handling needed (ie. virtio batching up messages to
host to release IOVA).
Signed-off-by: Rob Clark <robdclark@chromium.org>
Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/19832>