Hi,
Is there a way to use newer glsl language features on platforms which are officially only compliant to old opengl specifications? I somewhere read about arb shader language pack, however I didn’t find any documentation regarding it.
Thank you in advance, Clemens
E.g.:
-
I would like to run some demo using SSBOs on my Raspberry PI 4. For this demo I need at least GLSL Version 130. The Raspberry-Pi4-Driver supports all the extensions the demo requires (SSBO, bufferStorage, …), however because it lacks a few other mandatory extensions it only officially supports OpenGL 2.1 - and refuses to compile my glsl shaders.
-
Intel on Linux only supports OpenGL-3.0 for compatibility profiles, although for core profile the dirver can go up to OpenGL-4.6. So when using compatibility contexts I am restricted to GLSL 130, despite GLSL 140 should be no problem for the driver and would allow for some optimizations I have to omit for now.
If the implementation doesn’t support a thing, you cannot make it support a thing unless you have access to its code and are willing to get in there and modify it.
That is why I asked for language extensions.
In case I have OpenGL-3 I can use SSBOs via extensions, even if the driver doesn’t support GL-4.3 (the version where SSBOs became mandatory). That is why I wonder if there are extensions for the glsl language itself (there is no need for a driver which is only capable of a 3.0 compatibility context to restrict itself to glsl-130 if the driver would support opengl-4.6 core).
You can use
#extension extension_name : enable
to enable an extension in a shader. E.g.
#extension GL_ARB_shader_storage_buffer_object : enable
Extensions which extend the shading language wouldn’t be much use without this feature.
If you use require instead of enable, the compiler generates an error if the extension isn’t supported. If the shader cannot function without the extension, require should be used. Extensions which extend the shading language typically #define a macro with the same name as the extension so you can implement a fallback if the extension isn’t supported. If you provide a fallback, then use enable.
GClements:
Thanks for the example - I am already using this glsl extension mechanism to use ```
GL_ARB_shader_storage_buffer_object with drivers which only support OpenGL-3 compatibility contexts.
However, one example where this does not work is the Raspberry Pi 4. It supports tons of modern extensions (like SSBOs), but officially only exposes OpenGL-2.1 support (and therefore only glsl 120).
When I try to declare the SSBO in a #version 120 file, I get some errors about “UNEXPECTED NEW IDENTIFIER”:
"#version 120\n"
"#extension GL_ARB_shader_storage_buffer_object : require\n"
"#extension GL_ARB_fragment_coord_conventions : require\n"
"layout (binding = 0) buffer position {\n"
" uint[] mask;"
"};"
so I wonder - how useful can GL_ARB_shader_storage_buffer_object be, if the glsl version provided is too limited to access it properly?
Thanks, Clemens
GLSL 1.2 doesn’t have unsigned integers (in fact, integers are just syntactic sugar; it’s implied that all variables are actually floats). You might try using
#extension GL_EXT_gpu_shader4 : require
But that extension doesn’t add the uint keyword (I’m not sure which extension adds that, if any; it’s not something that can easily be searched for), so you need to use unsigned int instead.
If you’re trying to use 4.x code on a platform which only provides 1.2, but with most 4.x features available as extensions, you’re going to need to use a lot of extensions. If you overlook one, your code won’t work.
GClements thanks a lot, GL_EXT_gpu_shader4 in conjunction with unsinged int did the job - the shader now also works with glsl version 120 
However, now I get segfaults in the raspberry pi driver - I guess I am expecting a bit too much from the raspberry pi driver, now that most attention is directed towards the vulkan interface.
Thanks & best regards, Clemens