Semaphore signalling issue with Win32

[rowanpreston-mnl]

Hello,

I'm looking to migrate an OSG based windows application to VSG, and as a starting point I'm attempting to create a minimal sandbox application roughly following the vsgwin32 example.

VSG creates a window and gets as far as the first frame, but then runs into a semaphore signalling issue:

Validation Error: [ VUID-vkQueueSubmit-pSignalSemaphores-00067 ] | MessageID = 0x539277af
vkQueueSubmit(): pSubmits[0].pSignalSemaphores[0] (VkSemaphore 0x30000000003) is being signaled by VkQueue 0x17b7c8bf778, but it may still be in use by VkSwapchainKHR 0x200000000020.
Here are the most recently acquired image indices: [0], 1.
(brackets mark the last use of VkSemaphore 0x30000000003 in a presentation operation)
Swapchain image 0 was presented but was not re-acquired, so VkSemaphore 0x30000000003 may still be in use and cannot be safely reused with image index 1.
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_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://vulkan.lunarg.com/doc/view/1.4.321.1/windows/antora/spec/latest/chapters/cmdbuffers.html#VUID-vkQueueSubmit-pSignalSemaphores-00067)
Objects: 2
    [0] VkSemaphore 0x30000000003
    [1] VkQueue 0x17b7c8bf778

Validation Error: [ VUID-vkQueueSubmit-pSignalSemaphores-00067 ] | MessageID = 0x539277af
vkQueueSubmit(): pSubmits[0].pSignalSemaphores[0] (VkSemaphore 0x30000000003) is being signaled by VkQueue 0x17b7c8bf778, but it may still be in use by VkSwapchainKHR 0x200000000020.
Here are the most recently acquired image indices: 0, [1], 2.
(brackets mark the last use of VkSemaphore 0x30000000003 in a presentation operation)
Swapchain image 1 was presented but was not re-acquired, so VkSemaphore 0x30000000003 may still be in use and cannot be safely reused with image index 2.
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_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://vulkan.lunarg.com/doc/view/1.4.321.1/windows/antora/spec/latest/chapters/cmdbuffers.html#VUID-vkQueueSubmit-pSignalSemaphores-00067)
Objects: 2
    [0] VkSemaphore 0x30000000003
    [1] VkQueue 0x17b7c8bf778

I'd appreciate any advice about what I've missed. I haven't implemented any custom window classes or event handling as it wasn't needed with OSG, are extra steps needed for VSG?

[robertosfield]

This is known issue with some drivers, it's more of validation issue than a bug that causes runtime issues, as I've never known any runtime problems to be traced back to validation issue, so for now you'll probably get on just fine ignoring it.

This issue has a few potential ways to quieten this validation issue but I haven't yet had a chance to sit down a explore these. Once I've got some time I'll dive into the topic and will likely be making calls for testing across different OS, builds and hardware systems to make sure any changes don't introduce new problems.

[AnyOldName3]

We've got two issues tracking semaphore problems at the moment, #1558 and #1597 if you want to keep track of progress. #1559 is a fix for one of the problems.

[rowanpreston-mnl]

Thanks both, I'll keep any eye on those tickets but for now it doesn't seem to be breaking anything important