Blame: research/nvidia.md
d5eca1c82213 | atagen | 2026-10-16 13:56 UTC | 1 | # NVIDIA driver behaviour measured on an RTX 3060 |
d5eca1c82213 | atagen | 2026-10-16 13:56 UTC | 2 | |
d5eca1c82213 | atagen | 2026-10-16 13:56 UTC | 3 | Numbers from throwaway benchmarks against monolith's Vulkan renderer, October 2026. |
d5eca1c82213 | atagen | 2026-10-16 13:56 UTC | 4 | |
d5eca1c82213 | atagen | 2026-10-16 13:56 UTC | 5 | ## Waiting on a pending VkFence sleeps in 10 ms steps |
d5eca1c82213 | atagen | 2026-10-16 13:56 UTC | 6 | |
d5eca1c82213 | atagen | 2026-10-16 13:56 UTC | 7 | `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. |
d5eca1c82213 | atagen | 2026-10-16 13:56 UTC | 8 | |
d5eca1c82213 | atagen | 2026-10-16 13:56 UTC | 9 | ## Every 1024th queue submit stalls for milliseconds |
d5eca1c82213 | atagen | 2026-10-16 13:56 UTC | 10 | |
d5eca1c82213 | atagen | 2026-10-16 13:56 UTC | 11 | `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. |
d5eca1c82213 | atagen | 2026-10-16 13:56 UTC | 12 | |
d5eca1c82213 | atagen | 2026-10-16 13:56 UTC | 13 | Open for M7. Either spend the 1024th submission on an empty submit at a moment with slack, or move submission to its own thread so the render path never waits on it. |