1.9 KiB
← Back to Twitter thread index
title: "Rethinking Vulkan queue choice. Traditional double-buffered games might do somet" author: "NOTimothyLottes" handle: "@NOTimothyLottes" post_url: "https://x.com/NOTimothyLottes/status/2075769880092037309" post_id: "2075769880092037309" timestamp: "2026-07-11 02:31:20" post_count: 4 reply_count: 2 repost_count: 2 like_count: 42 view_count: 5063
@NOTimothyLottes — Rethinking Vulkan queue choice. Traditional double-buffered games might do somet
Post 1 (2026-07-11 02:31:20)
Rethinking Vulkan queue choice. Traditional double-buffered games might do something like the code below. Find the queue that does {presentation,graphics,compute}. First off this seems like a lot of unnecessary work when one could just choose queue 0 and be done with it ...
Post 2 (2026-07-11 02:34:19) — reply to Post 1
AMD on Linux (RADV) and Windows. Queue 0 just works. But note both platforms support doing present on queue 1. So on AMD I'm likely going to render via compute on queue 0 [to reduce chance of preemption] and present on queue 1. And have both decoupled (for front buffer rendering)
Post 3 (2026-07-11 02:37:24) — reply to Post 2
NVIDIA is more complex. They put a DMA engine in queue 1 slot, and compute engine in queue 2 slot. Some sometimes queue 2 slot can or cannot do present (varies by driver). So maybe present on 0 (gfx queue), and dispatch on queue 2 by default for NV.
Post 4 (2026-07-11 06:31:23) — reply to Post 1
@NOTimothyLottes Am I having a stroke? What is this font? It feels like reading a captcha. Is it only me?