Unclear blocking behavior in vkQueuePresentKHR

[LaylBongers]

I'm writing a multi-window GUI application, which requires me to render to multiple windows, potentially at different rates depending on the refresh rate of the screen the window is on.

Reading through the spec, my expectation was that vkAcquireNextImageKHR would block until the next image were available in the swapchain (wait until buffers swapped with vsync), however it seems that, at least on my current NVIDIA drivers, vkQueuePresentKHR blocks instead.

It seems unclear to me if this is intentional or not, or where the driver is expected to wait. I've been told that AMD behaves differently, and blocks on vkAcquireNextImageKHR instead.

The issue blocking on vkQueuePresentKHR results in, is that this means the rendering queue will be completely unavailable until presentation is done, since queues need to be externally synchronized. Since this can take up to 16ms on 60Hz windows, this slows down all windows in turn.

What is the expected behavior here? Are drivers matching this behavior correctly? If this is expected and it's up to the driver where to block for VSync could this be clarified?

[krOoze]

Seems allowed.

By "VSync" you mean exactly what in the context of composited windowed app? vkAcquireNextImageKHR acquires an image object you can use for your rendering. It does not necessarily imply anything about VSync. E.g. the compositor might simply copy it out, and so it can return it almost immediately to you because it does not need it anymore. Only situation it is absolutely guaranteed to block is if you are out of swapchain images (already acquired all of them).

Should probably link #370 here. #1137 might be relevant too

[stonesthrow]

Already discussing internally, in relation to #1137. We are working clarification and guidance.

[jschnarr-nv]

With FIFO (vsync) presentation, ideally neither vkQueuePresentKHR nor vkAcquireNextImageKHR should block. The pImageIndex parameter of vkAcquireNextImageKHR returns "the index of the next image to use". This image is not necessary ready when vkAcquireNextImageKHR returns. Before using the image on the CPU you first should wait for the fence used with vkAcquireNextImageKHR. Before you use the image on the GPU you should wait for the semaphore used with vkAcquireNextImageKHR. In some cases the NVIDIA driver currently blocks in vkQueuePresentKHR. We're working on improving this. In the meantime you might consider presenting from an alternate thread to allow work to proceed.

[critsec]

That behavior (ideally .. neither .. should block) isn't guaranteed by the spec and is unlikely to ever be true on some platforms. It's not uncommon for window systems to have limits of approximately the swapchain length on how deep the present queue is, so one of the two calls must block.

[jschnarr-nv]

I agree that vkAcquireNextImage needs to block at times. It just isn't safe to rely on it blocking for the purpose of throttling framerates or guarding access to images. A fence wait should be used instead. Preferably vkQueuePresentKHR would not block since it does not allow for a timeout but this isn't guaranteed by the spec.

[Try]

Hi, @jschnarr-nv !

I'm also having present-lags in my engine, and time spent into vkQueuePresentKHR can reach up to 35ms, and ~2ms on average.
Bumping count of swapchain images give little to no benefit.

While waiting for proper fix, what wound be a good workaround for game developer to use?