NVIDIA driver behaviour measured on an RTX 3060
Numbers from throwaway benchmarks against monolith’s Vulkan renderer, October 2026.
Waiting on a pending VkFence sleeps in 10 ms steps
vkWaitForFences on a fence whose work has not finished yet returned after a 10.06 ms median, for GPU work that finishes in under 200 us. Waiting 200 us before calling it gave a 2 us median. Exporting the fence as a sync_file and polling the fd wakes on completion, at a 15 us median and 213 us worst case. render-vk waits this way now.
Every 1024th queue submit stalls for milliseconds
vkQueueSubmit2 normally takes 30 to 90 us, but every 1024th call takes 2.5 to 15 ms, at the same submission indices in every run (1015, 2039, …). This holds with or without exportable fences and with pooled fences and command buffers, so it is per submission, probably an internal ring wrapping. At 165 Hz it shows up as one dropped frame every 6.2 s.
A vkQueueSubmit2 with no command buffers is a driver no-op that does not advance the count. A submit of an empty command buffer does advance it and takes the stall itself. In a 4200-frame run, absorbing the stall in idle time left zero stalled renders. render-vk now does this after every flip when the stalling submission is within 8, and it learns the phase on other drivers once two stalls land on the same one.