Open slipher opened 3 months ago
This seems to be a driver bug. Also, it's reporting an entirely incorrect line number.
I tried requesting OpenGL 4.6 (using r_glMajorVersion and r_glMinorVersion) and it compiled! (And worked OK if I turned off GPU occlusion culling.)
So either we're lacking some extension, or Intel's extension loading is buggy. Might we consider requesting a higher core profile than 3.2 when material system is enabled, instead of loading extensions a la carte?
Intel's extension loading is buggy
This is the case, since the extension spec states:
(insert after third paragraph, p. 73) The memory qualifiers "coherent", "volatile", "restrict", "readonly", and "writeonly" may be used in the declaration of buffer variables (i.e., members of shader storage blocks). ... Additionally, memory qualifiers may also be used in the declaration of shader storage blocks.
Might we consider requesting a higher core profile than 3.2 when material system is enabled, instead of loading extensions a la carte?
I think that's reasonable, yeah. Another thing that might work is changing the shader version.
This should work:
diff --git a/src/engine/sys/sdl_glimp.cpp b/src/engine/sys/sdl_glimp.cpp
index e9a28ab38..ad317b247 100644
--- a/src/engine/sys/sdl_glimp.cpp
+++ b/src/engine/sys/sdl_glimp.cpp
@@ -1021,13 +1021,15 @@ static rserr_t GLimp_ValidateBestContext(
For information about core, compatibility and forward profiles,
see https://www.khronos.org/opengl/wiki/OpenGL_Context */
+ bool testGL46 = r_materialSystem.Get();
+
struct {
int major;
int minor;
glProfile profile;
bool testByDefault;
} glSupportArray[] {
- { 4, 6, glProfile::CORE, false },
+ { 4, 6, glProfile::CORE, testGL46 },
{ 4, 5, glProfile::CORE, false },
{ 4, 4, glProfile::CORE, false },
{ 4, 3, glProfile::CORE, false },
I recommend to use a dedicated bool variable and not read the cvar directly because the line setting this bool may be extended later with an option to disable the workaround.
Lower profiles than 4.6 (4.3 and up can be worth checking) might work too.
Yes, I would be curious to know the lowest version that works, and if an extension is missing, that may help to identify it.
4.2 is the lowest that works.
Is there any reason to not just always try to get the highest context version, regardless of driver/hardware? Would also help prevent shader compile errors that happen when core functionality has different naming then the one in an extension, at an earlier point.
I remember @slipher reporting that testing all versions until the one that works can be very slow on Windows.
We can save it in a cvar, then only read from it if the cvar has a valid context number.
Tested with a clean homepath, only setting the 2 cvars to enable material system.