mirror of
https://gitlab.freedesktop.org/mesa/mesa.git
synced 2026-01-26 23:00:34 +01:00
f58630f07c
Forcing a dedicated sparse queue is problematic in real-world scenarios. In the current implicit sync world for sparse updates, we can rely on submission order. For use cases where an application can take advantage of the separate sparse queue to do "async" updates, the existing implementation works well, but problems arise when trying to implement D3D-style submission ordering. E.g., when a game does sparse on a graphics or compute queue, we need to guarantee that previous submissions, sparse update and future submissions are properly ordered. The Vulkan way of implementing this is to: - Signal graphics queue to timeline N (i.e. last submission made) - Wait on timeline N on the sparse queue - Do sparse updates - Signal timeline N + 1 on sparse queue - Wait for timeline N + 1 on graphics queue (can be deferred until next graphics submit) This causes an unavoidable bubble in GPU execution, since the existing sparse queue ends up doing: - Wait pending signal. The implication here is that all previous GPU work must have been submitted. - Do VM operations on CPU timeline - Wait for semaphores to signal (this is required for signal ordering) - ... GPU is meanwhile stalling in a bubble due to GPU -> CPU -> GPU roundtrip. - Signal semaphore on CPU (unblocks GPU work) Letting the GPU go idle here is not great, and we can be screwed over by bad thread scheduling. Another knock-on effect is that the graphics queue is now forced into using a thread for submissions. This is because when the graphics queue wants to wait for timeline N + 1, the sparse queue may not have signalled the timeline yet on CPU, so effectively, we have created a wait-before-signal situation internally in RADV. Throwing another thread under the bus is not great either. Just letting the queue in question support sparse binding solves all these issues and I don't see a path forward where the D3D use case can be solved in a separate queue world. It is also friendlier to the ecosystem at large. RADV is the only driver I know of that insists on separate sparse queues and multiple games assume that graphics queue can support sparse. Signed-off-by: Hans-Kristian Arntzen <post@arntzen-software.no> Reviewed-by: Samuel Pitoiset <samuel.pitoiset@gmail.com> Part-of: <https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/33166> |
||
|---|---|---|
| .. | ||
| amd | ||
| android_stub | ||
| asahi | ||
| broadcom | ||
| c11 | ||
| compiler | ||
| drm-shim | ||
| egl | ||
| etnaviv | ||
| freedreno | ||
| gallium | ||
| gbm | ||
| getopt | ||
| gfxstream | ||
| glx | ||
| gtest | ||
| imagination | ||
| imgui | ||
| intel | ||
| loader | ||
| mapi | ||
| mesa | ||
| microsoft | ||
| nouveau | ||
| panfrost | ||
| tool | ||
| util | ||
| virtio | ||
| vulkan | ||
| x11 | ||
| .clang-format | ||
| meson.build | ||