radv: Add a dedicated transfer-only queue using SDMA
This MR adds a transfer queue implementation to RADV, which uses the SDMA hardware to implement Vulkan transfer commands. Note, some discussion and background information about this feature can be found in issue #850. The new transfer queue implementation is currently hidden behind a perf test flag, and can be activated using RADV_PERFTEST=transfer_queue
.
Based on
- !25769 (merged)
- !25770 (merged)
- !25796 (merged)
- !25831 (merged)
- !25833 (merged)
- !26110 (merged)
- !25834 (merged)
- !26353 (merged)
- !26580 (merged)
- !26913 (merged)
Hardware support
- GFX9, GFX10, GFX10.3 and GFX11 should work fine now
- GFX6-8 are currently out of scope
Implemented workarounds
- Compression (DCC and HTILE) is disabled on transfer queue image layouts on GFX9 which doesn't support it and Navi 10 which is buggy
- Copying between tiled images sometimes requires a scanline copy (which means copying the image in smaller chunks)
- Copying between unaligned buffers and images sometimes requires a chunked copy too
- Some images are unsupported by SDMA, such as mulisampled images (on all HW), sparse bindings (on GFX6-8) and emulated formats such as ETC2 and ASTC. When copying these images, use a gang submission and execute the copies on an async compute command buffer.
Testing
Vulkan CTS
dEQP-VK.api.fill_and_update_buffer.suballocation_transfer_queue.*
dEQP-VK.pipeline.monolithic.timestamp.*_transfer_queue
dEQP-VK.api.copy_and_blit.copy_commands2.*_transfer_queue.*
dEQP-VK.api.copy_and_blit.core.*resolve*
dEQP-VK.api.copy_and_blit.multiplanar_xfer.*
mpv
mpv -v --vo=gpu-next --gpu-api=vulkan --vulkan-async-transfer=yes <filename>
DXVK
DXVK is supposed to use transfer queues in some cases, but I haven't tested this yet.