When running the game on Manjaro Linux, and using vsync = off, I receive the following Vulkan Validation error on game exit:
Validation Error: [ VUID-vkDestroyDevice-device-05137 ] | MessageID = 0x4872eaa0
vkDestroyDevice(): Object Tracking - For VkDevice 0x564041d069a0, VkSemaphore 0xb000000000b has not been destroyed.
The Vulkan spec states: All child objects created on device that can be destroyed or freed must have been destroyed or freed prior to destroying device (https://docs.vulkan.org/spec/latest/chapters/devsandqueues.html#VUID-vkDestroyDevice-device-05137)
Objects: 1
[0] VkSemaphore 0xb000000000b
Looking into this I made an interesting discovery: The number of swapchain images returned after swapchain creation depends on the chosen presentation mode! For instance, Mailbox mode requires 4 swapchain images, whereas other modes such as Immediate, FIFO, and FIFO Relaxed can return 3 or even 2 swapchain images depending on the hardware and driver. And because present semaphores are currently allocated once during initialization, you can cause a mismatch between number of swapchain images and present semaphores, which is not good and violates Vulkan best practices. The above error on exit shows up due to a dangling semaphore that does not get destroyed on exit (i.e. if semaphores allocated > swapchain images).
This means you cannot statically allocate presentation semaphores matching the initial number of swapchain images. Whenever you change the presentation (vsync) mode the number of swapchain images can change, and the number of present semaphores should also be updated.
This discovery was a surprise, and points out a more serious issue than I first realized. I likely should have known this behaviour, but frankly I missed this when coding in this area. I will submit a PR to address it.
When running the game on Manjaro Linux, and using vsync = off, I receive the following Vulkan Validation error on game exit:
Validation Error: [ VUID-vkDestroyDevice-device-05137 ] | MessageID = 0x4872eaa0
vkDestroyDevice(): Object Tracking - For VkDevice 0x564041d069a0, VkSemaphore 0xb000000000b has not been destroyed.
The Vulkan spec states: All child objects created on device that can be destroyed or freed must have been destroyed or freed prior to destroying device (https://docs.vulkan.org/spec/latest/chapters/devsandqueues.html#VUID-vkDestroyDevice-device-05137)
Objects: 1
[0] VkSemaphore 0xb000000000b
Looking into this I made an interesting discovery: The number of swapchain images returned after swapchain creation depends on the chosen presentation mode! For instance, Mailbox mode requires 4 swapchain images, whereas other modes such as Immediate, FIFO, and FIFO Relaxed can return 3 or even 2 swapchain images depending on the hardware and driver. And because present semaphores are currently allocated once during initialization, you can cause a mismatch between number of swapchain images and present semaphores, which is not good and violates Vulkan best practices. The above error on exit shows up due to a dangling semaphore that does not get destroyed on exit (i.e. if semaphores allocated > swapchain images).
This means you cannot statically allocate presentation semaphores matching the initial number of swapchain images. Whenever you change the presentation (vsync) mode the number of swapchain images can change, and the number of present semaphores should also be updated.
This discovery was a surprise, and points out a more serious issue than I first realized. I likely should have known this behaviour, but frankly I missed this when coding in this area. I will submit a PR to address it.