"Failed to create shared context for shader compiling." messages when using OpenGL with Dolphin

[Pokechu22]

Description

When trying to capture Dolphin using the OpenGL backend, Dolphin fails to start the first time and shows a large number of panic alerts.

This isn't a blocker for me, as Dolphin's other video backends use essentially the same shaders so I can do debugging with the other backends (and it seems like vertex and pixel debugging aren't even implemented for OpenGL). But I figure it's still worth reporting as a test case should OpenGL be improved.

Steps to reproduce

1. Download Dolphin 5.0-15105 and the lesson08 fifolog.
2. Launch Dolphin using RenderDoc.
3. In Dolphin, click "Graphics", and change the backend to OpenGL (though OpenGL is the default).
4. In Dolphin, switch to the advanced tab under graphics and check "Enable API Validation Layers" (this may not do anything for OpenGL, actually, but I usually have it on. I did confirm that this issue reproduces with it off too.)
5. In Dolphin, close the graphics window and open the config window. Uncheck "Enable Dual Core" (as the fifoplayer doesn't work well with it).
6. In Dolphin, close the graphics window, and then select "open". Open the Lesson08.dff file from before.
7. Dolphin will pop up the following warning messages; click "OK" on each one:
   • Failed to create shared context for shader compiling.
   • Failed to create shared context for shader compiling.
   • Failed to compile vs shader: C:/Users/Pokechu22/Documents/Dolphin Emulator/Dump/bad_vs_OGL_0.txt
     Debug info (NVIDIA Corporation, NVIDIA GeForce GTX 1650 Ti/PCIe/SSE2, 4.6.0 NVIDIA 471.41):
   • Failed to compile ps shader: C:/Users/Pokechu22/Documents/Dolphin Emulator/Dump/bad_ps_OGL_1.txt
     Debug info (NVIDIA Corporation, NVIDIA GeForce GTX 1650 Ti/PCIe/SSE2, 4.6.0 NVIDIA 471.41):
   • Failed to compile ps shader: C:/Users/Pokechu22/Documents/Dolphin Emulator/Dump/bad_ps_OGL_2.txt
     Debug info (NVIDIA Corporation, NVIDIA GeForce GTX 1650 Ti/PCIe/SSE2, 4.6.0 NVIDIA 471.41):
8. Dolphin will now show a black screen. Stop emulation by hitting esc and then selecting yes. (Note that trying to take a capture on this black screen causes Dolphin to close and no capture to be saved.)
9. Once again open the Lesson08.dff file from before.
10. Dolphin will pop up the following warning messages; click "OK" on each one:
    • Failed to create shared context for shader compiling.
    • Failed to create shared context for shader compiling.
11. This time, the shaders will compile successfully, and a capture can be made, despite those warnings.
12. Opening the capture notes that there are 36 issues. But the capture does seem to load correctly. The capture is available here: Lesson08_OpenGL.zip

Environment

• RenderDoc version: v1.15
• Operating System: Windows 10.0.19042.1165
• Graphics API: OpenGL

[baldurk]

This seems to be related to dolphin using an archaic GL 1.0 function wglShareLists which dates back to really old WGL when it was the only way to share contexts:

https://github.com/dolphin-emu/dolphin/blob/ee863e67220bfb9bb96c853437f2afebdf854480/Source/Core/Common/GL/GLInterface/WGL.cpp#L398-L411

I don't understand why this is being done since dolphin unconditionally relies on the (comparatively) modern wglCreateContextAttribsARB which has a share context as a creation parameter.

For whatever reason wglShareLists is failing when RenderDoc is attached. Possibly because RenderDoc does some work at context create/first activation. I believe wglShareLists is quite sensitive and so maybe that extra work between create and share is making it fail. Unfortunately though it's not possible to defer that work until after wglShareLists because we don't know it's going to be called, and 99% of GL code never uses it.

Removing the call (see below patch) and just passing in the share context directly seems to work fine, though the above referenced commit on the RenderDoc side is also necessary to fix some crashes/further failures due to weird edge-cases in context sharing and pushing/popping internal shared contexts. (OpenGL is a trash API 😢 ).

diff --git a/Source/Core/Common/GL/GLInterface/WGL.cpp b/Source/Core/Common/GL/GLInterface/WGL.cpp
index 69d9e93912..d0d343be01 100644
--- a/Source/Core/Common/GL/GLInterface/WGL.cpp
+++ b/Source/Core/Common/GL/GLInterface/WGL.cpp
@@ -396,20 +396,9 @@ HGLRC GLContextWGL::CreateCoreContext(HDC dc, HGLRC share_context)
                                       0};

     // Attempt creating this context.
-    HGLRC core_context = wglCreateContextAttribsARB(dc, nullptr, attribs.data());
+    HGLRC core_context = wglCreateContextAttribsARB(dc, share_context, attribs.data());
     if (core_context)
     {
-      // If we're creating a shared context, share the resources before the context is used.
-      if (share_context)
-      {
-        if (!wglShareLists(share_context, core_context))
-        {
-          ERROR_LOG_FMT(VIDEO, "wglShareLists failed");
-          wglDeleteContext(core_context);
-          return nullptr;
-        }
-      }
-
       INFO_LOG_FMT(VIDEO, "WGL: Created a GL {}.{} core context", version.first, version.second);
       return core_context;
     }

[Pokechu22]

The fix has been merged into Dolphin (5.0-15150 and newer have it), thanks!

I assume the the other fix relates to the black screen on the first launch. I haven't tested nightly RenderDoc builds, but I did notice that with v1.15 and the fix to Dolphin, trying to make a capture on that black screen no longer causes Dolphin to exit and instead a capture is successfully made (though the contents of the capture aren't particularly useful). It's still possible to work around the black screen by closing and then reopening the fifolog/game, so it's not big problem.

[baldurk]

For me it would either crash (on nvidia) or fail to compile shaders (on AMD) due to context juggling leading to the a mismatch between the context RenderDoc thinks is bound and the actual context and I ended up trampling over state and worse. All due to obtuse rules around DCs and contexts on windows, very tedious :(. A black screen certainly would be possible as well as one of the states I was trampling was the VAO's current index buffer bound.

Either way, it should work properly on the latest nightly and if it doesn't then please let me know.

[Pokechu22]

Yes, the latest nightly (v1.16 - 3d785b9) seems to work fine for me.