Matching versions in OpenGL, GLES and GLSL

[HeadCase]

Yesterday I compiled the latest version of https://www.raylib.com to test on RPi 4. Raylib is an easy to use graphics library that lets you do basic 2d/3d apps with minimal pain. It comes with a large set of tutorial examples that highlight the various features.

Most of the examples run without problems, however there are a few that fail because they ask for GLSL 3.30, and RPi 4 reports GLSL 3.00. So, looking at the versioning for OpenGL, GLES and GLSL, it looks to be rather confusing.

https://en.wikipedia.org/wiki/OpenGL_Shading_Language

The Pi 4 is supporting GLSL ES 3.00, GL ES 3.0, WebGL 2.0 - which seems to match the second table on that wiki page. However, that table also says that GLSL ES 3.00 is based on GLSL 3.30. To add to the confusion, GLSL 3.00 does not even appear in the non-ES list of GLSL versions, which is presumably the result of jumping from 1.50.11 to 3.30.6 in a single hop.

As far as I can tell, the shaders in Raylib should probably work on the Pi 4. In the world of desktop software, programmers are most likely going to use the versions from the upper non-ES version list, and 3.30 looks like an obvious choice - which might be a cause of problems.

I am not entirely convinced that Khronos have done a great job with their version numbers.

[gustafla]

As an Alacritty user I'd also like the driver to at least report GL 3.3 and GLES 330 core compatibility regardless if it has everything implemented

[Paeryn]

As an Alacritty user I'd also like the driver to at least report GL 3.3 and GLES 330 core compatibility regardless if it has everything implemented

The drivers are never going to report versions that they don't support, that kind of defeats the purpose of having version numbers. If you think whatever program you are wanting to run is just requesting a higher version than what it needs and are sure it will not try using anything that requires the higher version then you can tell Mesa to report the higher version by setting a few environment variables, just don't complain if it crashes. The environment variables that affect version reporting are as follows, note that setting these doesn't mean Mesa will emulate any missing functionality, they are primarily there for developers.

Code: Select all

MESA_GL_VERSION_OVERRIDE=3.3    # Pretend to have GL 3.3
MESA_GLSL_VERSION_OVERRIDE=330  # Pretend to have GLSL 3.30
MESA_GLES_VERSION_OVERRIDE=3.1  # Pretend to have GLES 3.1

Here's glxgears reporting version info both at default and with GL version set to 3.3 (I know that glxgears isn't going to try using any 3.3 features so is safe)

Code: Select all

[email protected]:~ $ glxgears -info
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
GL_RENDERER   = VC4 V3D 2.1
GL_VERSION    = 2.1 Mesa 19.1.0-devel
GL_VENDOR     = Broadcom

[email protected]:~ $ MESA_GL_VERSION_OVERRIDE=3.3 glxgears -info
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
GL_RENDERER   = VC4 V3D 2.1
GL_VERSION    = 3.3 (Compatibility Profile) Mesa 19.1.0-devel
GL_VENDOR     = Broadcom

When I first tested this I forgot to tell it to render it to the RPi's display rather than to my PC's (I'm logged in remotely), makes it look like I've got an RPi with an RX480 GPU

Code: Select all

[email protected]:~ $ glxgears -info
libGL error: No matching fbConfigs or visuals found
libGL error: failed to load driver: swrast
Running synchronized to the vertical refresh.  The framerate should be
approximately the same as the monitor refresh rate.
GL_RENDERER   = Radeon (TM) RX 480 Graphics
GL_VERSION    = 1.4 (4.6.13559 Compatibility Profile Context 26.20.12001.11014)
GL_VENDOR     = ATI Technologies Inc.
GL_EXTENSIONS = ... <snipped for brevity>
73495 frames in 5.5 seconds = 13403.212 FPS