Glfw + Vulkan: backend don't properly handle when vkQueuePresentKHR & vkAcquireNextImageKHR produce VK_ERROR_OUT_OF_DATE_KHR

[InsideBSITheSecond]

Version/Branch of Dear ImGui:

Version 1.90.5 WIP (19044), Branch: docking

Back-ends:

imgui_impl_glfw.cpp + imgui_impl_vulkan.cpp

Compiler, OS:

Linux + GCC 13.2.1
Vulkan: 1.3.279
GLFW: 3.4-2
KDE Plasma 6

GTX 1050Ti (Nvidia drivers v 550.67)

Full config/build information:

Dear ImGui 1.90.5 WIP (19044)
--------------------------------
sizeof(size_t): 8, sizeof(ImDrawIdx): 2, sizeof(ImDrawVert): 20
define: __cplusplus=202002
define: __linux__
define: __GNUC__=13
define: IMGUI_HAS_VIEWPORT
define: IMGUI_HAS_DOCK
--------------------------------
io.BackendPlatformName: imgui_impl_glfw
io.BackendRendererName: imgui_impl_vulkan
io.ConfigFlags: 0x00000440
 DockingEnable
 ViewportsEnable
io.ConfigViewportsNoDecoration
io.ConfigInputTextCursorBlink
io.ConfigWindowsResizeFromEdges
io.ConfigMemoryCompactTimer = 60.0
io.BackendFlags: 0x00001C0E
 HasMouseCursors
 HasSetMousePos
 PlatformHasViewports
 HasMouseHoveredViewport
 RendererHasVtxOffset
 RendererHasViewports
--------------------------------
io.Fonts: 1 fonts, Flags: 0x00000000, TexSize: 512,64
io.DisplaySize: 800.00,600.00
io.DisplayFramebufferScale: 1.00,1.00
--------------------------------
style.WindowPadding: 8.00,8.00
style.WindowBorderSize: 1.00
style.FramePadding: 4.00,3.00
style.FrameRounding: 0.00
style.FrameBorderSize: 0.00
style.ItemSpacing: 8.00,4.00
style.ItemInnerSpacing: 4.00,4.00

Details:

My Issue/Question:

So I'm trying to get the docking branch features implemented in my project and I realized there was an issue when resizing secondary viewports. I went to the example_glfw_vulkan to see how it was handled there and it seems resizing secondary viewports from the example sometimes works, and sometimes abort the program.
I attempted to just skip the error check if err == VK_ERROR_OUT_OF_DATE_KHR || err == VK_SUBOPTIMAL_KHR, and when doing so it later get stuck on vkDeviceWaitIdle which is the same behavior I observe in my project (only difference is that my project is using GLFW 3.29.2)

My project's implementation of this is probably not perfect but since I noticed an issue in the example itself I thought I'd post what I have.

Screenshots/Video:

2024-04-18-18-55-17.mp4

Minimal, Complete and Verifiable Example code:

code:
just using the example_glfw_vulkan/main.cpp

[InsideBSITheSecond]

So after digging a bit deeper into this I found that my issue may be related to #3758
When I skip the error check as shown in the middle of the video (just after vkAcquireNextImageKHR), it keep executing until it reaches vkQueuePresentKHR cff8162 after which it get stuck on the first vkDeviceWaitIdle it encounters at line 1419 in ImGui_ImplVulkanH_CreateWindowSwapChain (after entering ImGui_ImplVulkanH_CreateOrResizeWindow).

Producing 2 validation errors on the way
from vkQueueSubmit around line 1854 (imgui_impl_vulkan.cpp):
[vulkan] Debug report from ObjectType: 5 Message: Validation Error: [ VUID-vkQueueSubmit-pWaitSemaphores-03238 ] Object 0: handle = 0x9f58380000000064, type = VK_OBJECT_TYPE_SEMAPHORE; Object 1: handle = 0x5555558a7030, type = VK_OBJECT_TYPE_QUEUE; | MessageID = 0xb50452b0 | vkQueueSubmit(): pSubmits[0].pWaitSemaphores[0] queue (VkQueue 0x5555558a7030[]) is waiting on semaphore (VkSemaphore 0x9f58380000000064[]) 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 must have also been submitted for execution (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-vkQueueSubmit-pWaitSemaphores-03238)

from vkQueuePresentKHR near line 1878 (imgui_impl_vulkan.cpp)
[vulkan] Debug report from ObjectType: 27 Message: Validation Error: [ VUID-VkPresentInfoKHR-pImageIndices-01430 ] Object 0: handle = 0x625f640000000058, type = VK_OBJECT_TYPE_SWAPCHAIN_KHR; | MessageID = 0x48ad24c6 | vkQueuePresentKHR(): pPresentInfo->pSwapchains[0] image at index 1 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 or VK_IMAGE_LAYOUT_SHARED_PRESENT_KHR layout at the time the operation is executed on a VkDevice (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-VkPresentInfoKHR-pImageIndices-01430)

and if I try to not only skip the check but call ImGui_ImplVulkanH_CreateOrResizeWindow like here cff8162 I get:

[vulkan] Debug report from ObjectType: 1 Message: Validation Error: [ VUID-VkSubmitInfo-pWaitSemaphores-parameter ] Object 0: handle = 0x555555928e50, type = VK_OBJECT_TYPE_INSTANCE; | MessageID = 0xb0d79520 | vkQueueSubmit(): pSubmits[0].pWaitSemaphores[0] Invalid VkSemaphore Object 0x7ffff236fbe8. The Vulkan spec states: If waitSemaphoreCount is not 0, pWaitSemaphores must be a valid pointer to an array of waitSemaphoreCount valid VkSemaphore handles (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-VkSubmitInfo-pWaitSemaphores-parameter)

[vulkan] Debug report from ObjectType: 1 Message: Validation Error: [ VUID-VkSubmitInfo-pSignalSemaphores-parameter ] Object 0: handle = 0x555555928e50, type = VK_OBJECT_TYPE_INSTANCE; | MessageID = 0xb108ab13 | vkQueueSubmit(): pSubmits[0].pSignalSemaphores[0] Invalid VkSemaphore Object 0x100000001. The Vulkan spec states: If signalSemaphoreCount is not 0, pSignalSemaphores must be a valid pointer to an array of signalSemaphoreCount valid VkSemaphore handles (https://www.khronos.org/registry/vulkan/specs/1.3-extensions/html/vkspec.html#VUID-VkSubmitInfo-pSignalSemaphores-parameter)

EDIT:
Long story short: vkQueuePresentKHR & vkAcquireNextImageKHR produce VK_ERROR_OUT_OF_DATE_KHR in certain situations and it seems like it's not handled properly when it happens

[InsideBSITheSecond]

#7513 should fix this