search

flightlessmango / MangoHud

A Vulkan and OpenGL overlay for monitoring FPS, temperatures, CPU/GPU load and more. Discord: https://discordapp.com/invite/Gj5YmBb
MIT License
6.52k stars 287 forks source link

Proton 5.13 forces Steam Linux Runtime -> No MangoHud #369

Closed psofiterol closed 2 years ago

psofiterol commented 4 years ago
DadSchoorse commented 4 years ago

All globally installed vulkan layers are broken like this. This is a known issue on the steam side and will hopefully be fixed soon.

Sporif commented 4 years ago

Alternatively you can bypass the runtime container by editing the start script at

<steam-library>/steamapps/common/SteamLinuxRuntime_soldier/_v2-entry-point

Adding the following lines after #!/bin/bash:

shift 4
exec "${@}"

Obviously if SteamLinuxRuntime_soldier gets updated then this will need to be done again.

DistantThunder commented 4 years ago

Hi all, thanks for your work!

I've tried to use this "hack" but as it appears, RDR2 won't run when I'm using it, specifically the shift 4 part.

The generated command line looks like this:

/home/_USER_/.local/share/Steam/steamapps/common/Proton 5.13/proton waitforexitandrun /_GAMESPATH_/Steam/steamapps/common/Red Dead Redemption 2/PlayRDR2.exe -vulkan

But the game won't run then.

Any ideas?

Sporif commented 4 years ago

@DistantThunder Your system might not have the required library or libraries in the soldier runtime to run that game or Proton 5.13 in general. What distro are you using?

DistantThunder commented 4 years ago

@Sporif I'm using Arch Linux 5.9.x.

The game runs fine (apart from Online ofc) when not using the bash hack, but then of course I don't have the HUD.

When I try to use the hack, the game just stops being able to start.

smcv commented 3 years ago

All globally installed vulkan layers are broken like this

Versions >= 0.20201124.0 of the pressure-vessel container runner will import Vulkan layers from the host system, in addition to Vulkan ICDs. This is not currently included in the SteamLinuxRuntime_soldier Steam depot, but should be in the next public release.

The container does not have the same /etc or /usr as the host system, so not all system-wide configuration files will be available. For best results, use a configuration file in your home directory. Alternatively, there is a new environment variable PRESSURE_VESSEL_FILESYSTEMS_RO which can be used to pull in configuration files from other directories (although not /usr for technical reasons): for example you could use PRESSURE_VESSEL_FILESYSTEMS_RO="$MANGOHUD_CONFIGFILE:$VKBASALT_CONFIG_FILE".

Alternatively you can bypass the runtime container

Please don't do this. Proton 5.13 binary builds are intended to run in the Steam Runtime 2 'soldier' container, and are not necessarily compatible with your operating system when not using a container. Valve cannot provide support for running Proton outside its intended environment.

TaiTair commented 3 years ago

Please don't do this. Proton 5.13 binary builds are intended to run in the Steam Runtime 2 'soldier' container, and are not necessarily compatible with your operating system when not using a container. Valve cannot provide support for running Proton outside its intended environment.

You can't blame people for finding a way to make it work. The cause of the issue is the runtime, not the people trying to find a workaround.

frostworx commented 3 years ago

Any proton version used as "compatibility tool" (including official ones) does (currently?) not use the SLR (or simply use steamtinkerlaunch)

Of course "disabling" the SLR can't be officially supported, but if it fixes things it can't be that wrong. (for me starting without SLR is also much faster)

gort818 commented 3 years ago

There was an update to the Steam Solider runtime.. Just tested. MangoHud is working again with proton 5.13-2 at least for 64bit games. RADV users would mostly likely need to set NODEVICE_SELECT=1 for their games to launch with MangoHud That issue is being tracked here https://gitlab.freedesktop.org/mesa/mesa/-/issues/3801

psofiterol commented 3 years ago

There was an update to the Steam Solider runtime.. Just tested. MangoHud is working again with proton 5.13-2 at least for 64bit games. RADV users would mostly likely need to set NODEVICE_SELECT=1 for their games to launch with MangoHud That issue is being tracked here https://gitlab.freedesktop.org/mesa/mesa/-/issues/3801

Can confirm it works again after updating SLR Soldier. Also confirming it worked on every 64bit game I had already installed and tested on, but not on the single 32bit one I had available to test.

smcv commented 3 years ago

Also confirming it worked on every 64bit game I had already installed and tested on, but not on the single 32bit one I had available to test.

Do you mean this?

If so, this is being worked on. It looks as though the solution needs fixes in the Vulkan-Loader library, which are currently waiting to be reviewed.

loudan-arc commented 3 years ago

Alternatively you can bypass the runtime container by editing the start script at

<steam-library>/steamapps/common/SteamLinuxRuntime_soldier/_v2-entry-point

Adding the following lines after #!/bin/bash:

shift 4
exec "${@}"

Obviously if SteamLinuxRuntime_soldier gets updated then this will need to be done again.

I know this is more of a hack/workaround but this worked for me with games running in Proton such as CS2D, The Henry Stickmin Collection and Injustice: Gods Among Us, games that seem to rely on 32-bit libraries as I see that indicated in MangoHUD itself. It doesn't affect any existing games that only use 64-bit ones, like Shadow of the Tomb Raider.

The only difference is instead of seeing #!/bin/bash at the start, I see #!/usr/bin/env bash , but I still enter under it. In addition, I was also required to set the above games with the command for NODEVICE_SELECT=1 mangohud %command% like what gort818 referred to.

Each time Steam Runtime Soldier does update though, like what others have mentioned, I need to re-add it again. I will update if anything else changes.

Angell1993 commented 3 years ago

If you use Proton v5.13-XX then remember to use PRESSURE_VESSEL_FILESYSTEMS_RO="$MANGOHUD_CONFIGFILE:$VKBASALT_CONFIG_FILE" in the launch option..

This is a Proton Launch command that will use your MangoHud & VKBaslt if available..

shoober420 commented 3 years ago

I was trying to figure out why I couldn’t launch Proton games anymore since version 4.11-12. Thank you so much.

DistantThunder commented 3 years ago

This is still not working for me... Does anyone have a solution besides:

NODEVICE_SELECT=1 MANGOHUD=1 PRESSURE_VESSEL_FILESYSTEMS_RO="$MANGOHUD_CONFIGFILE" %command%?

I've tried this on Proton 5.13-x and I still have no overlay...

Arch Linux 5.10.x, Mesa 21.x-git (was happening on 20.x.x too), Soldier 0.20210126.1.

flightlessmango commented 3 years ago

@DistantThunder https://github.com/flightlessmango/MangoHud/issues/369#issuecomment-709902078

Angell1993 commented 3 years ago

@DistantThunder Have you tried changing the order like this??

PRESSURE_VESSEL_FILESYSTEMS_RO="$MANGOHUD_CONFIGFILE" NODEVICE_SELECT=1 MANGOHUD=1 %command%

That always work for me..

DistantThunder commented 3 years ago

@DistantThunder #369 (comment)

That didn't work for me before but it does now! Thanks!!

@DistantThunder Have you tried changing the order like this??

PRESSURE_VESSEL_FILESYSTEMS_RO="$MANGOHUD_CONFIGFILE" NODEVICE_SELECT=1 MANGOHUD=1 %command%

That always work for me..

Nope, didn't work I had to bypass the container completely.

QuicksilverBR commented 3 years ago

Have also been experiencing this issue ever since swapping to EndeavourOS (Arch); none of the workarounds above seemed to work for Proton games, and interestingly native (OpenGL) titles didn't have MangoHUD either; Wine worked fine. Some more searching lead me to this reply on the Proton issues thread, and the solution worked for me:

Use gamemoderun and mangohud together on startup command:

gamemoderun mangohud PROTON_FORCE_LARGE_ADDRESS_AWARE=1 %command%

Then add the following command in the beginning of the _v2-entry-point file:

shift 4
exec "${@}"

The start of the file should read:

head ~/.steam/steam/steamapps/common/SteamLinuxRuntime_soldier/_v2-entry-point 
#!/usr/bin/env bash

shift 4
exec "${@}"

set -eu
me="$(readlink -f "$0")"
here="${me%/*}"
me="${me##*/}"

This got me from no MangoHUD on any Proton or native game to:

Screenshot_20210226_190130

Screenshot_20210226_190252

Not a perfect solution I'm sure, but a plenty usable workaround until an official fix comes along.

berglh commented 3 years ago

So.. If I run Linux kernel 5.9 + Proton 5.13 + Mangohud, I am able to run Quake Champions without any of these work arounds.

When running Ubuntu 20.04, nvidia 4.60 driver, kernel 5.10/5.11 + Proton 5.13 + Mangohud, the wrapper launches, the processes launch, but no game window appears. As soon as I remove Mangohud from the command, everything is working just fine. I think it's related to this issue, however, I'm not entirely sure.

Eitherway, neither the _v2-entry-point edit, nor the environment variables mentioned in these comments solve the problem for me. Just thought I'd throw my situation in case someone has some suggestions. I'm trying to find other games that are not Vulkan implementations to verify my findings that it's only affecting Quake Champions for me.

berglh commented 3 years ago

So.. If I run Linux kernel 5.9 + Proton 5.13 + Mangohud, I am able to run Quake Champions without any of these workarounds.

I also have observed the same behaviour for Black Mesa, which I thought wasn't a Proton title?

Angell1993 commented 3 years ago

@berglh Any game is basically a proton title, sometimes the native Linux version is bugged to much to play.. I can't say what the differences are in Linux Kernels but something has changed..

smcv commented 3 years ago

I also have observed the same behaviour for Black Mesa, which I thought wasn't a Proton title?

What is "the same behaviour"? Freezing on launch with no game window appearing?

There is some sort of bad interaction between Mesa's device selection Vulkan layer and MangoHUD that can lead to undefined behaviour - which could mean anything, but in practice often freezing or crashing on launch. It isn't clear yet whether the root cause is a bug in Mesa, MangoHUD, Vulkan-Loader or some other component; one of my colleagues is looking into it, and will send a suggested change to whichever project seems most appropriate if we can figure out a solution.

This seems to be more likely to happen in the container runtime used by Proton 5.13+, and it seems to be more likely to happen in Proton, but as far as we can tell, it could happen in anything that uses Vulkan.

Mesa 21.0.0 includes a change that should avoid this. The same change will hopefully be in Mesa 20.3.5, but that hasn't been released yet.

If you are using the NVIDIA proprietary drivers, disabling Mesa's device selection layer with environment variable NODEVICE_SELECT=1 might work around this.

add the following command in the beginning of the _v2-entry-point file

Please note that this sort of hack is completely unsupported and will often lead to Proton not working at all. Valve cannot support Proton when not run in its intended environment.

Leopard1907 commented 3 years ago

Device select layer shouldn't be an issue for Black Mesa. It is on OpenGL , uses ToGL.

https://github.com/ValveSoftware/ToGL

berglh commented 3 years ago

I also have observed the same behaviour for Black Mesa, which I thought wasn't a Proton title?

What is "the same behaviour"? Freezing on launch with no game window appearing?

No game window appearing. It just stays on the steam window and the child process launched terminates as the play putton re-appears on Black Mesa.

There is some sort of bad interaction between Mesa's device selection Vulkan layer and MangoHUD that can lead to undefined behaviour - which could mean anything, but in practice often freezing or crashing on launch. It isn't clear yet whether the root cause is a bug in Mesa, MangoHUD, Vulkan-Loader or some other component; one of my colleagues is looking into it, and will send a suggested change to whichever project seems most appropriate if we can figure out a solution.

I appreciate you actively following through with this :)

If you are using the NVIDIA proprietary drivers, disabling Mesa's device selection layer with environment variable NODEVICE_SELECT=1 might work around this.

I have tried this as you suggest, but it didn't improved matters for me. I am running the latest nvidia driver 460.67-0ubuntu0~0.20.04.1 from the graphics-driver apt repo.

add the following command in the beginning of the _v2-entry-point file

Please note that this sort of hack is completely unsupported and will often lead to Proton not working at all. Valve cannot support Proton when not run in its intended environment.

Understood. I only tried it as a work-around, but had backed up and reverted the file when I found it didn't improve matters for me on a temporary basis. It makes complete sense why this is unsupported if we're bypassing the launch environment intended for compatibility.

smcv commented 3 years ago

No game window appearing. It just stays on the steam window and the child process launched terminates as the play putton re-appears on Black Mesa.

That sounds like a crash.

vanphong1310 commented 3 years ago

Alternatively you can bypass the runtime container by editing the start script at

<steam-library>/steamapps/common/SteamLinuxRuntime_soldier/_v2-entry-point

Adding the following lines after #!/bin/bash:

shift 4
exec "${@}"

Obviously if SteamLinuxRuntime_soldier gets updated then this will need to be done again.

It doesn't work anymore after steam update yesterday. Is there anything else I can do except switching to proton v5.0?

Leopard1907 commented 3 years ago

You need to do shift 2 now.

@vanphong1310

Angell1993 commented 3 years ago

There is another option, I've tried steamtinkerlaunch, and even though I use a version of Arch Linux, I think you can get it to work on other distros..

NerosTie commented 3 years ago

@vanphong1310 It still works for me. What is the update you are talking about?

Tested with Steam Beta Mar 22 2021 + Proton Experimental 5.13-2020-03-11

vanphong1310 commented 3 years ago

You need to do shift 2 now.

@vanphong1310

It works. Thank you very much!

@vanphong1310 It still works for me. What is the update you are talking about?

Tested with Steam Beta Mar 22 2021 + Proton Experimental 5.13-2020-03-11

I don't know, I open AC Odyssey and steam says updating something, then the game doesn't start anymore. I use Proton 5.13-6 and content of VERSIONS.txt file in SteamLinuxRuntime_soldier folder is

#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
vanphong1310 commented 3 years ago

There is another option, I've tried steamtinkerlaunch, and even though I use a version of Arch Linux, I think you can get it to work on other distros..

@Angell1993 Thank you for advice! I have tried it and it works out of the box. How does it work? Does it auto bypass the runtime container for me?

Angell1993 commented 3 years ago

@vanphong1310 I honestly don't know how it works, just that it does..

smcv commented 3 years ago

I honestly don't know how it works, just that it does..

Please don't consider workarounds that you don't understand to be solutions.

You need to do shift 2

Again, please note that this sort of hack is not supportable. Proton 5.13+ official builds are intended to run in the Steam Linux Runtime container environment and there is no expectation that they will run correctly on generic Linux distributions. You do this entirely at your own risk.

Leopard1907 commented 3 years ago

Yes, when issues ironed out with Soldier Runtime i honestly can't think why anyone would want to disable it anyway.

Problem is; Proton 5.0 vs Proton 5.13/Experimental has a huge gap on compatibility of games. People wants to use 5.13 but sometimes they can't do due to either long unresolved issues or new issues comes up.

Hopefully when everything gets solved, this issue can be closed for good. For just the time being, users relies on those workarounds/posting them around with good intents.

Users with runtime originated issues should report them here first, while waiting issues to be solved they can rely on workarounds.

https://github.com/ValveSoftware/steam-runtime/issues

vanphong1310 commented 3 years ago

@Angell1993 I read steamtinkerlaunch source code. It have a option to disable SteamLinuxRuntime and If you choose to run game with GAMEMODE option then SteamLinuxRuntime is disable by default. It is similar to the workaround above, I thought them had a solution for our problem :)

Angell1993 commented 3 years ago

@vanphong1310 Maybe it is similar, but it takes care of the workaround for you.. And it has quite a bit of interesting options to play with..

berglh commented 3 years ago

So.. If I run Linux kernel 5.9 + Proton 5.13 + Mangohud, I am able to run Quake Champions without any of these work arounds.

So, I just did a recursive git pull on submodules, pulled from master and rebuilt MangoHub, now everything is working just fine for me.

Lancer11211 commented 1 year ago

I still have this issue: ERROR: ld.so: object '/tmp/pressure-vessel-libs-PNWNY1/${PLATFORM}/libMangoHud.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.

flightlessmango commented 1 year ago

@Lancer11211 this isn't and never was a mangohud issue, this should be reported to the runtime instead https://github.com/ValveSoftware/steam-runtime/issues

Lancer11211 commented 1 year ago

Oh yeah, sorry, I didn't check the project.