Mesa 26.0 RADV Lands Dedicated Transfer-Only Queue Using SDMA
([Radeon] 6 Hours Ago
RADV Transfer Queue Via SDMA)
- Reference: 0001605058
- News link: https://www.phoronix.com/news/Mesa-26.0-RADV-Transfer-SDMA
- Source link:
There is another open-source Radeon Vulkan driver (RADV) improvement to look forward to in the upcoming [1]Mesa 26.0 release that was worked on by one of Valve's Linux graphics driver developers.
Timur Kristóf in addition to his [2]recent work improving old AMD GCN 1.0/1.1 GPUs has finally pushed his dedicated transfer-only queue patches using the SDMA engine over the finish line. Since October 2023 was the merge request [3]radv: Add a dedicated transfer-only queue using SDMA .
That was motivated by [4]this 2019 bug report (and since 2018 in the original BugZilla thread) requesting a dedicated transfer-only queue to help with resource streaming and memory defragmentation. The argument back then was that the AMDVLK driver supported such functionality as well as the NVIDIA proprietary Vulkan driver. Even going back years various Vulkan apps/back-ends supported using transfer queues while since 2023, Timur has been battling the RADV support.
[5]
The code merged for Mesa 26.0 has the RADV dedicated transfer queue support working on GFX9 (Vega) and newer GPUs. Enabling this feature currently requires the RADV_PERFTEST=transfer_queue environment variable to activate. The DXVK Direct3D-on-Vulkan layer is among the software able to benefit from the Vulkan transfer queues support although there are no performance/benchmark numbers noted in that merge request for quantifying the benefit of the new functionality.
Mesa 26.0 stable should be out in February with the feature freeze / code branching expected for next week.
[1] https://www.phoronix.com/search/Mesa+26.0
[2] https://www.phoronix.com/news/Timur-More-Old-AMDGPU-2026
[3] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25594
[4] https://gitlab.freedesktop.org/mesa/mesa/-/issues/850
[5] https://www.phoronix.com/image-viewer.php?id=2026&image=radv_transfer_queue_lrg
Timur Kristóf in addition to his [2]recent work improving old AMD GCN 1.0/1.1 GPUs has finally pushed his dedicated transfer-only queue patches using the SDMA engine over the finish line. Since October 2023 was the merge request [3]radv: Add a dedicated transfer-only queue using SDMA .
That was motivated by [4]this 2019 bug report (and since 2018 in the original BugZilla thread) requesting a dedicated transfer-only queue to help with resource streaming and memory defragmentation. The argument back then was that the AMDVLK driver supported such functionality as well as the NVIDIA proprietary Vulkan driver. Even going back years various Vulkan apps/back-ends supported using transfer queues while since 2023, Timur has been battling the RADV support.
[5]
The code merged for Mesa 26.0 has the RADV dedicated transfer queue support working on GFX9 (Vega) and newer GPUs. Enabling this feature currently requires the RADV_PERFTEST=transfer_queue environment variable to activate. The DXVK Direct3D-on-Vulkan layer is among the software able to benefit from the Vulkan transfer queues support although there are no performance/benchmark numbers noted in that merge request for quantifying the benefit of the new functionality.
Mesa 26.0 stable should be out in February with the feature freeze / code branching expected for next week.
[1] https://www.phoronix.com/search/Mesa+26.0
[2] https://www.phoronix.com/news/Timur-More-Old-AMDGPU-2026
[3] https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/25594
[4] https://gitlab.freedesktop.org/mesa/mesa/-/issues/850
[5] https://www.phoronix.com/image-viewer.php?id=2026&image=radv_transfer_queue_lrg