How to synchronize Vulkan swapchain presentation with sempahore destruction

When presenting with Vulkan using vkQueuePresentKHR() a number of semaphores can be provided to be waited upon by the driver before really doing the presentation. If I later want to destroy the semaphores with vkDestroySemaphore(), I need to first make sure that the presentation operation has finished execution. How do I do that? Unfortunately, differently from vkQueueSubmit(), vkQueuePresentKHR() does not support passing a fence the host can wait upon.

Some unsatisfying solutions I considered are:

• Calling vkQueueWaitIdle() on the presentation queue: my reading of the Vulkan specifications is that it only waits for "queue submission commands that accept a fence", and vkQueuePresentKHR() is not a queue submission command and it doesn't accept a fence. Also, it would force me to entirely stop the thread until the wait is done, while if I had a fence I could just poll it every now and then and destroy the semaphores as soon as I see it signaled.

• Calling vkDeviceWaitIdle(): has pretty much the same problems.

• Using VkSwapchainPresentFenceInfoEXT from extension VK_EXT_swapchain_maintenance1, which apparently does precisely what I would need. Unfortunately this doesn't appear to be implemented an basically any driver.

Any suggestion on another approach I could try?

vkDestroySemaphore has, as a Valid Usage rule:

> All submitted batches that refer to semaphore must have completed execution

Here's a fun fact: vkQueuePresentKHR does not create a "batch". You can see this from the definition of "batch": it's something created by "queue submission commands", which vkQueuePresentKHR is not. You can also see it in the docs for the present function. Compare it to other actual "queue submission commands", and you see that they all say that they create "batches" while the present function does not.

So as strange as it may be, according to the standard, it is 100% OK to destroy those semaphores after waiting on the queue submission operation that signaled them, not the present command that is waiting on them. Given that vkQueuePresentKHR already has funny behavior with regard to semaphores (they can't use timeline semaphores), I imagine that they prevent the semaphores from being fully destroyed or whatever behind the scenes.

Note that there has been some discussion of this issue for a while now. So while the specification seems to say that it's OK to destroy them, it's unclear if that is the intent or the way implementations work. Especially since the extension EXT_swapchain_mainenance1 exists which explicitly adds a mechanism to presenting to signal a fence. And it explicitly says that you're allowed to destroy the semaphores after the fence is signaled.

And because the wording is so loose, validation layers can't catch it, since they don't understand what the right behavior even is.

I would say, for the time being, try not to destroy semaphores used here until you can do a vkQueueWaitIdle to "ensure" that the present is done. By the spec presently, it doesn't ensure this, but practically it probably will.