My name is Stepan Gatilov (aka stgatilov), I am one of the developers of TheDarkMod game.
I'll write the whole story from the very beginning for the sake of completeness. Note that the most important things will be at the end of the post, so you can probably skip the preamble.
Two players using AMD GPUs reported weird lighting problem with new drivers. The lighting looks bad because normalmap texture samples returns trash in fragment shader (some constant, most likely vec3(0, 0, 0)). I do not have AMD GPU yet, so I decided to exchange apitrace-s with them.
I recorded full apitrace (loading a level plus 10 seconds) on my machine, let's call it cms.trace. The players replayed it on their machines and said it looked equally wrong as if they run the game itself.
Then I asked them to record apitraces on their side, and to my surprise their apitraces played properly on my machine.
So I aksed them to dump OpenGL state which they have when rendering one bumpy object:
glretrace -D 593599 --dump-format json cms.trace >call593599.json
Looking at their OpenGL states, I noticed that the normalmap sampler u_normalTexture was missing in "uniforms". All other uniforms were present, but this one was missing. This obviously causes the weird picture they saw.
Then I looked into the apitraces which the players recorded. Specifically, I looked at the moment during initialization when the shader is compiled and uniforms are queried. There I saw that the u_normalTexture uniform was not found in the shader on their machines:
After that I basically reduced the problem to something smaller, and here I am.
First of all, I have attached the reduced apitrace which I recorded (trim.trace).
This is how to replay it up to the very last command and dump GL state:
glretrace -D 569 --dump-format json trim.trace >trim.json
In the produced state, u_normalTexture must be among "uniforms". On my machine it is there, on the players' machines it is missing.
Second, I have created a standalone MWE based on freeglut demo (attached as package.zip). It can be built by passing the only source file to MSVC, aka "cl repro2.cpp /O2 /W2 /EHsc".
It draws red square and prints messages to console, mainly about missing uniforms. It prints the following on my machine, which makes sense to me:
Uniform not found: u_modelMatrix
Uniform not found: u_shadowMap
Uniform not found: u_lightOrigin2
Uniform not found: u_shadowRect
Player B has "AMD Radeon (TM) R9 390 Series" & "4.6.13544 Compatibility Profile/Debug Context 25.20.15011.1004". For him it additionally prints "Uniform not found: u_normalTexture", which is wrong.
Player H has "Radeon RX 570 Series" & "4.6.13547 Compatibility Profile/Debug Context 25.20.15015.1002". For him it prints something weirder:
CompileShader(interaction.vs): FAILEDVertex shader failed to compile with the following errors:ERROR: 0:63: error(#132) Syntax error: "-" parse errorERROR: error(#273) 1 compilation errors. No code generatedFAIL: sos
It fails to compile the vertex shader for unknown reason. Not even gets to the fragment shader where the main problem appears.
I see the following possible reasons for the problem:
1) We do something wrong in C++ or GLSL. Given the MWE, I would be grateful if someone points me to the problem.
2) There is some shader caching problem. The players tried to disable "Shader Cache" in "Radeon Settings" to no avail. If this is the problem, I would be happy to learn how to clean cache or how to do a proper fresh install of drivers.
3) There is some sort of driver issue here.
I would be happy to hear any ideas.
P.S. The raw original discussion is here.
Thank you for reporting this. You have been whitelisted now. I'm moving this thread to our OpenGL & Vulkan forum.
To help us investigate the issue, could you please provide a reproducible test-case and share the setup details?
Hi stgatilov， Here are some problems in your app:
Thank you for your answer!
Sorry about the text mode bug. It was indeed a bad idea. The game itself reads shader files in binary mode.
As for the main problem about missing uniform. Do I understand it right that:
1) You managed to reproduce the problem.
2) It is probably a driver problem.
3) The problem is only the happening on the ancient GLSL 120, newer GLSL versions are not affected.
We have found some sort of workaround.
As far as I see, some code which was in the global scope in interaction.fs has been moved into a function called from main.
As for moving to GL3.3, it is not so simple. But we plan to do it soon.
By the way, after replacing "fread(fileBuffer, fsize, 1, f);" with "fread(fileBuffer, 1, fsize, f);", you can get the correct length of your shader file. Adding a new variable to present the real length is also an avaliable fix.
GLuint real_length = fread(fileBuffer, 1, fsize, f);
fileBuffer[real_length] = 0;
I assume you already know it.
Anyway, lets back to what you have said, I've done some tests on NV, the same errors are thrown in console, so maybe there are some problems in your shader. But it looks not difficult to fix them.