search

ValveSoftware / steam-runtime

A runtime environment for Steam applications
Other
1.18k stars 86 forks source link

vkBasalt failing to load with error: version GLIBCXX_3.4.26 not found #381

Closed tgurr closed 3 years ago

tgurr commented 3 years ago

Operating system: Exherbo Linux

Steam system information: system-information.log

Steam runtime version:

#Name   Version     Runtime Runtime_Version Comment
SteamLinuxRuntime   v0.20210309.0-0-gb38a1fb            # Entry point scripts, etc.
pressure-vessel 0.20210305.0+srt1   scout   0.20210309.0    # pressure-vessel-bin.tar.gz
soldier 0.20210309.0    soldier 0.20210309.0    # com.valvesoftware.SteamRuntime.Platform-amd64,i386-soldier-runtime.tar.gz

Tested with Life Is Strange 2 (64-bit) mentioned and vkBasalt (with effects = monochrome to easily spot if things are working or not):

Launch command: ENABLE_VKBASALT=1 VK_LOADER_DEBUG=all PROTON_LOG=1 %command%

Notable error from the logs:

ERROR: /lib/x86_64-linux-gnu/libstdc++.so.6: version `GLIBCXX_3.4.26' not found (required by /overrides/lib/x86_64-linux-gnu/vulkan_imp_layer/libvkbasalt.so)

glibc is at 2.33, both glibc and vkBasalt are compiled from source and are working fine in combination with Proton 5.0-10 or plain ENABLE_VKBASALT=1 vkcube.

smcv commented 3 years ago

Help -> System Information, please?

Sorry, never mind, I didn't see the link at the top.

tgurr commented 3 years ago

Help -> System Information, please?

It's already attached, in the second line of the report, Steam system information: system-information.log.

smcv commented 3 years ago

Looks like we are perhaps not successfully picking up your host system's libstdc++.so.6. I think this is probably the root cause for this issue: your version of vkBasalt wants the version of libstdc++ from at least gcc 9, but the soldier runtime only has the version from gcc 8. Normally, we would pick up the version of libstdc++ from the host system if it is newer, and put symbolic links in /overrides/lib/x86_64-linux-gnu and /overrides/lib/i386-linux-gnu inside the container, resulting in us using that version preferentially inside the container. However, this isn't happening on your system for some reason.

Where is the library libstdc++.so.6 kept on Exherbo systems, and what version is it? Is it a symbolic link to something else, or a regular file in its own right?

To give you an idea of what information I'm looking for, on my Debian system with libstdc++6 version 10.2.1-6 (which comes from Debian's gcc-10 source package, version 10.2.1-6), I have these symbolic links:

lrwxrwxrwx 1 root root 19 Jan 10 11:35 /usr/lib/x86_64-linux-gnu/libstdc++.so.6 -> libstdc++.so.6.0.28
lrwxrwxrwx 1 root root 19 Jan 10 11:35 /usr/lib/i386-linux-gnu/libstdc++.so.6 -> libstdc++.so.6.0.28

pointing to these regular files:

-rw-r--r-- 1 root root 1870824 Jan 10 11:35 /usr/lib/x86_64-linux-gnu/libstdc++.so.6.0.28
-rw-r--r-- 1 root root 1865768 Jan 10 11:35 /usr/lib/i386-linux-gnu/libstdc++.so.6.0.28

and it's found by the runtime linker because the directories /usr/lib/x86_64-linux-gnu and /usr/lib/i386-linux-gnu are in the default search path.

smcv commented 3 years ago

glibc is at 2.33

Confusingly, GLIBCXX_3.4.26 is nothing to do with glibc - it's part of libstdc++.so.6, the GNU Standard C++ runtime library.

tgurr commented 3 years ago

On Exherbo we also have symbolic links:

lrwxrwxrwx 1 root root 119 19. Okt 13:48 /usr/x86_64-pc-linux-gnu/lib/libstdc++.so.6 -> ../../../etc/env.d/alternatives/_x86_64-pc-linux-gnu_libstdc++.so.6/_current/usr/x86_64-pc-linux-gnu/lib/libstdc++.so.6
lrwxrwxrwx 1 root root 115 19. Okt 13:47 /usr/i686-pc-linux-gnu/lib/libstdc++.so.6 -> ../../../etc/env.d/alternatives/_i686-pc-linux-gnu_libstdc++.so.6/_current/usr/i686-pc-linux-gnu/lib/libstdc++.so.6

which are symbolic links:

lrwxrwxrwx 1 root root 71 19. Okt 13:44 /etc/env.d/alternatives/_x86_64-pc-linux-gnu_libstdc++.so.6/_current/usr/x86_64-pc-linux-gnu/lib/libstdc++.so.6 -> ../../../../../../../../usr/x86_64-pc-linux-gnu/lib/libstdc++.so.6.0.28
lrwxrwxrwx 1 root root 69 19. Okt 13:47 /etc/env.d/alternatives/_i686-pc-linux-gnu_libstdc++.so.6/_current/usr/i686-pc-linux-gnu/lib/libstdc++.so.6 -> ../../../../../../../../usr/i686-pc-linux-gnu/lib/libstdc++.so.6.0.28

which are symbolic links:

lrwxrwxrwx 1 root root 129 19. Okt 13:48 /usr/x86_64-pc-linux-gnu/lib/libstdc++.so.6.0.28 -> ../../../etc/env.d/alternatives/_x86_64-pc-linux-gnu_libstdc++.so.6.0.28/_current/usr/x86_64-pc-linux-gnu/lib/libstdc++.so.6.0.28
lrwxrwxrwx 1 root root 125 19. Okt 13:47 /usr/i686-pc-linux-gnu/lib/libstdc++.so.6.0.28 -> ../../../etc/env.d/alternatives/_i686-pc-linux-gnu_libstdc++.so.6.0.28/_current/usr/i686-pc-linux-gnu/lib/libstdc++.so.6.0.28

which are symbolic links:

lrwxrwxrwx 1 root root 74 19. Okt 13:44 /etc/env.d/alternatives/_x86_64-pc-linux-gnu_libstdc++.so.6.0.28/_current/usr/x86_64-pc-linux-gnu/lib/libstdc++.so.6.0.28 -> ../../../../../../../../usr/x86_64-pc-linux-gnu/lib/libstdc++-10.so.6.0.28
lrwxrwxrwx 1 root root 72 19. Okt 13:47 /etc/env.d/alternatives/_i686-pc-linux-gnu_libstdc++.so.6.0.28/_current/usr/i686-pc-linux-gnu/lib/libstdc++.so.6.0.28 -> ../../../../../../../../usr/i686-pc-linux-gnu/lib/libstdc++-10.so.6.0.28

pointing to these regular files:

-rwxr-xr-x 1 root root 1960496 19. Okt 13:44 /usr/x86_64-pc-linux-gnu/lib/libstdc++-10.so.6.0.28
-rwxr-xr-x 1 root root 1955568 19. Okt 13:47 /usr/i686-pc-linux-gnu/lib/libstdc++-10.so.6.0.28

Reason for the alternatives is that we can have multiple compiler versions installed for gcc/clang, be it for upgrading to not break things, testing, or some special purposes. Where the _current symlinks are always set and pointing to the one selectable with our alternatives command line tool, e.g.:

# eclectic gcc list
Available providers for gcc:
  [1]   10 *
  [2]   9
# eclectic clang list
Available providers for clang:
  [1]   11 *
  [2]   10

We make use of this alternatives approach for other stuff as well, like java, python2/3, and so on.

tgurr commented 3 years ago 
# ls -la /usr/x86_64-pc-linux-gnu/lib/ | grep libstdc++
-rw-r--r--   1 root root   5770654 19. Okt 13:44 libstdc++-10.a
-rwxr-xr-x   1 root root       966 19. Okt 13:44 libstdc++-10.la
-rwxr-xr-x   1 root root   1960496 19. Okt 13:44 libstdc++-10.so.6.0.28
lrwxrwxrwx   1 root root       111 19. Okt 13:48 libstdc++.a -> ../../../etc/env.d/alternatives/_x86_64-pc-linux-gnu_libstdc++/_current/usr/x86_64-pc-linux-gnu/lib/libstdc++.a
-rw-r--r--   1 root root    680684 19. Okt 13:44 libstdc++fs-10.a
-rwxr-xr-x   1 root root       910 19. Okt 13:44 libstdc++fs-10.la
lrwxrwxrwx   1 root root       115 19. Okt 13:48 libstdc++fs.a -> ../../../etc/env.d/alternatives/_x86_64-pc-linux-gnu_libstdc++fs/_current/usr/x86_64-pc-linux-gnu/lib/libstdc++fs.a
lrwxrwxrwx   1 root root       116 19. Okt 13:48 libstdc++fs.la -> ../../../etc/env.d/alternatives/_x86_64-pc-linux-gnu_libstdc++fs/_current/usr/x86_64-pc-linux-gnu/lib/libstdc++fs.la
lrwxrwxrwx   1 root root       112 19. Okt 13:48 libstdc++.la -> ../../../etc/env.d/alternatives/_x86_64-pc-linux-gnu_libstdc++/_current/usr/x86_64-pc-linux-gnu/lib/libstdc++.la
lrwxrwxrwx   1 root root       115 19. Okt 13:48 libstdc++.so -> ../../../etc/env.d/alternatives/_x86_64-pc-linux-gnu_libstdc++.so/_current/usr/x86_64-pc-linux-gnu/lib/libstdc++.so
lrwxrwxrwx   1 root root       119 19. Okt 13:48 libstdc++.so.6 -> ../../../etc/env.d/alternatives/_x86_64-pc-linux-gnu_libstdc++.so.6/_current/usr/x86_64-pc-linux-gnu/lib/libstdc++.so.6
lrwxrwxrwx   1 root root       129 19. Okt 13:48 libstdc++.so.6.0.28 -> ../../../etc/env.d/alternatives/_x86_64-pc-linux-gnu_libstdc++.so.6.0.28/_current/usr/x86_64-pc-linux-gnu/lib/libstdc++.so.6.0.28
# ls -la /usr/i686-pc-linux-gnu/lib/ | grep libstdc++
-rw-r--r--  1 root root  4763272 19. Okt 13:47 libstdc++-10.a
-rwxr-xr-x  1 root root      964 19. Okt 13:47 libstdc++-10.la
-rwxr-xr-x  1 root root  1955568 19. Okt 13:47 libstdc++-10.so.6.0.28
lrwxrwxrwx  1 root root      107 19. Okt 13:47 libstdc++.a -> ../../../etc/env.d/alternatives/_i686-pc-linux-gnu_libstdc++/_current/usr/i686-pc-linux-gnu/lib/libstdc++.a
-rw-r--r--  1 root root   565632 19. Okt 13:47 libstdc++fs-10.a
-rwxr-xr-x  1 root root      908 19. Okt 13:47 libstdc++fs-10.la
lrwxrwxrwx  1 root root      111 19. Okt 13:47 libstdc++fs.a -> ../../../etc/env.d/alternatives/_i686-pc-linux-gnu_libstdc++fs/_current/usr/i686-pc-linux-gnu/lib/libstdc++fs.a
lrwxrwxrwx  1 root root      112 19. Okt 13:47 libstdc++fs.la -> ../../../etc/env.d/alternatives/_i686-pc-linux-gnu_libstdc++fs/_current/usr/i686-pc-linux-gnu/lib/libstdc++fs.la
lrwxrwxrwx  1 root root      108 19. Okt 13:47 libstdc++.la -> ../../../etc/env.d/alternatives/_i686-pc-linux-gnu_libstdc++/_current/usr/i686-pc-linux-gnu/lib/libstdc++.la
lrwxrwxrwx  1 root root      111 19. Okt 13:47 libstdc++.so -> ../../../etc/env.d/alternatives/_i686-pc-linux-gnu_libstdc++.so/_current/usr/i686-pc-linux-gnu/lib/libstdc++.so
lrwxrwxrwx  1 root root      115 19. Okt 13:47 libstdc++.so.6 -> ../../../etc/env.d/alternatives/_i686-pc-linux-gnu_libstdc++.so.6/_current/usr/i686-pc-linux-gnu/lib/libstdc++.so.6
lrwxrwxrwx  1 root root      125 19. Okt 13:47 libstdc++.so.6.0.28 -> ../../../etc/env.d/alternatives/_i686-pc-linux-gnu_libstdc++.so.6.0.28/_current/usr/i686-pc-linux-gnu/lib/libstdc++.so.6.0.28

and it's found by the runtime linker because the directories /usr/lib/x86_64-linux-gnu and /usr/lib/i386-linux-gnu are in the default search path.

Maybe for Exherbo it would work to instead/additionally just have the directories /usr/x86_64-pc-linux-gnu/lib and /usr/i686-pc-linux-gnu/lib in the default search path(?).

smcv commented 3 years ago

What does your dynamic linker cache say about libstdc++.so.6? This is where pressure-vessel gets its information about your host system libraries.

On Debian it looks like this, for example:

$ ldconfig -Xpv | grep libstdc
    libstdc++.so.6 (libc6,x86-64) => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
    libstdc++.so.6 (libc6) => /usr/lib/i386-linux-gnu/libstdc++.so.6

and then pressure-vessel does the equivalent of realpath /usr/lib/x86_64-linux-gnu/libstdc++.so.6 and realpath /usr/lib/i386-linux-gnu/libstdc++.so.6 to get more information.

Maybe for Exherbo it would work to instead/additionally just have the directories /usr/x86_64-pc-linux-gnu/lib and /usr/i686-pc-linux-gnu/lib in the default search path(?).

The default search path outside the container, which your ldconfig uses to compile your ld.so.cache, should already have those directories in it, if I understand Exherbo's variation on the FHS layout correctly?

smcv commented 3 years ago

The problem here might be that the regular filename, after doing the equivalent of realpath, ends up at .../libstdc++-10.so.6.0.28, which we cannot meaningfully compare with the libstdc++.so.6.0.25 in the soldier runtime because the prefix is different.

To resolve this, we might need to tell the runtime that it needs to compare these libraries by their symbol-versions instead.

tgurr commented 3 years ago

What does your dynamic linker cache say about libstdc++.so.6

Here's the output:

$ ldconfig -Xpv | grep libstdc
        libstdc++.so.6 (libc6,x86-64) => /usr/x86_64-pc-linux-gnu/lib/libstdc++.so.6
        libstdc++.so (libc6,x86-64) => /usr/x86_64-pc-linux-gnu/lib/libstdc++.so
$ realpath /usr/x86_64-pc-linux-gnu/lib/libstdc++.so.6
/usr/x86_64-pc-linux-gnu/lib/libstdc++-10.so.6.0.28
$ realpath /usr/i686-pc-linux-gnu/lib/libstdc++.so.6
/usr/i686-pc-linux-gnu/lib/libstdc++-10.so.6.0.28

The default search path outside the container, which your ldconfig uses to compile your ld.so.cache, should already have those directories in it, if I understand Exherbo's variation on the FHS layout correctly?

I'm pretty sure this is the case, else things would break all over the place I guess. After the awesome work you already did to make the steam-runtime and recent Proton versions work on Exherbo things are working nicely (except for such comfort features like e.g. vkBasalt).

smcv commented 3 years ago

Not directly related to the real issue here, just something I noticed in your log:

13:26:26.224616: pressure-vessel-wrap[259767]: I: We were expecting the libdrm directory in the provider to be located in "/usr/x86_64-pc-linux-gnu/share/libdrm", but instead it is missing
13:26:26.224665: pressure-vessel-wrap[259767]: I: We were expecting the drirc.d directory in the provider to be located in "/usr/x86_64-pc-linux-gnu/share/drirc.d", but instead it is missing

I would expect that you should have files named share/libdrm/amdgpu.ids and share/drirc.d/00-mesa-defaults.conf somewhere. Where does Exherbo keep those files? We try to guess from where we found your libdrm.so.2 and libGLX_mesa.so.0, but apparently our guess is wrong here.

smcv commented 3 years ago

Try this workaround:

You should find that you have a directory something like /mnt/games/Steam/steamapps/common/SteamLinuxRuntime_soldier/var/deploy-0.20210309.0.

Inside that directory, there should be a file files/lib/steamrt/libcapsule-knowledge.keyfile. Open that with a text editor, and add this to the end:

[Library libstdc++.so.6]
CompareBy=versions;

We need to look into whether this is something we can do safely for everyone - but if we can, then I think we can solve this problem for you that way.

smcv commented 3 years ago

This is another bug, probably unrelated:

13:26:26.433627: pressure-vessel-adverb[259974]: E: Cannot parse double value '2,000000' for --terminate-timeout
tgurr commented 3 years ago

Try this workaround:

You should find that you have a directory something like /mnt/games/Steam/steamapps/common/SteamLinuxRuntime_soldier/var/deploy-0.20210309.0.

Inside that directory, there should be a file files/lib/steamrt/libcapsule-knowledge.keyfile. Open that with a text editor, and add this to the end:

[Library libstdc++.so.6]
CompareBy=versions;

We need to look into whether this is something we can do safely for everyone - but if we can, then I think we can solve this problem for you that way.

I'm afraid that causes a problem, Life is Strange 2 starts and I can hear the background music playing but I never get something visible and the steam-532210.log keeps growing and growing to multiple GB repeating the same error, please see steam-532210.log until I either manually kill the process or use steam to stop the game.

Note: If I uninstall vkBasalt but keep the mentioned workaround in place Life is Strange 2 starts fine though. However with Proton 5.0-10 and vkBasalt installed, or plain vkcube things work so my feeling is it's not something related to vkBasalt on my system itself but rather causes by the workaround, hopefully the attached log is of some use to you.

tgurr commented 3 years ago

This is another bug, probably unrelated:

13:26:26.433627: pressure-vessel-adverb[259974]: E: Cannot parse double value '2,000000' for --terminate-timeout

I don't want to hijack the thread for that problem, but maybe because of the German locale (and probably others) having , as decimal mark instead of .?

smcv commented 3 years ago

failed to load shader file: /usr/share/vkBasalt/reshade-shaders/Shaders/Monochrome.fx

OK, so vkBasalt doesn't actually work inside your container unless we import the shaders that it's using, which I'd really prefer not to do - making random Vulkan layers "mostly work" is one thing, but putting in specific code to support specific third-party Vulkan layers is a step further than I'm comfortable with, because trying to support everyone's favourite third-party layer doesn't scale.

Please could I see a slr-*.log with the workaround in place? I think we're probably behaving "more correctly" with that change in place, and not having it is potentially going to break Exherbo users' Mesa graphics drivers in a few weeks' or months' time, so I'd still be tempted to make it "official" - but if that makes vkBasalt crash your process and leave gigabytes of logs, then that obviously isn't great.

Have you specifically configured vkBasalt to load shaders from /usr/share or is it pre-set to do that itself?

If you configure vkBasalt to use somewhere in your home directory instead of /usr/share/vkBasalt/reshade-shaders, for example /home/you/reshade-shaders, and copy the shaders it wants into that location, does that work without crashing?

c0000005 is the Windows equivalent of a segfault, so it's hard to say which component is crashing. I would guess maybe a NULL pointer dereference.

smcv commented 3 years ago

I don't want to hijack the thread for that problem, but maybe because of the German locale (and probably others) having , as decimal mark instead of .?

Right. According to GLib's documentation, when run in a locale with a decimal comma, we should be able to parse double command-line arguments with either a decimal comma or a decimal point - but apparently that's not working here. Maybe it's because this is happening before locales are fully set up in the container?

This is another thing that, while it isn't breaking anything for you right now, could cause problems for you in the future, so we should fix it.

Where does Exherbo keep system locales, in particular a file named locale-archive? On Debian (and probably many other FHS systems) it's in the /usr/lib/locale/ directory.

tgurr commented 3 years ago

failed to load shader file: /usr/share/vkBasalt/reshade-shaders/Shaders/Monochrome.fx

OK, so vkBasalt doesn't actually work inside your container unless we import the shaders that it's using, which I'd really prefer not to do - making random Vulkan layers "mostly work" is one thing, but putting in specific code to support specific third-party Vulkan layers is a step further than I'm comfortable with, because trying to support everyone's favourite third-party layer doesn't scale.

Please could I see a slr-*.log with the workaround in place? I think we're probably behaving "more correctly" with that change in place, and not having it is potentially going to break Exherbo users' Mesa graphics drivers in a few weeks' or months' time, so I'd still be tempted to make it "official" - but if that makes vkBasalt crash your process and leave gigabytes of logs, then that obviously isn't great.

Here's the requested file: slr-app532210-s745e222cbcfed3ba.log

Have you specifically configured vkBasalt to load shaders from /usr/share or is it pre-set to do that itself?

That probably depends on how vkBasalt is packaged, e.g. Arch Linux is also presetting the paths to the shaders installed with vkbasalt and/or additonally install or depend on reshade-shaders: https://aur.archlinux.org/cgit/aur.git/plain/PKGBUILD?h=vkbasalt But they're installing vkBasalt.conf as /usr/share/vkBasalt/vkBasalt.conf.example so it probably isn't picked up automatically. On Exherbo I currently have that installed as /etc/vkBasalt/vkBasalt.conf to work out of the box (https://git.exherbo.org/desktop.git/tree/packages/sys-libs/vkbasalt/vkbasalt-0.3.2.4.exheres-0). But here comes to good news, while working out of the box like this for native applications and Proton 5.0-10 it doesn't work for stream-runtime Proton versions until you put a vkBasalt.conf into your home directory. So without any manual user interactions nothing in regard to Proton causes any breakage.

If you configure vkBasalt to use somewhere in your home directory instead of /usr/share/vkBasalt/reshade-shaders, for example /home/you/reshade-shaders, and copy the shaders it wants into that location, does that work without crashing?

c0000005 is the Windows equivalent of a segfault, so it's hard to say which component is crashing. I would guess maybe a NULL pointer dereference.

And indeed it does work like that! So you not only have to create the vkBasalt configuration in the home directory, but also copy/move/install the shaders there.

tgurr commented 3 years ago

Where does Exherbo keep system locales, in particular a file named locale-archive? On Debian (and probably many other FHS systems) it's in the /usr/lib/locale/ directory.

We have that file(s) under our prefixes, e.g.:

$ file /usr/x86_64-pc-linux-gnu/lib/locale/locale-archive 
/usr/x86_64-pc-linux-gnu/lib/locale/locale-archive: locale archive 49 strings
$ file /usr/i686-pc-linux-gnu/lib/locale/locale-archive 
/usr/i686-pc-linux-gnu/lib/locale/locale-archive: locale archive 33 strings
smcv commented 3 years ago

Note: If I uninstall vkBasalt but keep the mentioned workaround in place Life is Strange 2 starts fine though. However with Proton 5.0-10 and vkBasalt installed, or plain vkcube things work so my feeling is it's not something related to vkBasalt on my system itself but rather causes by the workaround, hopefully the attached log is of some use to you.

I think the problem is that the libcapsule-knowledge.keyfile change makes vkBasalt load successfully (!), but then it crashes. This is because you've configured it to use shaders from /usr, but the container's /usr is not the same as your host system's /usr (that's the whole point of the container), and vkBasalt crashes its host process with a segmentation fault if it cannot load a shader.

So, in a way, the current official version of soldier is accidentally working around this crash by breaking the ability to load vkBasalt.

To reproduce this segfault using plain bwrap, without pressure-vessel, you can mount an empty directory over the top of your configured directory for reshade shaders:

$ cat ~/.config/vkBasalt/vkBasalt.conf
effects = monochrome
monochrome = /home/smcv/src/reshade-shaders/Shaders/Monochrome.fx
reshadeTexturePath = /home/smcv/src/reshade-shaders/Textures
reshadeIncludePath = /home/smcv/src/reshade-shaders/Shaders
$ ENABLE_VKBASALT=1 vkcube; echo $?
vkBasalt info:  config file: /home/smcv/.config/vkBasalt/vkBasalt.conf
vkBasalt info:  effects = monochrome
vkBasalt info:  monochrome = /home/smcv/src/reshade-shaders/Shaders/Monochrome.fx
vkBasalt info:  reshadeTexturePath = /home/smcv/src/reshade-shaders/Textures
vkBasalt info:  reshadeIncludePath = /home/smcv/src/reshade-shaders/Shaders
MESA-INTEL: warning: Performance support disabled, consider sysctl dev.i915.perf_stream_paranoid=0

(it works, and displays in greyscale)
(I close the window)
0
$ bwrap --ro-bind / / --dev-bind /dev /dev --ro-bind ~/tmp/empty ~/src/reshade-shaders env ENABLE_VKBASALT=1 vkcube; echo $?
vkBasalt info:  config file: /home/smcv/.config/vkBasalt/vkBasalt.conf
vkBasalt info:  effects = monochrome
vkBasalt info:  monochrome = /home/smcv/src/reshade-shaders/Shaders/Monochrome.fx
vkBasalt info:  reshadeTexturePath = /home/smcv/src/reshade-shaders/Textures
vkBasalt info:  reshadeIncludePath = /home/smcv/src/reshade-shaders/Shaders
MESA-INTEL: warning: Performance support disabled, consider sysctl dev.i915.perf_stream_paranoid=0

vkBasalt err:   failed to load shader file: /home/smcv/src/reshade-shaders/Shaders/Monochrome.fx
vkBasalt err:   Does the filepath exist and does it not include spaces?
139
smcv commented 3 years ago

I've reported the vkBasalt bug at https://github.com/DadSchoorse/vkBasalt/issues/146.

tgurr commented 3 years ago

Thanks for reporting the vkBasalt problem upstream and providing a way to easily reproduce the problem outside of Exherbo. Please note my comment above, while it can indeed turn out to be a problem when one just configures vkBasalt.conf in his/her home directory without also copying the shaders into the home directory as well, by default the system installed packaged version of Exherbo won't cause any problem per se as the vkBasalt.conf resides in /etc/vkBasalt/vkBasalt.conf and thus doesn't seem to be picked up by the container runtime. So you hopefully won't get any bug reports because of our packaged version. But of course it would be nice if vkBasalt would handle this gracefully.

I'll leave the workaround applied to libcapsule-knowledge.keyfile in place, but so far I'd say things are looking good that it doesn't cause any other breakage, at least on Exherbo.

Looking forward to see this fixed in a new steam-runtime release in the future when you can be sure it doesn't cause any breakage for others, as well as the mentioned problem in regards to loading the locale-archive on Exherbo. Please let me know if I can assist any further and like usually many huge thanks from my side!

smcv commented 3 years ago

While I'm opening a bunch of smaller issues and merge requests in pressure-vessel, please could you answer what I asked in https://github.com/ValveSoftware/steam-runtime/issues/381#issuecomment-800293478 and we can get that fixed as well?

smcv commented 3 years ago

Summarizing bugs we've found here so far:

DadSchoorse commented 3 years ago 
* If vkBasalt didn't crash, it also wouldn't _work_ in your configuration, because it wouldn't see the shaders in `/usr/share`. I don't think this is fixable without giving pressure-vessel some special-case code to specifically handle vkBasalt, which seems like a bad precedent to set for a nice-to-have: we don't have the bandwidth to special-case every third-party addon, so it seems like the fairest thing to do is to not special-case any of them (and if they happen to work anyway then that's great).

Instead of specifically handling vkBasalt, is there a general mechanism to import a host directory (/usr/share/vkBasalt in this case) into pressure-vessel? Like an env var or something?

smcv commented 3 years ago

Instead of specifically handling vkBasalt, is there a general mechanism to import a host directory (/usr/share/vkBasalt in this case) into pressure-vessel? Like an env var or something?

Not really, the design (borrowed from Flatpak) is that in general, /usr is meant to be entirely under the control of the runtime. The user can pull in nearly everything else from the host if they want to (in particular /home, /media, /opt and /srv are fine), but /usr is special (so are /bin, /sbin, /lib* if separate, and with somewhat different rules, so are /app, /etc, /run and /var).

A technical reason why /usr is special is that the runtime is mounted onto /usr read-only, so for every directory we want to import from the host system, we need a pre-existing mount point to mount it onto. In the absence of a special case for vkBasalt, we can't know that /usr/share/vkBasalt is something that needs to exist as a mount point. As far as I can see, if Exherbo had made different choices in their packaging, they could easily have been relying on /usr/share/reshade-shaders rather than the /usr/share/vkBasalt/reshade-shaders that they actually use.

A policy reason why /usr is special is that if we let the host system arbitrarily overwrite parts of /usr, we can't prevent it from overwriting the parts of /usr that are relied on by the executables that are designed to run in the runtime environment (currently Proton, and probably in future native Linux games), which defeats the purpose of the container runtime environment (providing a predictable library stack for games so that if they pass QA testing on one OS, they probably work acceptably on all the others).

Originally, pressure-vessel didn't do anything with Vulkan layers at all, but while some Vulkan layers are merely nice-to-have (like vkBasalt and MangoHUD), others are functionally necessary (like Mesa's device selection layer and NVIDIA's PRIME offload layer), so we have to deal with them, even though injecting arbitrary code into the game process somewhat contradicts the purpose of the container runtime.

smcv commented 3 years ago

If vkBasalt has a way to remap paths or otherwise override them, /usr/share/vkBasalt is available inside the container - but it's mounted at /run/host/usr/share/vkBasalt. This is the same behaviour as flatpak run --filesystem=host-os.

DadSchoorse commented 3 years ago

Is it possible to detect if the steam runtime is in use? I could remap all file loads to /run/host/ in that case.

smcv commented 3 years ago

Is it possible to detect if the steam runtime is in use? I could remap all file loads to /run/host/ in that case.

Only /usr and friends (/bin, etc.) get remapped to /run/host, most of the rest of the filesystem stays where it is.

smcv commented 3 years ago

It is technically possible to detect that the container runtime is in use, but there isn't really a "public API" for it at the moment. I think we need to think about whether that's really desirable - again, the purpose of the container runtime is to put the game in as much as possible the same library stack that it was QA-tested against, so individual modules second-guessing that is not necessarily something we want.

Flatpak deals with this by not getting Vulkan layers, or graphics drivers in general, from the host system at all - which is certainly an easier behaviour to explain, even if it doesn't necessarily meet user expectations. Flatpak users only get vkBasalt if they have specifically installed it as a Flatpak extension, usually meaning com.valvesoftware.Steam.Utility.vkBasalt.

However, pressure-vessel has taken the approach of getting the graphics drivers from the host and everything else from the runtime, and setting up a hybrid environment for the games. This is a somewhat different trade-off: the graphics drivers are less predictable, but they're also a version that we can be reasonably confident is compatible with the user's GPU.

tgurr commented 3 years ago

Not directly related to the real issue here, just something I noticed in your log:

13:26:26.224616: pressure-vessel-wrap[259767]: I: We were expecting the libdrm directory in the provider to be located in "/usr/x86_64-pc-linux-gnu/share/libdrm", but instead it is missing
13:26:26.224665: pressure-vessel-wrap[259767]: I: We were expecting the drirc.d directory in the provider to be located in "/usr/x86_64-pc-linux-gnu/share/drirc.d", but instead it is missing

I would expect that you should have files named share/libdrm/amdgpu.ids and share/drirc.d/00-mesa-defaults.conf somewhere. Where does Exherbo keep those files? We try to guess from where we found your libdrm.so.2 and libGLX_mesa.so.0, but apparently our guess is wrong here.

Please excuse me not answering your questions and thanks for pointing at them again, I overread that ones previously. On Exherbo these files reside at:

/usr/share/libdrm/amdgpu.ids
/usr/share/drirc.d/00-mesa-defaults.conf

Generally speaking, everything that is usr/share or etc and thus arch-independent is in plain /usr/share and /etc on Exherbo, and just arch-dependent stuff is installed in the corresponding prefixes, e.g. /usr/{i686-pc-linux-gnu,x86_64-pc-linux-gnu}/{bin,include,lib,libexec}.

smcv commented 3 years ago

OK, we need to adjust our algorithm for guessing a library's ${prefix} to take into account Exherbo's architecture-specific prefixes.

smcv commented 3 years ago

Thanks, I've edited the summary of bugs found here.

We still need to think about what (if anything) is the right answer for making vkBasalt behave as expected, but while we're thinking about that, we can fix the other stuff.

smcv commented 3 years ago
  • The original bug report: pressure-vessel did not capture your libstdc++.so.6 into /overrides. It should have done
  • The timeout isn't correctly communicated to a subprocess in e.g. German locales
  • If we are using Exherbo's glibc, we don't bring in Exherbo's /usr/*-pc-linux-gnu/lib/locale into the container
  • If we are using Exherbo's libdrm, we don't bring in Exherbo's /usr/share/libdrm/amdgpu.ids or /usr/share/drirc.d/00-mesa-defaults.conf

These should be fixed in the next beta, versioned >= 0.20210317.0; check SteamLinuxRuntime_soldier/VERSIONS.txt if you are not sure whether you have this version. The changes are partly in the pressure-vessel component and partly in the soldier runtime, but the relevant version number happens to be 0.20210317.0 in both cases.

The scout runtime optionally used for native Linux games has received the same fixes, also in version 0.20210317.0.

[Edited to add: These were released as betas on 2021-03-19]

  • With that fixed, vkBasalt crashes in your configuration
  • If vkBasalt didn't crash, it also wouldn't work in your configuration, because it wouldn't see the shaders in /usr/share

These have not changed. /usr continues to be controlled by the runtime; it is technically possible to override parts of it, but difficult to do that in a safe or predictable way (particularly if it's user-controlled), so at the moment we only do this for things that are part of the supported graphics stack (GLX drivers, Vulkan drivers, VA-API drivers, that sort of thing) and their mandatory dependencies. Sorry, vkBasalt does not get similar special-case behaviour at the moment.

tgurr commented 3 years ago
  • The original bug report: pressure-vessel did not capture your libstdc++.so.6 into /overrides. It should have done
  • The timeout isn't correctly communicated to a subprocess in e.g. German locales
  • If we are using Exherbo's glibc, we don't bring in Exherbo's /usr/*-pc-linux-gnu/lib/locale into the container
  • If we are using Exherbo's libdrm, we don't bring in Exherbo's /usr/share/libdrm/amdgpu.ids or /usr/share/drirc.d/00-mesa-defaults.conf

These should be fixed in the next beta, versioned >= 0.20210317.0; check SteamLinuxRuntime_soldier/VERSIONS.txt if you are not sure whether you have this version. The changes are partly in the pressure-vessel component and partly in the soldier runtime, but the relevant version number happens to be 0.20210317.0 in both cases.

The scout runtime optionally used for native Linux games has received the same fixes, also in version 0.20210317.0.

[Edited to add: These were released as betas on 2021-03-19]

Again thank you very much, not only for adressing the initial problem, but also identifying and fixing additional stuff along the road to make steam-runtime behave properly/better on Exherbo Linux. I can't thank you enough for your continued effort. I can confirm that with the latest steam-runtime beta vkBasalt (if configured properly with the config and shaders/textures in the home directory) works out of the box now for me.

  • With that fixed, vkBasalt crashes in your configuration
  • If vkBasalt didn't crash, it also wouldn't work in your configuration, because it wouldn't see the shaders in /usr/share

These have not changed. /usr continues to be controlled by the runtime; it is technically possible to override parts of it, but difficult to do that in a safe or predictable way (particularly if it's user-controlled), so at the moment we only do this for things that are part of the supported graphics stack (GLX drivers, Vulkan drivers, VA-API drivers, that sort of thing) and their mandatory dependencies. Sorry, vkBasalt does not get similar special-case behaviour at the moment.

For me that's fine, our system-installed version doesn't cause any issues per se so things only clash if the user manually and improperly configures vkBasalt (like I did when not also copying over the shaders/textures). Of course it would be nice if vkBasalt would fail gracefully, like you suggested in the bug report you've created for vkBasalt in their upstream GitHub bugtracker linked above.

Not sure how you'd like to handle this bug report, but to my understanding the initial problem has been fixed with your latest work so this bug could/should be closed(?).

smcv commented 3 years ago

Not sure how you'd like to handle this bug report, but to my understanding the initial problem has been fixed with your latest work so this bug could/should be closed(?).

Yes, I think so. If you want to open a separate issue for vkBasalt being unable to see the shaders in /usr/share, that would make sense, but it is not going to be solved immediately (I'll continue to think about what a solution should look like).

kisak-valve commented 3 years ago

Closing per the last couple comments.