Material system GLSL compile error on Intel #1260
Comments
|
This seems to be a driver bug. Also, it's reporting an entirely incorrect line number. |
Intel's driver won't compile the material system GLSL shaders without this extension, GL_ARB_enhanced_layouts. I haven't attemped to determine which "enhanced" syntactic construct we depend on. Just tried it and it works. Fixes DaemonEngine#1260.
|
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? |
This is the case, since the extension spec states:
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.
The text was updated successfully, but these errors were encountered: