I am using exactly 3 images for the swapchain and one
Callingon active CB before it has completed. You must check CB fence before this call.
, if not VK_NULL_HANDLE, is an array of
VkSemaphoreentries, and specifies the semaphores to wait for before issuing the present request
/* Acquire an image from the swapchain. Block until one is available.
Signal presentation_finished when we are allowed to render into the image */
vkAcquireImageKHR(device, swapchain, UINT64_MAX, presentation_finished, nullptr, &index);
/* (...) Frambuffer creation, etc. */
/* Begin CB: The command pool is flagged to reset the command buffer on reuse */
VkCommandBuffer cb = command_buffers[index];
/* (...) Trivial rendering of a single color image */
/* End CB */
/* Queue the rendering and wait for presentation_finished.
When rendering is finished, signal rendering_finished.
The VkSubmitInfo will have these important members set among others:
.pWaitSemaphores = &presentation_finished;
.pSignalSemaphores = &rendering_finished;
/* Submit the presentation request as soon as the rendering_finished
semaphore gets signalled
The VkPresentInfoKHR will have these important members set among others:
.pWaitSemaphores = &rendering_finished;
vkAcquireNextImageKHR is allowed to return an image that is still the destination and/or source of ongoing asynchronous operations. This means you have no guarantee the command buffer is available at time of reuse. It would be correct to enqueue additional, distinct command buffers to write to the acquired image, as long as those commands are configured to wait on the
presentation_finished semaphore; but to safely reuse that command buffer you must wait on the fence passed to
See section 29.6. WSI Swapchain in the Vulkan spec with KHR extensions:
An application can acquire use of a presentable image with vkAcquireNextImageKHR. After acquiring a presentable image and before modifying it, the application must use a synchronization primitive to ensure that the presentation engine has finished reading from the image. The application can then transition the image’s layout, queue rendering commands to it, etc. Finally, the application presents the image with vkQueuePresentKHR, which releases the acquisition of the image.
See also these notes for
When successful, vkAcquireNextImageKHR acquires a presentable image that the application can use, and sets pImageIndex to the index of that image. The presentation engine may not have finished reading from the image at the time it is acquired, so the application must use semaphore and/or fence to ensure that the image layout and contents are not modified until the presentation engine reads have completed.
As mentioned above, the presentation engine may be asynchronous with respect to the application and/or logical device. vkAcquireNextImageKHR may return as soon as it can identify which image will be acquired, and can guarantee that semaphore and fence will be signaled by the presentation engine; and may not successfully return sooner. The application uses timeout to specify how long vkAcquireNextImageKHR waits for an image to become acquired.
This shows that
vkAcquireNextImageKHR is not required to block on the presentation operation, and transitively is not required to block on the graphics command that the presentation operation is itself waiting on.