Getting stuck on Initializing OpenGL subsystem #386
Comments
|
Weird - can you run it again with Also, what GPU and driver are you using? Do other games work? |
|
I can't even copy the full output because it becomes an infinite string of Also I'm using a Radeon RX 5700 XT, with the default Mesa drivers, from what I can tell. Other games work just fine, yes. |
shouldn't have reused i in the inner loop..
|
Ahh, good to know - I think I just found a very stupid bug in that code that would explain your problem. Can you test if this change fixes it: 06390e8 ? (Or test the whole branch: https://github.com/dhewm/dhewm3/tree/gamma-in-shader) Thanks in advance! :) |
|
The game launches on that branch, but now every texture is extremely messed up:
|
|
groovy! can you post the new terminal output (with r_developer 1)? |
|
Is |
|
yes, that's what I meant, sorry |
|
Here it is, menu + loading a save: |
|
Thanks! This is weird - it looks absolutely ok: My best guess is that something is wrong with your driver - maybe a regression in support for OpenGL ARB shaders (almost noone uses them, which could explain that other games work)? |
|
Yup that works fine other than not being able to set the resolution to my actual native one (1440p) |
shouldn't have reused i in the inner loop..
|
@Yamagi ran into the same messed up texture problem (but not the getting stuck problem) and it turned out that it was introduced with this commit: dc42bdc Furthermore, I still can't reproduce that issue on my XUbuntu 20.04 box with an Radeon RX580; he's using an RX 5700XT on Arch Linux. So it seems possible that either this is a Polaris vs Navi problem or, more likely, an issue introduced in Mesa 21 (or at least in some version between 20.2.6 and 21.1.1). As it works everywhere else (and on older mesa versions; also on the same XUbuntu 20.04 version with an intel iGPU on my laptop) this looks like a regression in Mesa, though I have no idea why it would be broken only after reloading the shaders. |
|
Here's my |
|
Thanks! |
|
I just pushed a commit to the master branch that should work around this issue, can you test it? |
|
Hey it worked! Thanks! |
|
Awesome, thanks for the confirmation! |
|
I installed the oibaf PPA mesa version (21.2.0-devel 2021-06-26) on my machine with the Radeon RX580 and can reproduce the glitches, so it seems like the bug indeed is specific to newer Mesa versions (and not to Polaris vs Navi) |
|
I created a bugreport at Mesa's bugtracker: https://gitlab.freedesktop.org/mesa/mesa/-/issues/5001 |
shouldn't have reused i in the inner loop..
this *shouldn't* matter, but due to some Mesa bug is does: If the shaders have been loaded already (with R_LoadARBProgram()), then loading them again (like from the `reloadARBprograms` console cmd or as it happens if the `r_gammaInShader` has been modified) will cause glitches with the open source radeonsi driver (maybe also with others? at least the open source intel driver seems unaffected). As r_gammaInShader was marked as modified at startup (before the shaders were even loaded) they were loaded twice: First as expected when OpenGL is initialized, then again in R_CheckCvars() which is executed each frame. Marking as at not modified in R_InitOpenGL() prevents this and thus works around the bug. However this means that changing r_gammaInShader at runtime will still trigger this bug (while with non-broken drivers it switches seamlessly between gamma in shader and gamma in hardware without a vid_restart).
that was an important fix
I'm trying to launch dhewm3 but it keeps getting stuck on
Initializing OpenGL subsystem, no idea why.I'm running it on Arch Linux. I pasted the terminal output into a text file:
dhewm_log.txt
The text was updated successfully, but these errors were encountered: