Steam linux runtime soldier ��� ���

Steam linux runtime soldier ��� ���

I’ve been looking all over the web for some clarification but it was no use.

I’ve read that Steam Linux Runtime — Soldier runs games on a container that tries to be the same for every Linux distro. But my question is how does it compare to Proton? I am currently running all my games with the latest Proton but I wanted to know if I’m missing anything by not using Steam Linux Runtime.

Thanks for your time. I’m using Ubuntu 20.04 by the way.

It seems to be a set of libs used to compile games on.

It seeks to provide a compatible way for Game creators to make Steam-hosted games.
The compilation is supposed to be done within a docker provided by valve, but there’s other techniques too.

It is definitely not proton since the products of steam runtime (i.e. game installation) wouldn’t need an emulator (Proton is just a python script wrapping a software emulator called wine).

its also steam’s answer to prolong game compatibility as distributions continue to drop older support.
ie: i386

its a basic set of libraries for games to run on, instead of the system libraries
which is why its on the steamplay tab. and you can run a game with that runtime selected

proton is an ’emulation’ layer for windows games.
steam linux runtime is a set of native linux libraries.

its also steam’s answer to prolong game compatibility as distributions continue to drop older support.
ie: i386

its a basic set of libraries for games to run on, instead of the system libraries
which is why its on the steamplay tab. and you can run a game with that runtime selected

Yes, that’s exactly it.

There are plenty of games on steam that have a native linux version available (all those with the SteamOS icon on the store, which used to be a penguin icon but foolishness struck them and they changed it. )

Proton is only for windows-exclusives (or to force-use the windows version of a game even when it has a native linux version).

Both the steam linux runtimes and proton are called into use by the steam launcher only when needed by a specific game.

And you can even have multiple versions of Proton coexisting to be able to select the ine that works best for a specific game.

So what I select in the dropdown menu in the Setting / Steam Play tab will be forced on all the titles? Or it will just be forced on games not native to Linux?

IIRC the global setting (Steam > Settings) won’t force linux native titles to use proton, but the game-specific setting (Steam > Library > Game > Properties) definitely does have that ability (I use it with Dicey Dungeons, which has a native linux version but on my PC only the Proton version launches correctly

There is one bit missing from the picture that may help you piece this design quirk together:

Valve calls the entire framework for compatibility layers «Steam Play».

Not all compatibility layers are for windows games, though the most prominent official layer (Proton) is there for that exact purpose.

They also made it possible for us to provide custom layers. and some folks jumped at the oportunity, making custom forks of DOSBox (for DOS games), ScummVM (for 2D click-and-play games like Curse of Monkey Island) and other opensource alternate game engines which can use game resources from an original game. These forks do more or less what proton did to Wine (integrating steam achievements, cloud sync for saves, steam controller and overlay integration, etc).

Steam Runtimes wasn’t seen by Valve exactly as a compatibility layer. first because it exists before «Steam Play» was invented. second, because it includes a base set of libs for games to be able to use Steam features consistently everywhere (including a windows version of the Steam Runtimes on Steam on Windows), plus a standard version of basic libs any executable needs, to avoid issues between distros with different versions of said libs, etc.

What put Steam Linux Runtimes in the list of compatibility layers was a more recent development (internally called Pressure Vessel) where Valve learned to use Linux namespaces to run a native linux game in a dedicated sandboxed space which provides a complete set of those Steam Linux Runtime libs in the sandbox.

. and to use this for a game they just added the stuff to Steam’s Steam Play framework, which already supported offering multiple compatibility layers of varied nature for any game including linux native ones.

They could have used «Pressure Vessel 1.0″ instead of Steam Linux Runtimes» in the droplist, or «namespaces 1.0». maybe it would avoid a couple mixups. but what’s inside the bottle is the runtimes and that is what needs more care with versioning control, etc.

Источник

Steam linux runtime soldier ��� ���

I refreshed my Linux machines few days ago. then, I noticed any game which uses proton cannot start (stuck in «Preparing to launch XXX . » on popup window) on one of my machines. mysteriously, this problem happens only on a specific machine. other machines don’t have this problem.

I configured software on them as same as possible , but, it seems I did something wrong . now, I found some workaround, but I cannot find what’s wrong.

it seems it’s stuck in iscriptevaluator.exe, uninstalling the game is also stuck in it. 🙁

workaround1: using «previous_release» branch for Steam Linux Runtime — Soldier
workaround2: remove both NVIDIA cards
workaround3: use VK_ICD_FILENAMES

main Linux box (has problem)

• CPU: AMD Ryzen 3 2200G
• dGPU: AMD Radeon RX 470 (used with DXVK_FILTER_DEVICE_NAME=POLARIS)
• OS: Ubuntu 20.04.1 (Linux 5.8 kernel and amdgpu driver)
• Mesa: 20.3.3 (from kisak-mesa)
• NVIDIA GT730: for Steam Remote Play with NVENC
• NVIDIA GT710: for Twitch streaming with OBS Studio

sub Linux box (no problem)

• CPU: AMD FX-8800P
• dGPU: AMD Radeon RX 470 (used with DXVK_FILTER_DEVICE_NAME=POLARIS)
• OS: Ubuntu 20.04.1 (Linux 5.8 kernel and amdgpu driver)
• Mesa: 20.3.3 (from kisak-mesa)
• NVIDIA GT710: for Steam Remote Play with NVENC

laptop (no problem)

• CPU: AMD Ryzen 5 3500U
• dGPU: N/A
• OS: Ubuntu 20.04.1 (Linux 5.8 kernel and amdgpu driver)
• Mesa: 20.3.3 (from kisak-mesa)

You have a lot of graphic cards in the first rig, maybe the ICD loader is choosen wrong,
Check this quick read:
https://wiki.archlinux.org/index.php/Vulkan#Selecting_vulkan_driver

I have to put it in my config file to load it with my system, with proton 5.13-5

Источник

Soldier runtime prevents proton from running #278

Comments

CosmicToast commented Oct 17, 2020

Your system information

• Steam Runtime Version: v0-111-gc94c8fd | soldier 0.20201007.0
• Distribution (e.g. Ubuntu 18.04): Fedora 33
• Link to your full system information (Help -> System Information) in a Gist: https://gist.github.com/CosmicToast/f9079360bb0533700d2564fba0b34a4b
• Have you checked for system updates?: Yes
• Are you using the Steam Linux Runtime compatibility tool?: Yes (Proton 5.13 dependency)

Please describe your issue in as much detail as possible:

1. Launch steam with PRESSURE_VESSEL_VERBOSE=1
2. Run a game with proton 5.0-9 — launches
3. Run a game with proton 5.13 — does not launch
4. Edit soldier entrypoint to skip over it, run agame with proton 5.13 — launches

This narrows down the culprit to soldier.
Note that in the log there is a 5. this is a repeat with point 3 (unedited proton 5.13) but the launch options reset to default, purely for demonstration purposes.

1. Username change to «USER»
2. Hostname changed to «HOSTNAME»
3. Steam Username changed to «STEAMUSER»
4. Additional ____ STEP X ____ were inserted to help identify the steps from the above description. These are purely informative (i.e may not be at the VERY start of the block, but I did put in reasonable effort).

Full log: https://gist.github.com/CosmicToast/7a1dd02c9bc7a2d3cc2005bfea79df0b
The expected results are for step 3 (and 5) to launch the game.

Steps for reproducing this issue:

Repeat of the above for consistency purposes.

1. Launch steam with PRESSURE_VESSEL_VERBOSE=1
2. Run a game with proton 5.0-9 — launches
3. Run a game with proton 5.13 — does not launch
4. Edit soldier entrypoint to skip over it, run agame with proton 5.13 — launches
5. Edit soldier entrypoint back to its original state (or use «verify files») and remove any launch options (while staying with proton 5.13) — does not launch

There are various reports of people having trouble with proton 5.13.
Since the issue is clearly with the runtime, this issue is here to serve as a meta tracker, as well as consolidate the soldier runtime-specific data.
Common reports talk about disabling the runtime, which is done in this log (this is step 4) for demonstration and logging purposes.
Note that PROTON_LOG with proton 5.13 and the runtime enabled has no effect (thus it was not included).

Other threads to see:

• flightlessmango/MangoHud#369 (comment) (procedure for disabling soldier runtime)
• ValveSoftware/Proton#4278 — one of the related proton issues. Though one person in the thread had a different problem, people with this issue are in the thread as well.
• ValveSoftware/Proton#4270 — another related issue (original reporter not seeing issues with the runtime disabled)

Additional details: prior to the log running, all components involved (scout runtime, soldier runtime, proton 5.0 and proton 5.13) were reinstalled. The game being tested (wildfire) is installed on the same disk as them (the main one in /home) for clarity purposes.

The text was updated successfully, but these errors were encountered:

smcv commented Oct 19, 2020

consolidate the soldier runtime-specific data

This might be counter-productive. There are lots of reasons why the container-based runtime might fail to start, with the same user-facing symptom (it doesn’t start). Fixing one root cause will have no effect on all the others.

If people use a single issue report for multiple root causes, then in practice we will never be able to close that issue report, because there will always be one more root cause that isn’t fixed yet — and that isn’t particularly helpful for issue tracking and triaging.

smcv commented Oct 19, 2020 •

Common reports talk about disabling the runtime

You can experiment with this for your own interest, but please do not recommend it, especially to less knowledgeable users. Disabling or bypassing the Steam Runtime, either the older LD_LIBRARY_PATH runtime or the newer container runtimes, is completely unsupported.

Proton 5.13 is compiled to run on Steam Runtime 2 ‘soldier’ and is not expected to work in other runtime environments. If native Linux games are compiled against ‘soldier’ in future, they will also be intended to work only on ‘soldier’, not in other runtime environments. (There are currently no native Linux games on Steam that need ‘soldier’, and it’s unlikely to happen until the container runtime system is more robust.)

Similarly, older Proton builds like 5.0, and all current native Linux games on Steam, are compiled against Steam Runtime 1 ‘scout’ and intended to run in a ‘scout’ environment, either the traditional LD_LIBRARY_PATH runtime (which ends up being a mixture of ‘scout’ and the host system) or the newer SteamLinuxRuntime container runtime. They are not intended to run in any other environment (not even ‘soldier’).

CosmicToast commented Oct 19, 2020

I’m not recommending it.
The statement is there for two purposes:

1. The issue is severe enough that there are people already doing this, with examples.
2. It actively demonstrates that the root cause is soldier (since it is the only variable being modified).

It not being supported is obvious, since it’s modifying steam internals.

Though on that note, this is the typical «different library versions» problem, so all that really matters is (non-kernel) ABI compatibility. The general concept of a runtime environment is consequently mostly void.
Looking into soldier I’m seeing only a couple of things actually bundled, namely:

• glibc 2.28 (fair, glibc loves breaking abi)
• nss modules (not sure why that’s needed, but they’re bundled with glibc so it’s fine)
• pam (does not break ABI very often afaik)
• gtk 2, gtk 3 and pixbuf 2 (does not break ABI very often afaik)
• v4l (not sure why this is here)
• pulse 12.2 libraries (this will actually likely break systems running pipewire as their only audio daemon)
• gio (which is prominent in the logs (dconf settings) for failing to load)
• gconv (does not break abi very often afaik)
• dri (including virtio, old nouveau and vm drivers, and even radeon; but not amdgpu for some reason)
• python (understandable since proton has python components)

This is actually a significant departure from scout, which also included some common things, such as:

Which I would expect to be used relatively often (e.g openssl in games with networking).

From this I induce that soldier is (at least for now) explicitly just the bare minimum required for proton 5.13, which does indeed raise the question of why it needs gtk 2, gtk3, v4l and similar.

This might be counter-productive. There are lots of reasons why the container-based runtime might fail to start, with the same user-facing symptom (it doesn’t start). Fixing one root cause will have no effect on all the others.

Are you perchance familiar with the concept of a meta-bug?
If these issues turn out to be separate root causes I have little issue with adding a checklist with the various root causes to the OP.

Источник