Skip to content

Fix swapchain semaphore reuse validation warning#59

Open
sammifs wants to merge 1 commit into
blurrypiano:mainfrom
sammifs:fix-terminal-warning
Open

Fix swapchain semaphore reuse validation warning#59
sammifs wants to merge 1 commit into
blurrypiano:mainfrom
sammifs:fix-terminal-warning

Conversation

@sammifs
Copy link
Copy Markdown

@sammifs sammifs commented Apr 3, 2026

Summary

Attempted fix for a repeating Vulkan validation warning caused by reusing the semaphore passed to vkQueuePresentKHR as a per-frame resource instead of a per-swapchain-image resource.

This change updates the present-ready semaphores to be allocated per swapchain image and indexed by the acquired image index, I really tried to follow and understand the guidance here:
https://docs.vulkan.org/guide/latest/swapchain_semaphore_reuse.html

I still can not claim any expertise in these concepts/structures, but by following the page above and the example fix commit they linked to I got the warning to disappear. Compiles and runs and I cant spot anything amiss.

Problem

Running the current main produces the following repeating validation warning (memory addresses/ image indices vary of course):

validation layer: vkQueueSubmit(): pSubmits[0].pSignalSemaphores[0] (VkSemaphore 0x1f000000001f) is being signaled by VkQueue 0x749abe0, but it may still be in use by VkSwapchainKHR 0x40000000004.
Most recently acquired image indices: [0], 1, 2.
(Brackets mark the last use of VkSemaphore 0x1f000000001f in a presentation operation.)
Swapchain image 0 was presented but was not re-acquired, so VkSemaphore 0x1f000000001f may still be in use and cannot be safely reused with image index 2.
Vulkan insight: See https://docs.vulkan.org/guide/latest/swapchain_semaphore_reuse.html for details on swapchain semaphore reuse. Examples of possible approaches:
   a) Use a separate semaphore per swapchain image. Index these semaphores using the index of the acquired image.
   b) Consider the VK_KHR_swapchain_maintenance1 extension. It allows using a VkFence with the presentation operation.
The Vulkan spec states: Each binary semaphore element of the pSignalSemaphores 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-vkQueueSubmit-pSignalSemaphores-00067)

…ores per swapchain image

Use a separate semaphore for each swapchain image instead of reusing
present-wait semaphores per frame in flight. Signal and present using
readyPresentSemaphores[imageIndex] so a semaphore is only reused after
its swapchain image has been reacquired.

Also rename renderFinishedSemaphores to readyPresentSemaphores for clarity.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant