vkAcquireNextImageKHR extremely slow?

After doing some profiling, I’ve noticed that ‘vkAcquireNextImageKHR’ takes about 16ms on average on my machine to execute. I’ve tested it in the triangle demo, with the same result.

// Get the index of the next available swapchain image:
err = demo->fpAcquireNextImageKHR(demo->device, demo->swapchain, UINT64_MAX,
                                    (VkFence)0, // TODO: Show use of fence

Is there any way to get around that? Why is it so slow in the first place? According to the specification, “If timeout is UINT64_MAX, the function will not return until an image is acquired from the presentation engine.”, but since there’s two images in the swapchain, one should always be ready almost immediately (After it was presented), right?

Is it Vsynced FIFO by any chance?

one should always be ready almost immediately (After it was presented), right?

Not quite. Neither AcquireNextImageKHR or PresentKHR() necessarily block, so without some synchronization you use up both your images for first two frames and then you have to wait until one of them finish being presented.

“Way around” would be to do whatever can be done without the Image in the meantime. Or have more swapchain images for things where input lag is not a concern (though, they would be used up quick too if the scene is easy too compute in comparison to the blanking interval)

Also I am always suspicious of profiling() style functions.

Getting AcquireNextImageKHR to not block requires that you allocate enough images that one is able to be free at any point and that you don’t use the FIFO mode.

With FIFO all images get pushed onto a FIFO queue and every vsync one gets pulled of to be shown on screen. During which the previously shown image is freed up for AcquireNextImageKHR

With mailbox you need at least 3 images (exact number depends on minImages of the surface query); one the is being shown now, one that is to be shown next and one that you render to.