vkAcquireNextImageKHR ignoring timeout

I’m running into a nasty bug with vkAcquireNextImageKHR.

I’m trying to call the function with timeout set to 0 so that it will not block and I can do stuff while the next presentation image is not ready yet. However, no matter what value I set (0, or 1, or anything else), the vkAcquireNextImageKHR never timeouts or returns not ready. It always blocks until the next image is available (which makes me lose 16ms).

I’m using FIFO for my presentation mode, but I still would expect that vkAcquireNextImageKHR would not block if I set timeout to 0. MAILBOX is not available on my system.

OS: Arch Linux
GPU: GeForce GTX 1070
Windowing system: i3 (with X11)

Is this a bug with nvidia linux drivers or is it with my windowing system? Where should I report this?


thanks for your feedback. Can you provide your driver version?

The driver version is 381.22-3.

Our current implementation of vkAcquireNextImageKHR() cannot block when presenting through X11 and can always return an image, given that your application did not try to acquire all the images without presenting them (in which case we return INVALID_BEHAVIOR).

Are you positive that this is indeed vkAcquireNextImageKHR() that is blocking?

Sorry for the delay in answering this.

My bad. I assumed that because vkAcquireNextImageKHR() didn’t return either TIMEOUT or NOT_READY the problem was with it.

What blocks is a vkQueueWaitIdle() call on the presentation queue after calling vkPresentImageKHR(). This makes complete sense, as I’m using FIFO for my presentation mode.

However, I’m having another problem with this. If I remove the vkQueueWaitIdle()'s and use only semaphores to synchronize between the vkAcquireNextImageKHR(), my compute shaders, and then vkPresentImageKHR(), the render loop will run thousands of times per second at first (using FIFO), with vkPresentImageKHR() not blocking, and then start running at 60fps, with vkPresentImageKHR() blocking. Everything will work fine until I break out of the render loop and call vkQueueWaitIdle() to wait for all queues to be empty before closing the app. When I call it, the application (and windowing system) will freeze for around 15 seconds, until it returns with a VK_ERROR_DEVICE_LOST message and the application crashes.

Do you have any idea why using only semaphores is causing this behavior after running properly for some time and then calling vkQueueWaitIdle?

It is hard to picture what you are trying to do without code or pseudo code.

It sounds like you are trying to throttle the presentation? It is currently not possible to throttle the presentation in Vulkan. However, you can throttle the rendering, which should achieve the same result.

LunarG’s cube does this kind of throttling, I recommend you take a look.

In particular, you cannot use the semaphore returned by vkAcquireNextImageKHR() to throttle either the presentation or the rendering. This semaphore holds information about the last time that image was presented, which could have been several frames ago.

Throttling can be achieved by having an out fence from vkQueueSubmit() and waiting for it if the application is too many frames ahead.

I think I understand now.

I was trying to throttle rendering so that I would not be too far ahead and could run the loop in full speed without waiting with vkQueueWaitIdle(). So I need to use a Fence, easy enough. I don’t know why I didn’t think of this before.

Thanks for the support!

By the way, will we ever have the mailbox presentation mode on Linux as we have on Windows?