SaschaWillems
Sample request: how to wait for older GPU frame (and vsync)
The current samples all seem to wait for the GPU to finish before going on to the next frame (e.g. they do a vkQueueWaitIdle() after submitting command buffers. Both in Metal and D3D12 the basic samples wait for an older frame to finish, so that the CPU can start recording a new command buffer while the GPU is processing the previously submitted commands and the swap chain is presenting the rendered frame.
There is some example code in "Example 5" in the spec here, which does something similar for Vulkan (basically in vkAcquireNextImageKHR set a fence, and at start of frame, wait for an older fence), and this is also presented as a way to throttle the render loop with the vsync: https://www.khronos.org/registry/vulkan/specs/1.0-wsi_extensions/xhtml/vkspec.html (search for "Example 5").
It would be nice to have a 'vsync' sample which implements this idea, since I currently don't get this to work:
- I'm getting a validation warning "vkWaitForFences called for fence xxxx which has not been submitted on a Queue" for the fence that is provided to vkAcquireNextImageKHR()
- and vsync doesn't seem to work at all, rendering is unthrottled
I'm on Windows10 with an NVIDIA 940M (driver version 364.51), and LunarG SDK 1.0.3.1.
Did you actually get vsync to work in your samples?
PS: at least the fence warning I'm getting seems to have been a bug in the validation layer (https://github.com/KhronosGroup/Vulkan-LoaderAndValidationLayers/issues/19), but this means missing vsync isn't related to this.
No, haven't done anything with vsync. It's on my todo list, but that's growing and growing. So much to do, so little time. So I don't have any eta on this.
Ok, no problem :) if I get it working I'll report back, I currently suspect it's a driver issue, I'll try to check if it works on Intel and/or Linux.
@floooh what present mode are you using? My understanding is that if you want the GL behavior of blocking on presentation, then you need to use VK_PRESENT_MODE_FIFO_KHR. Using mailbox or immediate modes will result in non-blocking calls to vkQueuePresentKHR and unbounded rendering.
Ah sorry I didn't get past the 'clear screen' stage when I dabbled with Vulkan back then :)
Using mailbox or immediate modes will result in non-blocking calls to vkQueuePresentKHR and unbounded rendering.
FWIW, there's no spec-guarantee that vkQueuePresentKHR or vkAcquireNextImageKHR will ever block no matter that the present mode is. The app has to implement some kind of CPU-side throttling (fence wait) if it wants to avoid getting too far ahead of the GPU.
