Hang when destroying viewports in example_sdl2_opengl3 (only when vsync is deactivated)

nobledemon commented 3 months ago

Version/Branch of Dear ImGui:

Version v1.90.9 WIP, Branch: Docking

Back-ends:

imgui_impl_SDL2.cpp + imgui_impl_opengl3.cpp

Compiler, OS:

Windows 10 + MSVC 2022

Full config/build information:

Dear ImGui 1.90.9 WIP (19082)
--------------------------------
sizeof(size_t): 8, sizeof(ImDrawIdx): 2, sizeof(ImDrawVert): 20
define: __cplusplus=199711
define: _WIN32
define: _WIN64
define: _MSC_VER=1939
define: _MSVC_LANG=201402
define: IMGUI_HAS_VIEWPORT
define: IMGUI_HAS_DOCK
--------------------------------
io.BackendPlatformName: imgui_impl_sdl2
io.BackendRendererName: imgui_impl_opengl3
io.ConfigFlags: 0x00000443
 NavEnableKeyboard
 NavEnableGamepad
 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: 1280.00,720.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:

When disabling vsync, I'm experiencing a silent hang in the sdl2 + opengl3 docking example. It occurs when trying to drag a window inside a bigger window. I'm attaching a video of the behavior (although it's probably hard to see it, I'm clicking trying to drag things after dragging a window and releasing it on top of another one, but the program has become unresponsive).

Then breaking the debug in visual studio, I noticed that the next statement of execution is inside ImGui_ImplSDL2_DestroyWindow. I'm attaching a screenshot of this as well, and the call stack, not sure if it would be helpful or not.

Screenshots/Video:

hang.webm

Minimal, Complete and Verifiable Example code:

// modified line 79 of example_sdl2_opengl3/main.cpp to disable vsync
SDL_GL_SetSwapInterval(0); // 0 for immediate updates

PathogenDavid commented 3 months ago

It looks like it's actually stuck within SDL_GL_DeleteContext. I imagine if you enabled showing external code in the stack trace that you'd see it's stuck in your graphics driver. You should try updating it. It'd also be helpful to know what GPU you have

nobledemon commented 3 months ago

You are right! So, I have a Radeon RX 5500M and an Integrated AMD Ryzen 7 4800H with Radeon graphics (I assume that means it's just an integrated card. Sad to say I don't know much about Graphic card numbers or types. Also, aren't both cards integrated when they are inside a laptop?). The drivers are up to date.

Just for curiosity's sake, I tried to force the example to use the dedicated card. This seems to take care of the issue for some reason. Although the problem persists on the integrated graphics card. extern "C" { __declspec(dllexport) int AmdPowerXpressRequestHighPerformance = 1; }

GamingMinds-DanielC commented 3 months ago

I use neither SDL nor OpenGL, but this sounds a lot like the backend trying to release resources that are still in use by the graphics hardware. Basically a synchronization issue, which means that the crash depends on timing and GPU load. In that case it should happen even with VSync enabled if you saturate your GPU with work and it didn't have enough time to catch up yet when destroying the context. Depending on the guarantees OpenGL makes this could be an error in the backend implementation (improper synchronization) or a driver bug.

PathogenDavid commented 3 months ago

I assume that means it's just an integrated card.

Correct. The Ryzen GPU is your iGPU and the Radeon one is your dGPU.

Also, aren't both cards integrated when they are inside a laptop?

In modern times "integrated GPUs" refers to GPUs integrated with the CPU. (As opposed to GPUs integrated into the motherboard like you used to see on desktops eons ago.)

The drivers are up to date.

That is unfortunate because this smells like a driver bug.

Could you see if the issue happens with example_glfw_opengl3? I imagine it does, but in the off chance it doesn't that might mean a workaround exists for us.

Just for curiosity's sake, I tried to force the example to use the dedicated card. This seems to take care of the issue for some reason. Although the problem persists on the integrated graphics card.

Good test!

Yeah, the issue applying specifically to the iGPU probably part of the bug from AMD's perspective.

this sounds a lot like the backend trying to release resources that are still in use by the graphics hardware.

@GamingMinds-DanielC Good theory, but in OpenGL object lifetimes are managed by the driver so even if this is the case it's still a driver bug.

nobledemon commented 3 months ago

I just tried on opengl3 + glfw, the problem doesn't seem to happen. Neither it seems to happen with sdl2 + dx11 example, although I have not checked which graphic cards are being picked in these examples now that I think about it.

For now, manually picking the working card is enough for me, although if you want me to do more tests, I can try to find more time on the following weeks.

PathogenDavid commented 3 months ago

Thanks for reporting back!

I just tried on opengl3 + glfw, the problem doesn't seem to happen.

That's quite surprising. If you could verify that it's running on the iGPU when you get a chance that'd definitely be great, but if you're happy there's no rush.

(With vsync off you'd probably be able to tell which GPU is being used just by looking at which one is busy in Task Manager. You can also enable the GPU engine column in the details tab and check it.)

ocornut / imgui