Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
InsideBSITheSecond opened this issue Apr 18, 2024 · 5 comments

Comments

@InsideBSITheSecond
Copy link

InsideBSITheSecond commented Apr 18, 2024

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

@ocornut ocornut changed the title (GLFW + Vulkan) Resizing undocked windows cause example to abort (docking branch) GLFW + Vulkan: Resizing secondary viewports cause example to abort Apr 18, 2024
@InsideBSITheSecond
Copy link
Author

InsideBSITheSecond commented Apr 19, 2024

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 InsideBSITheSecond changed the title GLFW + Vulkan: Resizing secondary viewports cause example to abort backend don't properly handle when vkQueuePresentKHR & vkAcquireNextImageKHR produce VK_ERROR_OUT_OF_DATE_KHR Apr 19, 2024
@InsideBSITheSecond InsideBSITheSecond changed the title backend don't properly handle when vkQueuePresentKHR & vkAcquireNextImageKHR produce VK_ERROR_OUT_OF_DATE_KHR Glfw + Vulkan: backend don't properly handle when vkQueuePresentKHR & vkAcquireNextImageKHR produce VK_ERROR_OUT_OF_DATE_KHR Apr 19, 2024
InsideBSITheSecond added a commit to InsideBSITheSecond/imgui that referenced this issue Apr 20, 2024
@InsideBSITheSecond
Copy link
Author

InsideBSITheSecond commented Apr 20, 2024

#7513 should fix this

@ocornut ocornut added the vulkan label May 7, 2024
@ocornut
Copy link
Owner

ocornut commented May 7, 2024

@ocornut
Copy link
Owner

ocornut commented May 7, 2024

I realize that #3390 aimed to solve the same problem, but it ended up in Vulkan-confusion-procrastination-quagmire.
So hopefully we can close 4-5 issues/pr together here.

ocornut pushed a commit that referenced this issue May 7, 2024
@ocornut
Copy link
Owner

ocornut commented May 7, 2024

This should now be fixed, see other PR:
#3390 (comment)

Both PR were AFAIK near identical in results, given the complexity of this, I would appreciate if everyone affected could confirm that it fixes the situation for them. Thanks everyone!

@ocornut ocornut closed this as completed May 7, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants