Flatpak: pressure-vessel: Vulkan Layers broken since ~2024-03-25 - Githubissues

ValveSoftware / steam-runtime

A runtime environment for Steam applications

Other

1.18k stars 86 forks source link

Flatpak: pressure-vessel: Vulkan Layers broken since ~2024-03-25 #662

Closed jntesteves closed 5 months ago

jntesteves commented 6 months ago

Your system information

Steam Runtime Version: sniper 0.20240307.80401 and 0.20240321.82082 tested
Distribution: Flatpak
Link to your full system information (Help -> Steam Runtime Diagnostics) in a Gist: steam-runtime-system-info-1711663142.txt
Have you checked for system updates?: Yes
What compatibility tool are you using?: Steam Linux Runtime and Proton
What versions are listed in steamapps/common/SteamLinuxRuntime/VERSIONS.txt? N/A

What versions are listed in steamapps/common/SteamLinuxRuntime_soldier/VERSIONS.txt?

#Name   Version     Runtime Runtime_Version Comment
depot   0.20240306.80253            # Overall version number
pressure-vessel 0.20240306.0    scout       # pressure-vessel-bin.tar.gz
scripts 0.20240306.0            # from steam-runtime-tools
soldier 0.20240306.80253    soldier 0.20240306.80253    # soldier_platform_0.20240306.80253/

What versions are listed in steamapps/common/SteamLinuxRuntime_sniper/VERSIONS.txt?

#Name   Version     Runtime Runtime_Version Comment
depot   0.20240307.80401            # Overall version number
pressure-vessel 0.20240306.0    scout       # pressure-vessel-bin.tar.gz
scripts 0.20240306.0            # from steam-runtime-tools
sniper  0.20240307.80401    sniper  0.20240307.80401    # sniper_platform_0.20240307.80401/

Please describe your issue in as much detail as possible:

Vulkan Layers like MangoHud and VkBasalt stopped working on Steam Flatpak in 2024-03-25, I suspect after an update to steam-runtime. The problem happens when running within pressure-vessel.

In my investigation of the issue, I found that the overrides data dir mounted within the pressure-vessel container (/usr/lib/pressure-vessel/overrides/share) is on a path not included in the search paths of Vulkan-Loader. I think what's missing is pressure-vessel adding that path to one of these search paths, e.g. XDG_DATA_DIRS="${XDG_DATA_DIRS}":/usr/lib/pressure-vessel/overrides/share

As a workaround in the Flatpak package I've sent the PR flathub/com.valvesoftware.Steam#1281 that adds the path to XDG_DATA_DIRS, since pressure-vessel inherits this variable from the outer environment.

related to flathub/com.valvesoftware.Steam#1280 flathub/org.freedesktop.Platform.VulkanLayer.MangoHud#47

Steps for reproducing this issue:

Install Flatpak Steam and MangoHud: flatpak install flathub com.valvesoftware.Steam org.freedesktop.Platform.VulkanLayer.MangoHud
Launch Flatpak Steam: flatpak run com.valvesoftware.Steam
On any Vulkan or D3D game, add the launch option: MANGOHUD=1 %command%
Launch the game. The MangoHud overlay should appear over the game's graphics, but it doesn't.

smcv commented 5 months ago

In my investigation of the issue, I found that the overrides data dir mounted within the pressure-vessel container (/usr/lib/pressure-vessel/overrides/share) is on a path not included in the search paths of Vulkan-Loader. I think what's missing is pressure-vessel adding that path to one of these search paths, e.g. XDG_DATA_DIRS="${XDG_DATA_DIRS}":/usr/lib/pressure-vessel/overrides/share

It's meant to do that already - actually, it prepends rather than appending.

Please could you capture a log, by running an affected game with its launch options set to STEAM_LINUX_RUNTIME_VERBOSE=1 STEAM_LINUX_RUNTIME_LOG=1 %command%? For Proton 7 or 8 games, logs will appear in steamapps/common/SteamLinuxRuntime_sniper/var/ with a symbolic link slr-latest.log pointing to the newest log file.

smcv commented 5 months ago

You might need to add XDG_DATA_DIRS=/app/share:/usr/lib/extensions/vulkan/share:/usr/share:/usr/share/runtime/share:/run/host/user-share:/run/host/share to the launch options to undo the workaround before this is reproducible again.

smcv commented 5 months ago

I can reproduce this, or something close to it - but I'd still like to see a log, because otherwise I can't be sure that I'm seeing the same root cause that you are.

smcv commented 5 months ago

I think I've identified the root cause for this, which would be consistent with code introduced in early March. A fix is in progress.

jntesteves commented 5 months ago

Launched L4D with the verbose log: https://gist.github.com/jntesteves/ae953360995013cd7ad707d41355dc7e

Log shows in the Final command to execute: the overrides paths are being set for shared objects, LD, ICD, etc, but not in --env=XDG_DATA_DIRS= or any other XDG_ variable.

smcv commented 5 months ago

If this is what I think it is, then the regression is fixed in pressure-vessel 0.20240321.1 or later, which is expected to be in the next beta update for each of SLR 2.0 (soldier) and SLR 3.0 (sniper).

You can test that version early by replacing steamapps/common/SteamLinuxRuntime_sniper/pressure-vessel/ (and also steamapps/common/SteamLinuxRuntime_soldier/pressure-vessel/ if you have it) with the result of downloading and unpacking https://repo.steampowered.com/pressure-vessel/snapshots/0.20240321.1/pressure-vessel-bin.tar.gz.

smcv commented 5 months ago

As of today, this should be fixed in the client_beta branches of "Steam Linux Runtime 2.0 - soldier" and "Steam Linux Runtime 3.0 - sniper". If you have the fixed version, VERSIONS.txt should say pressure-vessel 0.20240415.0 or later.

smcv commented 5 months ago

Starting from yesterday, this should also be fixed in the default (stable) branches of "Steam Linux Runtime 2.0 - soldier" and "Steam Linux Runtime 3.0 - sniper".

jntesteves commented 5 months ago

Hi, I did a quick test last night of sniper on L4D and, as you said, the overridden data path is added at the beginning of the XDG_DATA_DIRS variable as expected. MangoHud showed up too. I don't know how one would test soldier, though. Is that game specific?

smcv commented 5 months ago

There's no need to test soldier specifically, the change that fixed this was in a component for which sniper and soldier share identical binaries (pressure-vessel).

sniper is used for Windows games like L4D running under Proton 8, 9 or experimental, and for a short but increasing list of actively-maintained native Linux games (Battle for Wesnoth, CS2, Dota 2, Endless Sky, Retroarch, TF2, possibly others).

soldier is used for Windows games running under Proton 5.13, 6.x or 7, and as part of running older native Linux games if you configure them to run under the "Steam Linux Runtime 1.0 (scout)" compatibility tool (which is not the default for any game that I'm aware of on desktop, although it is the default for many games on Steam Deck).

smcv commented 5 months ago

@kisak-valve or @jntesteves, please could you close this issue based on https://github.com/ValveSoftware/steam-runtime/issues/662#issuecomment-2077487039?

smcv commented 5 months ago

Among Valve's titles, I believe Aperture Desk Job (free), the Half-Life series (except for Alyx), the Portal series, and other older games like Counter-Strike 1 (free?) and Team Fortress Classic (free?) are still older native Linux games that run in the scout environment (and can therefore run under SLR 1.0, which uses soldier).

When I need a quick test of the scout environment, I normally use Floating Point (which is free, very small and can run on very old/bad hardware), Life is Strange (chapter 1 is free) or Tomb Raider (the first of the post-2013 trilogy).