RPI VC4 open source driver: shaders cannot be loaded

[gizmo98]

Description

It is not possible to load shaders if MESA VC4 Raspberry Pi driver is used.

Expected behavior

Shaders can be loaded. Broadcom closed source driver works fine.

Actual behavior

There is always a [WARN] [GL]: Failed to set multipass shader. Falling back to stock. message. The driver does not support GL_OES_standard_derivatives. If i remove GL_OES_standard_derivatives in https://github.com/libretro/RetroArch/blob/32a30266545f6fa6e5ddde23c959e1333665704f/gfx/drivers/gl_shaders/shaders_common.h#L6 there is a "wrong precision" error message.

I have saved a log here: retroarchlog.txt

Steps to reproduce the bug

Open menu and select a shader or shader preset.

Version/Commit

Build from latest source

Environment information

• OS: Raspbian Stretch
• Compiler: GCC 6.3
• drm kms gles2 [INFO] [GL]: Vendor: Broadcom, Renderer: Gallium 0.4 on VC4 V3D 2.1. [INFO] [GL]: Version: OpenGL ES 2.0 Mesa 13.0.6. [INFO] [GL]: Default shader backend found: glsl. [INFO] [Shader driver]: Using GLSL shader backend.
• glxinfo: glxinfo.txt

[gizmo98]

Status update: If OpenGL is enabled (--enable-opengl) shaders can be loaded. If OpenGLES is enabled (--enable-opengles) shaders cannot be loaded. Is it possible to confuse the GL profile detection if GLES 2 and GL 2.1 drivers are present?

@bparker06 Just some dumb noob questions. If retroarch is build with OpenGLES enabled EEsProfile should be used? If there are multiple profiles (compat, es profile) which profile will be selected? I don't think retroarch supports GL profiles if GLES is enabled.

[ghost]

The warning about missing derivatives is just a warning, it should not be related to this problem. The only thing that uses that is the non-simplified menu ribbon shader which is disabled for ES platforms that don't support that extension anyway.

I tested ES on my desktop GPU and shaders in-game work fine, so I'm guessing there is some difference in this driver that's causing the precision error... perhaps it's not defining GL_ES, and the particular shader you're using then also doesn't provide a fallback precision in that case (crt-pi doesn't). For example on this line:

https://github.com/libretro/glsl-shaders/blob/master/crt/shaders/crt-pi.glsl#L54

Try adding "mediump" to the end like line 51 has. If that's still not enough, try adding https://github.com/libretro/glsl-shaders/blob/master/crt/shaders/crt-pi.glsl#L52 to a new line under that. Basically we're trying to see if setting the precision when GL_ES is false will fix the issue, and if so, this might be a driver bug or either RA is not requesting the ES vs Desktop GL context correctly.

[ghost]

@gizmo98 If you build with simply --enable-opengles, then it requests an ES context explicitly. You can test this on a recent desktop GPU that supports ES as well, since the renderer string reported to RA will differ when you've compiled with or without ES.

[ghost]

Another thing I noticed is that it gave you an ES3 context when we requested ES2 (assuming you didn't also specify --enable-opengles3). If that's the case, you could try compiling with "--enable-opengles --enable-opengles3" and see what happens.

[gizmo98]

If i add mediump there is a new error message: [INFO] Linker log: error: declarations for uniformFrameDirectionhave mismatching precision qualifiers

runcommand.txt FrameDirection is uniform int.

--enable-gles3 or --disable-gles3 does not change anything.

[gizmo98]

I downloaded crt-pi.glslp and crt-pi.glsl from libretro/glsl-shaders. This shader preset can be loaded. Old and other shader files which run with broadcoms driver blob and VC4 open source GL 2.1 driver do not work.

Working presets: fxaa.glslp cbod_v1.glslp crt-pi.glslp gdapt.glslp pal-r57shell.glslp reshade/gba.glslp reshade/nds.glslp reshade/vba.glslp

[gizmo98]

I found something. All shaders with uniform COMPAT_PRECISION int FrameDirection; can be loaded. All shaders with uniform int FrameDirection; cannot be loaded. If i add COMPAT_PRECISION shaders can be loaded (tested with dot.glsl and lcd3x.glsl).

[psyke83]

@gizmo98

If you check "./configure --help", it shows both opengles and opengles3 are enabled by default. I think that @bparker06 made a mistake and intended for you to try "--enable-opengles --disable-opengles3"?

I tried the above build flags, but there was no improvement with shader loading. Disabling both (and using opengl) does seem to fix shaders, as you said.

[hizzlekizzle]

@gizmo98 ah, I only added the precision macro on the few shaders that complained about it (seemed to be related to the #version strings) on my end, but I just pushed up a commit to add it to the rest. It should populate on the online updater soon. If you don't mind, re-fetch them and give it another shot at your convenience.

[ghost]

Ok so I guess my earlier assumption about GL_ES not being defined must have been incorrect. I was basing that off the assumption from your log paste that you were already using crt-pi and that it didn't work. But since it does, then yes the only thing that should need fixing is adding the COMPAT_PRECISION macro to the other shaders. Your driver just seems extra picky about it I guess.

[gizmo98]

@psyke83 I have updated my retropie rpi-kms branch. Shaders should work now.

Thank you @all. Most shaders work now. Some shaders do not. crt-hyllian.glsl for example still has uniform int FrameDirection; without COMPAT_PRECISION. https://github.com/libretro/glsl-shaders/blob/master/crt/shaders/crt-hyllian.glsl#L84

[psyke83]

Nice work. My guess is that @hizzlekizzle used a sed replace but it didn't catch everything; crt-hyllian.glsl has two spaces between "int" and "FrameDirection". Maybe send a PR to clean up the stragglers such as that one?

pi@retropie:~/RetroPie-Setup/tmp/me/glsl-shaders $ git grep uniform | grep FrameDirection | grep -v COMPAT
crt/shaders/crt-aperture.glsl:uniform int  FrameDirection;
crt/shaders/crt-hyllian-multipass/crt-hyllian-pass0.glsl:uniform int  FrameDirection;
crt/shaders/crt-hyllian-multipass/crt-hyllian-pass1.glsl:uniform int  FrameDirection;
crt/shaders/crt-hyllian.glsl:uniform int  FrameDirection;
xbr/shaders/xbr-lv2.glsl:uniform int  FrameDirection;
``