vkQueuePresentKHR blocks, as expected (FIFO, 2 image, vsync required), but on all the OS’s and hardware (all NVidia) i have access to (which is very limited) - it does that by busy-looping the CPU to hell. Not yielding to other threads/processes (the only sane option) nor using CPU friendly wait instructions (like what idle process does in Windows) just plain dumb polling loop. This makes Vulkan unusable.
Which begs the question - what am i doing wrong? As evidently people do use vulkan. I must be missing something.
So far i have used a horrid-hack-workaround by setting an event after present related rendering is done and wait for it at CPU side before proceeding to call vkQueuePresentKHR. Unfortunately, for reasons i can not fathom, Vulkan does not support waiting for events at CPU side. Which makes the hack particularly ugly and unreliable.
Collect data for rendering - among other things it will vkAcquireNextImageKHR setting wImageAvailable.
vkQueueSubmit that contains:
- early pathes of heavy work
- presentable patch that waits for wImageAvailable and signals wRenderFinished
- more pathes or other work - where the very first thing is signalling an event hackCanPresent
My workaround hack: polling hackCanPresent and guesstimating reasonable delay for SetWaitableTimer/WaitForSingleObject (which does not kill the CPU).
vkQueuePresentKHR that waits for wRenderFinished.
How can i fix this?