atagen

monolith

public
Star0
Watch0
d24854a5fbbc8ff17734f4e5aab7cb8e09949090
1
ssh://brewery@pls.lobotomise.me:33/atagen/monolith.git

Blame: research/nvidia.md

d5eca1c82213atagen2026-10-16 13:56 UTC1
# NVIDIA driver behaviour measured on an RTX 3060
d5eca1c82213atagen2026-10-16 13:56 UTC2
d5eca1c82213atagen2026-10-16 13:56 UTC3
Numbers from throwaway benchmarks against monolith's Vulkan renderer, October 2026.
d5eca1c82213atagen2026-10-16 13:56 UTC4
d5eca1c82213atagen2026-10-16 13:56 UTC5
## Waiting on a pending VkFence sleeps in 10 ms steps
d5eca1c82213atagen2026-10-16 13:56 UTC6
d5eca1c82213atagen2026-10-16 13:56 UTC7
`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.
d5eca1c82213atagen2026-10-16 13:56 UTC8
d5eca1c82213atagen2026-10-16 13:56 UTC9
## Every 1024th queue submit stalls for milliseconds
d5eca1c82213atagen2026-10-16 13:56 UTC10
d5eca1c82213atagen2026-10-16 13:56 UTC11
`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.
d5eca1c82213atagen2026-10-16 13:56 UTC12
5cd954fce34batagen2026-10-16 22:42 UTC13
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.