On Mon Jun 17 14:15:30 2024 +0000, Conor McCarthy wrote:
I probably need to improve the comment. With vsync on, the driver delays present commands until the next vblank, which can easily cause presents to accumulate until all three images are pending, at which point `vkAcquireNextImageKHR()` will block. But because the block occurs in a worker, our `Present()` implementation will happily add more ops to the list without limit. `Present()` must block for the same reason `vkAcquireNextImageKHR()` blocks - to wait until an earlier present meets a vblank and completes. This does not solve the problem of frame latency, which should be patched separately. If rendering is very fast compared to sync rate, it's theoretically possible for any number of presents to be added to the list while the worker leaves the mutex unlocked. A frame latency implementation is probably the answer to that issue.
`Present()` doesn't necessarily have to wait if the user requested more buffers than there are images in the Vulkan swapchain. If the user requests 10 buffers (`DXGI_SWAP_CHAIN_DESC1::BufferCount`) but the Vulkan swapchain only supports three, after having submitted three buffers the Vulkan queue will be full and will have to wait for the first frame to finish presentation, but the D3D12 will still be able to hand out buffers until the count reaches 10.