GLSL caching bugs are still with us - and they've only grown stronger

[slipher]

Master looks like this for me on the main menu. If I set r_glslCache 0 it works.

[VReaperV]

Can't reproduce.

[VReaperV]

I tried deleting glsl cache, running 0.55.2, then running master again - still no issues.

[slipher]

0.55.2 doesn't even use the same caching scheme, so it probably wouldn't cause a bug. We need to test different branches since the recent caching rewrite

[illwieckz]

Which system, hardware and driver?

[illwieckz]

It may also be useful to know the cvar configuration, because maybe this is only triggered with a specific set of options.

[slipher]

I got this with Nvidia GTX 1070 on Windows. I don't know what the cvars were or how to reproduce it.

[illwieckz]

I may have gotten something similar in the render with temporary commits when debugging #1613

The screen was pitch black on the left part, and white on the right part, perfect vertical division, not a square on top right.

I believed that was my patch that was wrong and added more patches above it. But later when I checked out the old patch, it rendered fine. It's also possible that my patch wasn't the same anymore, but I got surprised that reverting to what I believed to be an older version of my code didn't produce the same thing.

[illwieckz]

@VReaperV do we invalidate the cache if:

• the GLSL code is exactly the same one
• the driver is exactly the same one, with same identification strings (same hardware, etc.)
• but GL/GLSL versions differ?
• or extensions may differ?

[slipher]

That's a good question. I never thought of the possibility that the program binary could be different due to changing which GLSL extensions are enabled.

[slipher]

Besides the possibility of the compiler backend outputting different stuff based on extensions, as I was imagining in the previous comment, there's also an easy way to break it. We use the __VERSION__ builtin macro in several shaders, so if we change GLSL version the source code is effectively different for those.

[illwieckz]

But then __VERSION__ isn't part of the source I guess.

[slipher]

I mean for the stuff like

#if __VERSION__ > 120
out vec4 outputColor;
#else
#define outputColor gl_FragColor
#endif

We can get two different preprocessed source codes depending on which GLSL version is being used.

But then the GLSL version must be set by the #version directive. So if __VERSION__ is always just echoing back the version directive, there is no issue with the same source preprocessing differently.

Anyway this version stuff is a distraction; the bug, in my case at least, clearly was not caused by that.

[VReaperV]

• but GL/GLSL versions differ?

For GLSL versions - yes, and they follow from the GL version.

• or extensions may differ?

Yes, as long as they are used in shaders (i. e. any that are present in the version header).