atagen

monolith

public
Star0
Watch0
cce3ef7e0162cdeeecdac3e9a0a3e1204c029d8b
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
d5eca1c82213atagen2026-10-16 13:56 UTC13
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.