VK_ERROR_FULL_SCREEN_EXCLUSIVE_MODE_LOST_EXT

Hi,

I'm currently adding support for full-screen exclusive mode in our engine (OS = Windows 11).

I'm facing some problems while trying to handle VK_ERROR_FULL_SCREEN_EXCLUSIVE_MODE_LOST_EXT correctly.

So, when pressing Alt+Tab, vkQueuePresentKHR() calls returns VK_ERROR_FULL_SCREEN_EXCLUSIVE_MODE_LOST_EXT. When this appends, I call acquireFullScreenExclusiveMode() to acquire full-screen mode again.

The documentation states:

However, if the presentation request is rejected by the presentation engine with an error VK_ERROR_OUT_OF_DATE_KHR, VK_ERROR_FULL_SCREEN_EXCLUSIVE_MODE_LOST_EXT, or VK_ERROR_SURFACE_LOST_KHR, the set of queue operations are still considered to be enqueued and thus any semaphore wait operation specified in VkPresentInfoKHR will execute when the corresponding queue operation is complete.

I therefore understand there is no need to call vkQueuePresentKHR() again at this point.

The next frames are being rendered correclty, until I press Alt-Tab again. vkQueuePresentKHR() calls returns VK_ERROR_FULL_SCREEN_EXCLUSIVE_MODE_LOST_EXT as expected, and I therefore call acquireFullScreenExclusiveMode(). However, in that case, a validation error message is being raised during the next vkAcquireNextImageKHR() call:

[VUID-vkAcquireNextImageKHR-swapchain-01802] : Validation Error: [ VUID-vkAcquireNextImageKHR-swapchain-01802 ] Object 0: handle = 0x8f1c31000000006d, type = VK_OBJECT_TYPE_SWAPCHAIN_KHR; | MessageID = 0x3e97a888 | vkAcquireNextImageKHR: Application has already previously acquired 2 images from swapchain. Only 2 are available to be acquired using a timeout of UINT64_MAX (given the swapchain has 3, and VkSurfaceCapabilitiesKHR::minImageCount is 2). The Vulkan spec states: If the number of currently acquired images is greater than the difference between the number of images in swapchain and the value of VkSurfaceCapabilitiesKHR::minImageCount as returned by a call to vkGetPhysicalDeviceSurfaceCapabilities2KHR with the surface used to create swapchain, timeout must not be UINT64_MAX (https://vulkan.lunarg.com/doc/view/1.3.211.0/windows/1.3-extensions/vkspec.html#VUID-vkAcquireNextImageKHR-swapchain-01802) (1050126472)

Which seems to indicate the swapchain images previously acquired haven't been released (likely when vkQueuePresentKHR() returns VK_ERROR_FULL_SCREEN_EXCLUSIVE_MODE_LOST_EXT - which is not the behaviour I would expect according to the documentation).

So, I've tried to play it differently. When vkQueuePresentKHR() returns VK_ERROR_FULL_SCREEN_EXCLUSIVE_MODE_LOST_EXT, I'm still calling acquireFullScreenExclusiveMode() as before, but this time followed by a second call to vkQueuePresentKHR() (with the pWaitSemaphore being set to NULL for this second call).
In that scenario, the first call to vkAcquireNextImageKHR() following these operation returns VK_NOT_READY (which is not an error message according to the documentation).
I get then other error messages from the validation layer :

[VUID-vkQueueSubmit-pWaitSemaphores-03238] : Validation Error: [ VUID-vkQueueSubmit-pWaitSemaphores-03238 ] Object 0: handle = 0xfb9036000000536b, type = VK_OBJECT_TYPE_SEMAPHORE; Object 1: handle = 0x26b2de46450, type = VK_OBJECT_TYPE_QUEUE; | MessageID = 0xb50452b0 | vkQueueSubmit(): pSubmits[0].pWaitSemaphores[0] Queue VkQueue 0x26b2de46450[] is waiting on semaphore (VkSemaphore 0xfb9036000000536b[]) that has no way to be signaled. The Vulkan spec states: All elements of the pWaitSemaphores member of all elements of pSubmits created with a VkSemaphoreType of VK_SEMAPHORE_TYPE_BINARY must reference a semaphore signal operation that has been submitted for execution and any semaphore signal operations on which it depends (if any) must have also been submitted for execution (https://vulkan.lunarg.com/doc/view/1.3.211.0/windows/1.3-extensions/vkspec.html#VUID-vkQueueSubmit-pWaitSemaphores-03238) (-1258007888)
[VUID-VkPresentInfoKHR-pImageIndices-01296] : Validation Error: [ VUID-VkPresentInfoKHR-pImageIndices-01296 ] Object 0: handle = 0x8f1c31000000006d, type = VK_OBJECT_TYPE_SWAPCHAIN_KHR; | MessageID = 0xc7aabc16 | vkQueuePresentKHR: pSwapchains[0] image at index 2 was not acquired from the swapchain. The Vulkan spec states: Each element of pImageIndices must be the index of a presentable image acquired from the swapchain specified by the corresponding element of the pSwapchains array, and the presented image subresource must be in the VK_IMAGE_LAYOUT_PRESENT_SRC_KHR layout at the time the operation is executed on a VkDevice (https://github.com/KhronosGroup/Vulkan-Docs/search?q=)VUID-VkPresentInfoKHR-pImageIndices-01296) (-945112042)

To be honest, I'm a bit lost, I'm confused and couldn't really find in the documentation how to properly handle that VK_ERROR_FULL_SCREEN_EXCLUSIVE_MODE_LOST_EXT error.

Thanks for any help !

Start by tracing the vkQueuePresentKHR, acquireFullScreenExclusiveMode(), and vkAcquireNextImageKHR sequence described in the issue, using VUID-vkAcquireNextImageKHR-swapchain-01802 and the two reported validation messages as checkpoints. Determine the expected validation behavior after VK_ERROR_FULL_SCREEN_EXCLUSIVE_MODE_LOST_EXT and document or reproduce the result with the cited Vulkan operations.