Chapter 1: Mainloop Code - Invalid reuse of render semaphores #149
Description
The code in chapter 1 reuses a single render-finished semaphore per frame-in-flight. This reuse is invalid because a semaphore used in vkQueuePresentKHR may still be in use by the presentation engine when it is signaled again, which violates the Vulkan spec.
Recent validation layers will catch this and report the following error:
vkQueueSubmit2(): pSubmits[0].pSignalSemaphoreInfos[0].semaphore (VkSemaphore 0x1a000000001a) is being signaled by VkQueue 0x10d23e90, but it may still be in use by VkSwapchainKHR 0x30000000003.
Here are the most recently acquired image indices: 0, [1], 2, 0.
(brackets mark the last use of VkSemaphore 0x1a000000001a in a presentation operation)
Swapchain image 1 was presented but was not re-acquired, so VkSemaphore 0x1a000000001a may still be in use and cannot be safely reused with image index 0.
Vulkan insight: One solution is to assign each image its own semaphore. Here are some common methods to ensure that a semaphore passed to vkQueuePresentKHR is not in use and can be safely reused:
a) Use a separate semaphore per swapchain image. Index these semaphores using the index of the acquired image.
b) Consider the VK_EXT_swapchain_maintenance1 extension. It allows using a VkFence with the presentation operation.
The Vulkan spec states: The semaphore member of any binary semaphore element of the pSignalSemaphoreInfos member of any element of pSubmits must be unsignaled when the semaphore signal operation it defines is executed on the device (https://docs.vulkan.org/spec/latest/chapters/cmdbuffers.html#VUID-vkQueueSubmit2-semaphore-03868)
I have fixed this in my own project by allocating one render-finished semaphore per swapchain image, and indexed by the image index returned from vkAcquireNextImageKHR.