Support different GLSL versions

[revmischa]

Problem: different systems and drivers have support for different versions of GLSL. ProjectM will not run unless the shader language matches the supported driver version.

As an example, my raspberry pi outputs:

INFO: GL_VERSION: OpenGL ES 2.0 Mesa 13.0.6
INFO: GL_SHADING_LANGUAGE_VERSION: OpenGL ES GLSL ES 1.0.16
INFO: GL_VENDOR: Broadcom
Failed to compile shader 'Vertex: v2f_c4f'. Error: 0:2(1): error: syntax error, unexpected NEW_IDENTIFIER
Failed to compile shader 'Fragment: v2f_c4f'. Error: 0:3(1): error: `in' qualifier in declaration of `fragment_color' only valid for function parameters in GLSL ES 1.00
0:4(1): error: `out' qualifier in declaration of `color' only valid for function parameters in GLSL ES 1.00

And @servimo reports the error:
error: GLSL 3.30 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.00 ES, and 3.00 ES
And again in #101

How can we support multiple versions of GLSL, ES and non-ES?

Also important: detect if GLES is needed automatically in configure.ac so that users don't have to do --enable-gles manually. A decent number of issues on here are related to people not specifying that they need GLES.

More info: #115 #101

@deltaoscarmike could really use your help here

[champagj]

Thank you @revmischa for the new thread.

Trying to run ProjectM on pi 3 and finding it difficult with my limited programming skills.. Back to linux after many years.

Looks like it may be possible to run via QT but also difficult to install/config to run ProjectM.

If you need an "intermediate" tester, I'm here.

[peak3d]

@revmischa gl version is usuallly detected during runtime and not compile time.
But for my GLSL 100 (GLES 2.0) devices there are more changes in shaders needed to get it working

The easiest thing is the version ( 5 minutes work) and the in / out (what is not supported by GLSL 100)
Mor interesting are the layout statements (IIRC) which are not part of GLSL 100

[revmischa]

Yes, i agree it would be great if it could detect the right shader code to load at runtime rather than compile time.

[sergiomb2]

can we run applications without GLSL ? and lib to use in other apps need "compile shader" ?
or can we build projectM without GLSL ?

Thanks

[revmischa]

GLSL is pretty integral now, so you can't build without it.
There is just a quite small amount of work that someone who knows what they are doing needs to do to make the default shaders compile on different GLSL versions.

[sergiomb2]

OK thanks for clarify and about projectM as lib (libprojectM)? libprojectM need GSSL support (GLSL 3.30) ? or apps that use libprojectM render itself ? apps like kodi, clementine or VLC .

[sergiomb2]

Hi,
I have a report saying that libprojectM plugin for kodi is working
"I can confirm that 3.1.1 rc3 works with the latest Kodi projectM visualization plugin 2.2.0" [1]

Thanks,

[1]
https://bugzilla.redhat.com/show_bug.cgi?id=1685314#c2

[ghost]

Is it possible to support OpenGL ES GLSL ES 1.00?

[revmischa]

Probably?

[ghost]

The sdl projectm builds into a binary linked with opengles, but when executed I see the error messages above. “Unsupported shader version”. Any thoughts?

[ghost]

I am guessing that the unsupported shader version is due to my system, which only supports GLSL #version 100 (#define GLSL_VERSION "300 es" doesn't operate) I noticed that the ver and frag sources contain references to layout, in/out, ect that are not supported by GLSL ES 1.00? Are there any plans to support the older spec (raspberry pi, ect) ?

https://github.com/mattdesl/lwjgl-basics/wiki/GLSL-Versions

[revmischa]

It's totally possible I think to support multiple GLSL versions. I don't know how far back it can go. Partly it depends on the HLSL->GLSL transpiler which may emit code that depends on a certain version. Some small amount of coding needs to be done. I don't know what to do, @deltaoscarmike may know, someone else surely does.

[ghost]

I think gles 1.0 compatibility is critical for broadening participation in this project. I strongly recommend we plan a strategy to make this software operate on small embedded systems

…

On Mar 28, 2019, at 2:18 AM, Mischa Spiegelmock ***@***.***> wrote: It's totally possible I think to support multiple GLSL versions. I don't know how far back it can go. Partly it depends on the HLSL->GLSL transpiler which may emit code that depends on a certain version. Some small amount of coding needs to be done. I don't know what to do, @deltaoscarmike may know, someone else surely does. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[deltaoscarmike]

Converting to GLSL 1.0 / Opengl ES 2 is not trivial, it requires to:

• remove "layout(location = x)" shader directives and fetch attributes location with glGetAttribLocation
• replace shader keywords: "in" becomes "attribute" and "out" becomes "varying" (roughly)
• replace texture samplers (glGenSamplers not implemented in opengl es 2) with texture copy. Or alternatively simplify texture wrap and filter parameters handling (eg: parameters are overwritten thus only last ones are applied)
• replace VAO's (not implemented in opengl es 2) but only one is required for opengl 3. Or alternatively use OES_vertex_array_object extension
• replace 3D noise textures with a combination of a flat 3D textures and a shader function to access it. Or alternatively use OES_texture_3D extension

Extensions usage will reduce hardware compatibility but these are available on raspberry pi.

@mancoast Windows headers expose only opengl 1.1 api, but graphics drivers may support newer versions. glad allows to circumvent windows limitation.

[lgbaldoni]

@deltaoscarmike what about GLSL 3.30?

[sergiomb2]

Hi,
I followed a tip from Stellarium/stellarium#663 , which is run :

MESA_GLSL_VERSION_OVERRIDE=130 /usr/bin/projectM-pulseaudio

but still saying Failed to compile shader 'Vertex: v2f_c4f'. Error: 0:1(10): error: GLSL ES 3.00 is not supported. Supported versions are: 1.10, 1.20, 1.30, and 1.00 ES

but surprisingly my default glxinfo says:

OpenGL version string: 2.1 Mesa 18.0.5
OpenGL shading language version string: 1.20
OpenGL ES profile version string: OpenGL ES 2.0 Mesa 18.0.5
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16

[ghost]

The code from this repo requires GLES3 and your platform is GLES2. I recently experienced this exact dilemma when experimenting with embedded systems and projectm

…

On Apr 10, 2019, at 8:23 PM, Sérgio Basto ***@***.***> wrote: Hi, I followed a tip from Stellarium/stellarium#663 , which is run : MESA_GLSL_VERSION_OVERRIDE=130 /usr/bin/projectM-pulseaudio but still saying Failed to compile shader 'Vertex: v2f_c4f'. Error: 0:1(10): error: GLSL ES 3.00 is not supported. Supported versions are: 1.10, 1.20, 1.30, and 1.00 ES but surprisingly my default glxinfo says: OpenGL version string: 2.1 Mesa 18.0.5 OpenGL shading language version string: 1.20 OpenGL ES profile version string: OpenGL ES 2.0 Mesa 18.0.5 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 1.0.16 — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[sergiomb2]

ah! I misread the error, my video card just have low GLSL (shadow languague) 1.10, 1.20, 1.30, and 1.00 ES when it is required GLSL ES 3.00 ...
Hum let me check in a computer in better video card .
Thanks.
Thanks,

[sergiomb2]

ah! I misread the error, my video card just have low GLSL (shadow language) 1.10, 1.20, 1.30, and 1.00 ES when it is required GLSL ES 3.00 ...
Hum let me check in a computer in better video card .

Ya , with one video card that supports OpenGL ES 3.0., it works. So maybe, at least, if we can check OpenGL ES version and if < 3, popup one warning that will fail runs the apps ... and we need at least OpenGL ES 3.0

Thanks

[anoadragon453]

I'm running a card that supports up to GLSL 3.20. Any chance we could make this only slightly older version work?

➜  ~ glxinfo | grep -i "version"
server glx version string: 1.4
client glx version string: 1.4
GLX version: 1.4
    Version: 18.3.6
    Max core profile version: 4.5
    Max compat profile version: 3.0
    Max GLES1 profile version: 1.1
    Max GLES[23] profile version: 3.2
OpenGL core profile version string: 4.5 (Core Profile) Mesa 18.3.6
OpenGL core profile shading language version string: 4.50
OpenGL version string: 3.0 Mesa 18.3.6
OpenGL shading language version string: 1.30
OpenGL ES profile version string: OpenGL ES 3.2 Mesa 18.3.6
OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.20
➜  ~ projectM-pulseaudio                   
Default config: /usr/local/share/projectM/config.inp
reading /home/user/.projectM/config.inp 
[projectM] config file: /home/user/.projectM/config.inp
Failed to compile shader 'Vertex: v2f_c4f'. Error: 0:1(10): error: GLSL 3.30 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.00 ES, 3.00 ES, 3.10 ES, and 3.20 ES

Failed to compile shader 'Fragment: v2f_c4f'. Error: 0:1(10): error: GLSL 3.30 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.00 ES, 3.00 ES, 3.10 ES, and 3.20 ES

Failed to link program: error: linking with uncompiled/unspecialized shadererror: linking with uncompiled/unspecialized shader
Failed to compile shader 'Vertex: v2f_c4f_t2f'. Error: 0:1(10): error: GLSL 3.30 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.00 ES, 3.00 ES, 3.10 ES, and 3.20 ES

Failed to compile shader 'Fragment: v2f_c4f_t2f'. Error: 0:1(10): error: GLSL 3.30 is not supported. Supported versions are: 1.10, 1.20, 1.30, 1.00 ES, 3.00 ES, 3.10 ES, and 3.20 ES

Compiled with ./configure --enable-qt --enable--gles or ./configure --enable-qt. No difference.

[fughilli]

I modified ShaderEngine.cpp to rewrite the shaders in such a way that they can be compiled for GLSL 1.20 and successfully ran an SDL-based libprojectm wrapper with these modifications on a Raspberry Pi 3 with VideoCore IV. My modifications are in this repo if anyone is interested in trying them out. I can also put together a PR for this repo.

[swrobel]

@fughilli any luck getting this into a PR?

[fughilli]

@fughilli any luck getting this into a PR?

Tada! #399

I got sidetracked working on overhauling the HLSL->GLSL translation and shader compilation to support async compilation, since that's currently the major blocker to getting nice smooth performance on SBCs like the Raspberry Pi. Blocking the render thread on translation/compilation is maybe acceptable on desktop/laptop hardware, but is a complete show-stopper for underpowered CPUs.

If anyone has spare cycles for that, I can share some more details, perhaps in a different feature request.

[revmischa]

Yeah blocking on shader compilation is a real issue, even on desktop

[fughilli]

Just merged the backported shader implementations. Without the async fixes, preset transitions are still painfully slow in some cases on my RPi 3a+. I'm working on getting those fixes rolled up, you can follow along on #402.

[kblaschke]

Currently, GLES 3.0 shaders and OpenGL shader language level 3.0 are supported. There's no real way to support lower GLSL levels as they lack texture samplers, and going higher would probably require a rewrite of the HLSL transpiler due to a different syntax for uniforms in the latest shader language levels.

I'm going to close this ticket for now. If there's any specific problem with the shader versions, please open a new issue and provide examples.