GLEW with glewExperimental reports all extensions as supported on GLX/Mesa.

[SingularityCat]

GLEW erroneously reports extensions as supported on GLX/Mesa.

For instance, Mesa does not support GL_ARB_shading_language_include however, GLEW reports it as available and provides function pointers for it - this is a sample of glewinfo from my Mesa system:

GL_ARB_shading_language_include:                               OK [MISSING]
--------------------------------
  glCompileShaderIncludeARB:                                   OK
  glDeleteNamedStringARB:                                      OK
  glGetNamedStringARB:                                         OK
  glGetNamedStringivARB:                                       OK
  glIsNamedStringARB:                                          OK
  glNamedStringARB:                                            OK

After doing a bit of digging, it seems that GLEW will look for non-null function pointers to assess whether an extension is supported. This is a problem as Mesa's glXGetProcAddress never returns NULL (source), even for totally made up function names.

[nigels-com]

That's the long-established behaviour of GLEW. It's recommend that the application checks for the relevant extensions or GL version number before calling the entry point.

[SingularityCat]

Hmm, this isn't the impression I initially got from reading the documentation (http://glew.sourceforge.net/basic.html).

Checking for Extensions

Starting from GLEW 1.1.0, you can find out if a particular extension is available on your platform by querying globally defined variables of the form GLEW_{extension_name}:

if (GLEW_ARB_vertex_program)
{
 /* It is safe to use the ARB_vertex_program extension here. */
 glGenProgramsARB(...);
}

The way I read this, checking GLEW_ARB_shading_language_include should be sufficient to tell me if the extension is available and safe to use.

I actually fell down this particular rabbit hole while understanding the hacks and workarounds required to get "Divinity: Original Sin" working with Mesa on Linux - see this Mesa bug report for all the funky details. (Divinity doesn't actually check the GLEW_{extension_name} variables, but I noticed that even if it did, this would still be a problem).

[nigels-com]

Is the application using experimental mode? That might explain why you're not seeing the intended and documented behaviour.

[SingularityCat]

Hmm, I think it does - I'll confirm this later.

It's also bundled and linked against an older version of GLEW - version 1.10.0 (as for why, I have no idea). IIRC, this version needed glewExperimental to work with a core context, which might explain why they've set it.

It would seem glewExperimental renders the GLEW_{extension_name} variables totally meaningless on Mesa. I suppose such breakage should be expected when using functionality marked as "Experimental" 😃.

Perhaps it's worth ignoring glewExperimental on Mesa, given the huge number of false positives? Or allowing the end user to force GLEW to use a specific value, via some envvar like GLEW_FORCE_EXPERIMENTAL.

[SingularityCat]

It does indeed. Replacing the bundled GLEW with a newer version and forcing glewExperimental to GL_FALSE works as intended.

[nigels-com]

Glad to hear that!

[SingularityCat]

This still leaves the issue of glewExperimental rendering programs unusable on Mesa (which is particularly frustrating as the developers of this particular title seem to have no intention of fixing it).

Given the fact that lots of glewExperimental usage prior to GLEW 2.0 was likely due to lack of core context support, maybe it would make sense to ignore glewExperimental and instead look at a new symbol (glewReallyExperimental?) instead for new versions.

If you think this approach is not too awful, I'll give it a shot. In either case, I think perhaps a warning added to documentation about glewExperimental's interaction with certain OpenGL implementations is the only thing needed to hopefully stop this happening in the future.

(Thanks for the help!)

[nigels-com]

I think a good way forward on this is to provide a compile-time opt-out for experimental mode. It would still be there by default for the purpose of backwards compatibility. But you could force-disable it with a custom-built GLEW shared library?

[SingularityCat]

I suppose my end goal is to make it slightly easier to run broken stuff that the original developers can't be bothered fixing - this isn't really GLEW's problem.

On reflection, I think hacking up GLEW in this way doesn't really solve much either -- you'd still need to update bundled copies, and there's the chance you break a buggy graphics driver that doesn't list all it's supported extensions properly.