[Linux] "Failed to compile vertex shader stage" on second core launch since upgraded to 1.10.0

[TiBeN]

Description

Since i upgraded to RetroArch 1.10, slang shaders do not apply the second time i launch a core (whatever the core, i use a global preset). On the second run there is the following error:

[INFO] [Shaders]: Specific shader preset found at "/home/ben/.config/retroarch/config/global.slangp".
[INFO] Watching file for changes: /home/ben/.config/retroarch/shaders/shaders_slang/crt/crt-lottes-multipass-glow.slangp
[INFO] Watching file for changes: /home/ben/.config/retroarch/shaders/shaders_slang/crt/shaders/crt-easymode-halation/linearize.slang
[INFO] Watching file for changes: /home/ben/.config/retroarch/shaders/shaders_slang/crt/shaders/crt-easymode-halation/blur_horiz.slang
[INFO] Watching file for changes: /home/ben/.config/retroarch/shaders/shaders_slang/crt/shaders/crt-easymode-halation/blur_vert.slang
[INFO] Watching file for changes: /home/ben/.config/retroarch/shaders/shaders_slang/crt/shaders/crt-easymode-halation/threshold.slang
[INFO] Watching file for changes: /home/ben/.config/retroarch/shaders/shaders_slang/crt/shaders/crt-lottes-multipass/bloompass.slang
[INFO] Watching file for changes: /home/ben/.config/retroarch/shaders/shaders_slang/crt/shaders/crt-lottes-multipass/scanpass-glow.slang
[INFO] [slang]: Compiling shader: "/home/ben/.config/retroarch/shaders/shaders_slang/crt/shaders/crt-easymode-halation/linearize.slang".
[ERROR] 
[ERROR] [slang]: Failed to compile vertex shader stage.
[ERROR] [Vulkan]: Failed to compile shader: "/home/ben/.config/retroarch/shaders/shaders_slang/crt/shaders/crt-easymode-halation/linearize.slang".
[ERROR] [Vulkan]: Failed to create preset: "/home/ben/.config/retroarch/config/global.slangp".

First run after launch retroarch is OK. If i close retroarch, then restart it works again (but on the second run the same error occurs again of course).
To make things simple, i have to quit Retroarch each time i change a core/game to make shaders work again.

Expected behavior

Slang shaders is applied on every core launch without having to shutdown and restart Retroarch.

Actual behavior

Shaders do not apply second time a core is run after retroarch is launched.

Steps to reproduce the bug

(Consider a slang shader preset is configured globally)

1. Start retroarch
2. Launch a content
3. Notice the shader preset is correctly applied
4. Close content (simple content restart through quick menu does not apply here, content has to be closed)
5. Launch another content (or the same, no matter)
6. Notice this time the shader preset is not applied at all

Bisect Results

Issue appeared just after upgrading to 1.10 through pacman (archlinux). Previous versions did not have this issue.

Version/Commit

• RetroArch: 1.10.0 - b71be7e

Environment information

• OS: Archlinux

Verbose logs of a RA session
retroarch.cfg.txt

EDIT:

• Only slang shaders are affected (works ok with GLSL)
• v1.9.14 is not affected by this bug

[i30817]

That sounds like it might be a driver shader cache problem. Nvidia has a shader cache on home for linux, ~/nvm or something like that (i moved mine to .cache).

I'd check if you have permissions to write on whatever dir the driver is supposed to write the shader cache to.

[TiBeN]

Looks like the directory is : ~/.cache/mesa_shader_cache:
https://unix.stackexchange.com/questions/604737/where-does-mesa-store-its-vulkan-shader-cache-on-linux

My machine has an intel graphic chip (Iris Xe)

I deleted this dir then tried again. Same behavior:
First run it okay (the dir is recreated and filled), second run fails. I tried to delete this dir in between two runs but issue remains.

I think shaders would not work at all if it was a permission issue. Permissions look correct on my machine:

drwx------ 70 ben  ben  4.0K Feb  1 11:11 .cache

EDIT

It seems only slang shaders are affected. I tried to switch gl driver with GLSL shaders. There is no issue with GLSL shaders it works at any core launch.

[TiBeN]

Just compiled myself RetroArch v1.9.14:

git clone ..
git checkout v1.9.14

It works correctly with v1.9.14 so its a regression in v1.10.0

EDIT:
v1.10.0 works well too (as master branch) when compiled manually. So maybe its an ArchLinux package issue..

[TiBeN]

Ok so i found that compiling retroarch with the following flag is triggering the bug:

./configure --disable-builtinglslang

This flag is enabled in RetroArch ArchLinux package since v1.10.0-1. This issue have been reported on archlinux bugtracker:
https://bugs.archlinux.org/task/73585

I leave this issue opened as i don't know if it is a retroarch upstream or an archlinux specific bug.

[nfp0]

I have this exact same issue on my Radeon RX 6800 on Manjaro Linux (which is Arch based).

[alucryd]

We try to avoid builtins as much as possible on Arch, so I'd rather keep using our system glslang if possible. I see no reason why our glslang would have enough permissions on the first run, but not on subsequent ones. Any ideas?

[TiBeN]

@alucryd
I really have no idea as my knowledge about slang shader etc. are pretty limited on "the dev side". Maybe some kind of "pid" file, tmp file, or any other kind of resourse which is not cleaned or released properly between the two launchs ? ..

However I can do some tests if it could help. Let me know. Is there some debug environment variables (like mesa vars) which could give more insights about the shader compilation error ? Error output is not really verbose.

[nfp0]

This only started manifesting specifically on RetroArch 1.10.0 though. Does not happen with previous versions.

[TiBeN]

@nfp0 the maintainer fixes (or at least worked-around ) this issue with the new package 1.10.0-3

[nfp0]

@TiBeN Sweet. Thanks for the heads-up!

[alucryd]

@TiBeN I have no idea how any of this works either, for now I just reinstated the builtin glslang. I would love to hear from the retroarch devs to get some insight on this issue, I'll try to dig the cache lead when I have some time.

[TiBeN]

@alucryd i understand. It seems the kind of bug which is pretty hard to diagnose. It could be a pure retroarch bug when the glslang lib is not embedded, it could be the glslang lib in retroarch repository or glslang upstream. To this point it may be interesting to inform glsang maintainers and upstream about this issue ? Anyway, thank you for your work on this package and your action with the release of 1.10.0-3