Backport GLSL shaders to version 1.2 to support older hardware.

[fughilli]

This PR backports the GLSL hardcoded shaders in ShaderEngine.cpp to GLSL1.2 and also adds another target version to hlslparser to export GLSL1.2. These changes enable running ProjectM on hardware which supports only older GLSL versions, such as the VideoCore IV GL implementation used by the Raspberry Pi (versions <=3).

[revmischa]

Yo, this is terrific! Thanks!

I think older Pis may have issues anyway due to CPU limitations (mine certainly did running without shaders)

If this means we can require a lower minimum GL version this should be updated - https://github.com/projectM-visualizer/projectm/blob/master/src/projectM-sdl/projectM_SDL_main.cpp#L307

If there's any way to keep our modified hlslparser in sync with upstream that would be super cool https://github.com/Thekla/hlslparser/tree/master/src

[fughilli]

CPU limitations are definitely an issue. I'm using the Pi to run an addressable LED array with ~3000 pixels, so much smaller raster and grid size is OK, plus I'm curating presets that run smoothly. I mentioned in #168 that async would help with this. Another potential plus would be supporting vectorization on ARM (I see that only SSE intrinsics are used for acceleration currently). One way to do this scalably would be to rewrite the fixed-function parts of the per-frame and per-vertex equations in Halide.

[fughilli]

Re: keeping things in sync with upstream; any reason this project is not making use of submodules and/or a build system with imports? I used Bazel for my fork and that also allowed me to support cross-compilation (compiling projectM from source every time on the Pi itself is absolutely miserable).

[revmischa]

Async would help.
Enabling LLVM JIT compilation of presets may speed things up for the CPU and utilize things like vectorization. A little bit of work is needed to make --enable-llvm work with recent versions of llvm - #360

[revmischa]

Upgrading build system is fine, though it may make downstream projects 😞
It was CMake long ago and it was a huge pain in the ass to deal with

[revmischa]

Tested on macOS Catalina:

2020-08-08 15:07:41.885 projectMSDL[52080:1382685] INFO: GL_VERSION: 4.1 ATI-3.9.15
2020-08-08 15:07:41.885 projectMSDL[52080:1382685] INFO: GL_SHADING_LANGUAGE_VERSION: 4.10
2020-08-08 15:07:41.885 projectMSDL[52080:1382685] INFO: GL_VENDOR: ATI Technologies Inc.
2020-08-08 15:07:41.886 projectMSDL[52080:1382685] INFO: Using data directory: /usr/local/share/projectM
2020-08-08 15:07:41.886 projectMSDL[52080:1382685] INFO: Config file not found, using built-in settings. Data directory=/Users/cyber/dev/projectm/src/projectM-sdl/
Failed to compile shader 'Vertex: v2f_c4f'. Error: ERROR: 0:1: '' :  version '120' is not supported
ERROR: 0:2: '' :  #version required and missing.
ERROR: 0:2: 'attribute' : syntax error: syntax error

Failed to compile shader 'Fragment: v2f_c4f'. Error: ERROR: 0:1: '' :  version '120' is not supported
ERROR: 0:2: '' :  #version required and missing.
ERROR: 0:2: 'varying' : syntax error: syntax error

Failed to link program: ERROR: One or more attached shaders not successfully compiled

Perhaps we need to be able to run different versions of the shader code depending on the GL version?

[fughilli]

Maybe we could query the available GL version using glGetString and then select a variant of the shaders that way? If we go that route, I would propose taking the shader code out of string literals and instead either load them in at runtime or compile them in as binary resources.

[revmischa]

Yeah makes sense

[fughilli]

I ran a small test program on both my RPi 3A and my Razer Blade 14" 2017:

... GL context setup ...
std::cout << "GL version: " << glGetString(GL_VERSION) << std::endl;
...

Razer Blade:
GL version: 4.6.0 NVIDIA 390.132

Raspberry Pi:
GL version: 2.1 Mesa 13.0.6

Looking at this table, I can map the version number to a GLSL version. I'm thinking as a first pass that we can select the GLSL1.2 code for GL version <= 3.2, and the original GLSL3.3 code for GL version >= 3.3.0.

[fughilli]

Added another commit to the PR which refactors the shaders out into a separate manager. The manager queries the supported GLSL version and picks either the original GLSL3.3 shaders or the backported GLSL1.2 shaders depending on the result of the query.

[fughilli]

I also opened #402

[fughilli]

It looks like the builds are failing because the new sources are not included in the project manifests for the XCode and Visual Studio builds. Does someone else have the time to add them?

[milkdropper]

I'll do the visual studio bits tonight.

[fughilli]

What remains to be done to get this merged? @milkdropper do you have a fixed VS project file? Also I think the XCode project file needs to be updated--I don't have a Mac, so I can't do it.

[milkdropper]

What remains to be done to get this merged? @milkdropper do you have a fixed VS project file? Also I think the XCode project file needs to be updated--I don't have a Mac, so I can't do it.

I'll give it another shot with msvc. I actually had problems last time I tried, but will take a look with a fresh set of eyes.

[fughilli]

Nice! Thanks for the assist!

gif