 |
Cannot reproduce it on GeForce, both on 2.07-hotfix and SVN. But I managed to reproduce it on RX 550 on 2.07-hotfix). Here is unmangled stack trace: > atio6axx.dll!00007fff4c3ec1c9() Unknown TheDarkModx64.exe!R_LoadARBProgram(int progIndex) Line 576 C++ TheDarkModx64.exe!R_FindARBProgram(unsigned int target, const char * program) Line 643 C++ TheDarkModx64.exe!idMaterial::ParseStage(idLexer & src, const textureRepeat_t trpDefault) Line 1516 C++ TheDarkModx64.exe!idMaterial::ParseMaterial(idLexer & src) Line 2126 C++ TheDarkModx64.exe!idMaterial::Parse(const char * text, const int textLength) Line 2212 C++ TheDarkModx64.exe!idDeclLocal::ParseLocal() Line 2176 C++ TheDarkModx64.exe!idDeclManagerLocal::FindType(declType_t type, const char * name, bool makeDefault) Line 1114 C++ [Inline Frame] TheDarkModx64.exe!idWindow::SetupBackground() Line 1404 C++ TheDarkModx64.exe!idWindow::SetupFromState() Line 1422 C++ TheDarkModx64.exe!idWindow::Parse(idParser * src, bool rebuild) Line 2512 C++ TheDarkModx64.exe!idUserInterfaceLocal::InitFromFile(const char * qpath, bool rebuild, bool cache) Line 290 C++ TheDarkModx64.exe!idUserInterfaceManagerLocal::FindGui(const char * qpath, bool autoLoad, bool needUnique, bool forceNOTUnique) Line 189 C++ [Inline Frame] TheDarkModx64.exe!newGui(const char *) Line 30 C++ TheDarkModx64.exe!COverlaySys::setGui(int handle, const char * file) Line 321 C++ TheDarkModx64.exe!idEntity::CreateOverlay(const char * guiFile, int layer) Line 12526 C++ TheDarkModx64.exe!idPlayer::UpdateUnderWaterEffects() Line 7561 C++ TheDarkModx64.exe!idPlayer::Think() Line 7805 C++ TheDarkModx64.exe!idGameLocal::RunFrame(const usercmd_t * clientCmds) Line 3424 C++ TheDarkModx64.exe!idSessionLocal::RunGameTic() Line 2954 C++ [Inline Frame] TheDarkModx64.exe!idSessionLocal::RunGameTics() Line 3022 C++ TheDarkModx64.exe!idSessionLocal::FrontendThreadFunction() Line 3068 C++ It crashes on calling qglBindProgramARB inside R_LoadARBProgram. The call arguments look valid to me. Except for the fact that TDM does not use glGenPrograms, and instead assigns program identifiers sequentally =) The problem may be caused by the fact that shader is loaded in frontend thread. OpenGL is sensible to such things. |
|
|
Ok, I took some random brush and changed its material to "textures/water_source/water_overlay". As the result, the crash does NOT happen. The explanation is simple: if some map brush uses the material, then it gets loaded on start, and such loading works OK. I guess loading materials which are used by statically spawned entities also works fine. The problem happens when some material is loaded during gameplay, and it is the first one to use some new shader program. As the result, the shader program gets loaded from wrong place, causing the crash. I wonder how it works with dynamically spawned entities (e.g. when you spawn water arrow on a clean map, which is the first to use heatHaze shader). |
|
|
Ok, I get the same crash simply by loading a small test map and executing: g_testPostProcess textures/postprocess/rotoedge This results in loading rotoedge.vfp shader, which was not loaded during map load. Here is the stack trace: atio6axx.dll!00007fff4c3ec1c9() Unknown > TheDarkModx64.exe!R_LoadARBProgram(int progIndex) Line 576 C++ TheDarkModx64.exe!R_FindARBProgram(unsigned int target, const char * program) Line 643 C++ TheDarkModx64.exe!idMaterial::ParseStage(idLexer & src, const textureRepeat_t trpDefault) Line 1516 C++ TheDarkModx64.exe!idMaterial::ParseMaterial(idLexer & src) Line 2126 C++ TheDarkModx64.exe!idMaterial::Parse(const char * text, const int textLength) Line 2212 C++ TheDarkModx64.exe!idDeclLocal::ParseLocal() Line 2176 C++ TheDarkModx64.exe!idDeclManagerLocal::FindType(declType_t type, const char * name, bool makeDefault) Line 1114 C++ TheDarkModx64.exe!idPlayerView::SingleView(idUserInterface * hud, const renderView_s * view, bool drawHUD) Line 620 C++ TheDarkModx64.exe!idPlayerView::RenderPlayerView(idUserInterface * hud) Line 997 C++ TheDarkModx64.exe!idGameLocal::Draw(int clientNum) Line 3672 C++ TheDarkModx64.exe!idSessionLocal::Draw() Line 2559 C++ [Inline Frame] TheDarkModx64.exe!idSessionLocal::DrawFrame() Line 3036 C++ TheDarkModx64.exe!idSessionLocal::FrontendThreadFunction() Line 3071 C++ |
|
|
The problem does NOT happen on SVN, because ARB shaders are no longer used: everything has been migrated to GLSL. For this reason, this issue can be suspended for now, then reevaluated after 2.08 is out. What I find alarming is that overlay in the middle water does not work properly in terms of window size. This is most likely caused by: https://bugs.thedarkmod.com/view.php?id=5068#c11976 |
 |
What should happen here? This is how it looks to me: https://ibb.co/wRCDr6D |
|
|
From above, it looks like crystal clear water. Dive into pools to see GUI overlays in action. The left/right ones are working, but they don't use shader. The middle one uses a shader, and for me shader does not cover the whole screen on SVN. |
 |
SteveL mentioned visual glitching with that overlay in his 16:9 monitor at https://bugs.thedarkmod.com/view.php?id=4214#c7821 and I think that's why he linked 0004084 to that bug. I don't know whether it's the same issue you're seeing since it was in the 2,03/2.04 era. |
|
|
It does crash to me with ARB2 shader. Not sure if it needs fixing too. Threads conflict. I suppose it might only crash on AMD though (thumbdown.png) atio6axx.dll!00007fff5040c1c9() Unknown > TheDarkModx64NoTools.exe!R_LoadARBProgram(int progIndex) Line 124 C++ TheDarkModx64NoTools.exe!R_FindARBProgram(unsigned int target, const char * program) Line 194 C++ TheDarkModx64NoTools.exe!idMaterial::ParseStage(idLexer & src, const textureRepeat_t trpDefault) Line 1555 C++ TheDarkModx64NoTools.exe!idMaterial::ParseMaterial(idLexer & src) Line 1850 C++ TheDarkModx64NoTools.exe!idMaterial::Parse(const char * text, const int textLength) Line 2267 C++ TheDarkModx64NoTools.exe!idDeclLocal::ParseLocal() Line 2182 C++ TheDarkModx64NoTools.exe!idDeclManagerLocal::FindType(declType_t type, const char * name, bool makeDefault) Line 1120 C++ TheDarkModx64NoTools.exe!idWindow::SetupBackground() Line 1405 C++ TheDarkModx64NoTools.exe!idWindow::SetupFromState() Line 1424 C++ TheDarkModx64NoTools.exe!idWindow::Parse(idParser * src, bool rebuild) Line 2512 C++ TheDarkModx64NoTools.exe!idUserInterfaceLocal::InitFromFile(const char * qpath, bool rebuild, bool cache) Line 290 C++ TheDarkModx64NoTools.exe!idUserInterfaceManagerLocal::FindGui(const char * qpath, bool autoLoad, bool needUnique, bool forceNOTUnique) Line 189 C++ [Inline Frame] TheDarkModx64NoTools.exe!newGui(const char *) Line 30 C++ TheDarkModx64NoTools.exe!COverlaySys::setGui(int handle, const char * file) Line 321 C++ TheDarkModx64NoTools.exe!idEntity::CreateOverlay(const char * guiFile, int layer) Line 12334 C++ TheDarkModx64NoTools.exe!idPlayer::UpdateUnderWaterEffects() Line 7390 C++ TheDarkModx64NoTools.exe!idPlayer::Think() Line 7631 C++ TheDarkModx64NoTools.exe!idGameLocal::RunFrame(const usercmd_t * clientCmds, int timestepMs) Line 3209 C++ TheDarkModx64NoTools.exe!idSessionLocal::RunGameTic(int timestepMs) Line 3052 C++ TheDarkModx64NoTools.exe!idSessionLocal::RunGameTics() Line 3127 C++ TheDarkModx64NoTools.exe!idSessionLocal::FrontendThreadFunction() Line 3173 C++ [Inline Frame] TheDarkModx64NoTools.exe!idSessionLocal::StartFrontendThread::__l2::<lambda_16de5467341aba11472bb29a736528b0>::operator()(void *) Line 3265 C++ TheDarkModx64NoTools.exe!<lambda_16de5467341aba11472bb29a736528b0>::<lambda_invoker_cdecl>(void * x) Line 3267 C++ [External Code] |
|
|
Do we want to split these two very different bugs? One is ARB2 shader load from the frontend thread Another is the GUI shader broken visuals. |
|
|
I have suspended this issue, since SVN is already on GLSL completely, where the crash does not happen. As for broken visual, I suggest fixing it in 0005068, where you broke it (since it happened very recently). |
|
|
Since C++ code for ARB shaders is being removed completely for 2.09, this is no longer a problem. |
|
|
I can still reproduce this on 2.09 (now using Linux, Intel/Nvidia). |
|
|
Does not crash for me on SVN Although the gui does not work either Are you actually testing this with that 2015 test map? EDIT: NM, it did crash after TDM restart @stgatilov, the underlying issue still persists the AMD driver crashes on qglCreateProgram from the frontend thread |
|
|
Yes, it crashes on my RX 550 too, with same repro steps and call stack as in: https://bugs.thedarkmod.com/view.php?id=5012#c12012 |
|
|
Add a shader placeholder to be replaced on first access from the main thread? |
 |
Should be fixed with 9526. |
|
|
The "wet" map does not crash for me on current SVN (AMD 6850) |
- Anonymous
