NixOS + Steam discussion thread

[jonringer]

Continuation of https://github.com/NixOS/nixpkgs/issues/100655 without spamming that particular issue

[Atemu]

Could you mark the comment over there as OT and copy pasta it here?

[danieldk]

Copy-pasted from the other issue. Though I guess @jonringer 's (very interesting) comment should probably also go here.

The usage of nix would solve all of the dependency issues in the goals.md. Even solves very difficult issues like:

some games bundle a private copy of libgcc_s.so.1 or libstdc++.so.6, and Mesa graphics drivers also depend on those libraries. If the game's bundled copy is older than the version that the user's Mesa graphics driver requires, the game will crash or otherwise fail to work.

where nix packages will only reference unique nix-store paths, so can actually load many versions of a library at the same time. It also makes what's on the host's system irrelevant (outside of video drivers and a few exceptions, but scope is mitigated).

Could you elaborate what you mean here? We can't dynamically load two libraries with the same soname/symbols. We have the same problem when people mix nixpkgs versions, where they use OpenGL software from an older nixpkgs revision. libc is loaded from the old revision and then dynamic linking Mesa from /run/opengl-driver fails due to missing symbols.

See e.g.:

https://discourse.nixos.org/t/use-old-pinned-version-of-3d-software/9908/6 https://github.com/NixOS/nixpkgs/issues/97311#issuecomment-688350952

(And probably many other issues.)

[jonringer]

I'm not an expert when it comes to glibc, so I'm likely to be wrong in some regards.

Anyway, @danieldk, to reply to https://github.com/NixOS/nixpkgs/issues/100655#issuecomment-755402635

Could you elaborate what you mean here? We can't dynamically load two libraries with the same soname/symbols.

Yes, you're correct. But if steam used nix to package the games, then some of their linking behavior could be better controlled at build time, and reliance on impure behavior would be restricted to graphics drivers and runtime depenencies (commands, etc). My comment was more in regards to "some games bundle a private copy of libgcc_s.so.1 or libstdc++.so.6", in which the vendored libraries will become store paths, and the correct linking can be fixed with patchelf.

libc is loaded from the old revision and then dynamic linking Mesa from /run/opengl-driver fails due to missing symbols.

For NixOS, maybe we should build the graphics libraries with older versions of glibc, to increase compatibility with other binaries. Not ideal, or maybe allow for people to opt-in to an older version being used to build their drivers.

https://github.com/Mic92/nix-ld could also help remedy this maybe?

Windows bends-over backwards to ensure abi compatibility, and it does make it a lot easier to distribute binaries. Linus mentioned this as a major painpoint of linux as well (along with library availability not being guaranteed, thus making package managers almost mandatory).

[jonringer]

Copied from previous thread, to limit off-topic discussion:

I don't think it's realistic to implement what I say below, but I think it's an interesting idea. This is more about determining the viability of Nix as a commercial packaging format; obviously I'm a NixOS fanboy, so take everything I say with a grain of salt:

If steam used nix as its packaging format, then all of these runtime iterations would be irrelevant. Nix closures are pure and isolated by default, so you can use many incompatible library combinations (even within a single process). Game creators would have to create a nix expression, but you can make templates to make the common scenarios pretty easy. With that nix-expression, they can nix-copy-closure the build outputs to some binary cache; and the game+version, system, build-dependencies can be referenced by the .drv produced. Clients wouldn't have access to the underlying repositories, so there's no additional vectors of retrieving game source code, but a binary version would be able to be downloaded from the cache. For clients, the steam client could just do nix-store --realise xxx.drv to "rehydrate"/download the game+dependencies for a platform. This would even work on mac and windows (with mingw toolchain).

You may have to implement some crazy huge ACL on the binary cache to prevent people from downloading games they don't own (however, this would be a valid concern even without nix, and I assume steam has some drm baked into the games it distributes.) The usage of nix would solve all of the dependency issues in the goals.md. Even solves very difficult issues like:

some games bundle a private copy of libgcc_s.so.1 or libstdc++.so.6, and Mesa graphics drivers also depend on those libraries. If the game's bundled copy is older than the version that the user's Mesa graphics driver requires, the game will crash or otherwise fail to work.

where nix packages will only reference unique nix-store paths, so can actually load many versions of a library at the same time. It also makes what's on the host's system irrelevant (outside of video drivers and a few exceptions, but scope is mitigated).

For the security concerns, you will still probably need something like bubblewrap to limit the runtime environment of the games+scripts. But at least at the point, you're only using bubblewrap to isolate the semi-untrusted code from the user's environment, instead of trying to manifest a runtime environment.

Obviously, not everything is wonderful, there's a few other real-world concerns:

• Curation of more toolchains/libraries than what nixpkgs provides (possibly to the point of being a mini-distro). However, patching was mentioned in the goals.md, so I assume this is already being done in some capacity.
• Added complexity to game delivery. Now studios will have to know some Nix, this pain can be mitigated with documentation and templates, but I assume that most games are duct-taped together for their builds which wouldn't do too well in a sandboxed and offline envrionment.
• Need new ways of debugging client environment to reproduce runtime issues. This should make it easier as you can do nix-store --query --requisites <store-path> to get all of the runtime dependencies
• Code ownership of nix expression, and liability of game issues.

And then there's the concerns with Nix in general:

• Nix is still a small community, so it's hard to find domain experts.
• Onboarding to Nix is painful, with a steep learning curve, and relatively small amount of documentation.
• Rebuilds. Changing one dependency will cause the .drv to change for all games which include it as a dependency. This helps when determining when a change broke something as the changes [in nixpkgs at least] are version controlled, but it also means that you will have to rebuild all down stream dependencies as well.

I did a break-down of the goals as if nix was used as the underlying package format:	Goal	Nix supported	Nix unsupported	Comments
Old games continue to work	X		Nix expressions would have to be "backported" to older titles, or legacy behavior would be preserved through older proton versions
i386 games continue to work on i386-capable hosts	X		i686-linux is a "2nd tier"(unofficial) platform. We don't have much CI around this platform, but there are some hydra jobsets (IIRC). Either way, there's nothing preventing i386-linux to be built from source. x86_64-linux to i686-linux can be cross-compiled with pkgsi686Linux.<pkg>
Games are deployed through steampipe			Not sure of the implications. Nix is a c++ codebase, so it may be possible to link directly against it and make the steam client "nix-aware". nix build is able to show download progress, so likely plausible.
Games developed in an impure scout environment continue to work	X		There's no guarentee that this scenario will work in previous or current paradigms. Nix can be leveraged with the use of patchelf to modify the binaries to reference known-good library versions, but would require manual intervention on behalf of steam or game developer to do this packaging.
Host system doesn't need uncommon packages installed	X		Probably the best use case for Nix, as all dependencies are captured within the .drv mentioned above. Nix store paths are unique, so shared dependencies only need to be downloaded once across all games (assuming dependencies are from the same package set. If they differ, then you wouldn't want them shared anyway).
Open-source (Mesa) graphics drivers continue to work	X		Graphics libraries in NixOS are mounted at /run/opengl-driver/, native nix-packages are patched to include it in the elf's RUNPATH. Nixpkgs' steam-wrapper currently exports it on LD_LIBRARY_PATH
Proprietary (NVIDIA) graphics drivers continue to work	X		See above, Nvidia use is also captured

New goals

Goal	Nix supported	Nix unsupported	Comments
New runtimes	X		Nix would also support not using runtimes at all, but dependencies would have to be pinned to major versions. "Runtimes" could just be overlays with certain packages available, e.g. overlays = [ steam_sniper_overlay ];. Dependencies could also be pinned to patch version numbers, but this would be at the cost of hardrive space. Maintenance of the package set would be easier if there was less pinning, and patching would be less likely as you would have the latest of a given major version. Within nixpkgs, pinning is only done on an "as needed" basis (e.g. ansible_2_9 which has breaking changes between minor versions, while we maintain relevant gcc major versions, as those may have breaking changes for some builds). EOL or obsolete libraries are generally removed, and this may be one area of significant maintenance for a steam overlay, however, at least this dependency tree is captured in some regard in a reproducible way.
Games can be built in a container	X		Nix does sandboxed builds by default in linux
Games run in a predictable, robust environment	X		Nix doesn't care about the host's system, nix packages are "hermetic" in this regard.
Games that inappropriately bundle libraries work anyway	X		This would have to be captured in the nix expression, but do-able	Games don't all have to use the same runtime	X		Nix only cares about store paths, runtimes can be an abstraction on top of nix
Steam client runs in a predictable environment	X		See, above. Nix doesn't care about the host system.
Steam client can use a newer runtime	X		Nix doesn't care about the host system
New runtimes can be supported for multiple years	X (reasonable if curating just major versions of libraries)	X (unreasonable if you want to continue "runtime" paradigm with reasonable amount of man-hours)	In the non-runtime world, packages would just have to reference packages like SDL_1 vs SDL_2, but the version variants can easily apply security packages through patches attr, and this would propagate to all packages referring to it. In the current workflow, it mentions that it would just use the system's libraries, but there's no guarantee that it's more secure.
New runtimes do not require newest host system	X		Nix doesn't care about the host system.
New runtimes do not require rebuilding everything	X		NixOS release channel + overlay. The "runtime" iteration would be shortened to 6 months, but if most packages are pinned to major versions in an overlay, this is mitigated.
New runtimes do not require extensive patching	X		Should only need to do security patches (if not already applied). And maintain overlay with pinned major versions of packages not available.
New runtimes work on future hardware	X		Through /run/opengl-driver/ or similar mechanism of limited runtime impurity
i386 games work on non-i386 hosts	X		pkgsi686Linux overlay allows this.
Game data is easy to sync and delete			Would have to be done through bubblewrap or something similar to have limited access to certain files/directories.
Steam can be installed in a cross-distro way	X		Nix doesn't care about the host system.
Steam can be installed unprivileged	X		Nix supports unprivileged installation. Scripts which require to be ran as root would need bwrap'ed in a new userspace to isolate privilege escalation in the host machine
Steam client cannot accidentally break the system			Nix store is mounted as read-only, so virus/backdoors will not be able to inject themselves into anything that is likely to be ran without privilege escalation and some additional work to mount the store as write-able. Bubblewrap would need to be used to isolate "malicious" runtime behavior files that live outside the nix store.
Games cannot accidentally break the system			Same as above
Security boundary between desktop and Steam client			Same as above.
Security boundary between desktop and games			Same as above
Security boundary between Steam client and games			Same as above

[danieldk]

My comment was more in regards to "some games bundle a private copy of libgcc_s.so.1 or libstdc++.so.6", in which the vendored libraries will become store paths, and the correct linking can be fixed with patchelf.

Thanks for the clarification!

For NixOS, maybe we should build the graphics libraries with older versions of glibc, to increase compatibility with other binaries. Not ideal, or maybe allow for people to opt-in to an older version being used to build their drivers.

Yeah, I was thinking about this the other day. It's the advantage that the proprietary NVIDIA driver currently has, since it is built against some lowest common denominator glibc version, it does not seem to suffer from being dynamically linked against a glibc from an older nixpkgs revision. The procedure would be something like:

1. Build Mesa against an older glibc.
2. patchelf Mesa to use the current glibc (to avoid always requiring multiple glibcs).

Not sure what the practical problems one would encounter implementing this though. Also the set of overlapping libraries is probably larger than glibc, including X11 libraries and libstdc++. (I hope downstream software does not link against libLLVM.)

[bbigras]

Is there a workaround to use Proton 5.13?

[Flakebi]

You can use x11docker with a container of a more standard-conforming distribution like arch or ubuntu, install steam in the container and bind-mount your steam library. (Note that x11docker requires a docker image with steam, not a container. So you need to install steam in the Dockerfile.)

[danieldk]

Another option is to install Steam through Flatpak and then use the FlatHub community build of Proton:

https://github.com/flathub/com.valvesoftware.Steam.CompatibilityTool.Proton#installation

I don't think any of my games require such a new Proton, but at least they seem to work fine this way. Steps for convenience:

1. Enable services.flatpak.enable in your NixOS configuration.
2. flatpak remote-add --if-not-exists flathub https://flathub.org/repo/flathub.flatpakrepo
3. flatpak install flathub com.valvesoftware.Steam
4. flatpak install com.valvesoftware.Steam.CompatibilityTool.Proton
5. flatpak run com.valvesoftware.Steam

[bbigras]

@danieldk any special trick to use protontricks? Do I just need to set export STEAM_DIR=~/.var/app/com.valvesoftware.Steam/.local/share/Steam?

EDIT: it's:

flatpak install flathub com.valvesoftware.Steam.Utility.protontricks
echo "alias protontricks-flat='flatpak run --command=protontricks com.valvesoftware.Steam'" >> ~/.bashrc

[nh2]

I just upgraded to NixOS 21.05. Dota2 + Vulkan on NVIDIA proprietary seems to no longer work (log messages also mention lavapipe which is a software-renderer). OpenGL mode works fine.

Would be interested whether anybody has a similar problem.

[timor]

Do you get error messages that Direct3D does not find a compatible device?

[timor]

Well, that was the typical symptom for me, at least. The issue that was affecting me is described here: https://discourse.nixos.org/t/steam-doesnt-detect-nvidia-graphics-device-after-update/11957

[nh2]

Do you get error messages that Direct3D does not find a compatible device?

@timor I don't thinks so -- Direct3D is DirectX, and Dota2 is a Linux-native OpenGL / Vulkan game.

I get these with the -vulkan launch option enabled:

Starting app 570
>>> Adding process 241417 for game ID 570
GameAction [AppID 570, ActionID 1] : LaunchApp changed task to WaitingGameWindow with ""
ERROR: ld.so: object '/home/niklas/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/niklas/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
pid 241419 != 241418, skipping destruction (fork without exec?)
ERROR: ld.so: object '/home/niklas/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
GameAction [AppID 570, ActionID 1] : LaunchApp changed task to Completed with ""
>>> Adding process 241418 for game ID 570
ERROR: ld.so: object '/home/niklas/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
>>> Adding process 241420 for game ID 570
ERROR: ld.so: object '/home/niklas/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.
ERROR: ld.so: object '/home/niklas/.local/share/Steam/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored.

However, those appear also with -gl, when Vulkan is disabled.

And this is a popup:

CreateSwapChain():

The selected graphics queue does not support presenting a swapchain image.

(Like this https://github.com/ValveSoftware/Dota-2-Vulkan/issues/153)

---

With -gl (which is working), I later also get:

failed to dlopen "libtensorflow.so" error=libtensorflow.so: cannot open shared object file: No such file or directory

This isn't a problem according to Valve: https://github.com/ValveSoftware/Dota-2-Vulkan/issues/361

[nh2]

With LD_DEBUG=libs from https://discourse.nixos.org/t/steam-doesnt-detect-nvidia-graphics-device-after-update/11957/11 I get:

Log file: nixos-21.05-nvidia-dota2-vulkan-error.txt

[nh2]

The presence of

MESA-INTEL: warning: Performance support disabled, consider sysctl dev.i915.perf_stream_paranoid=0

WARNING: lavapipe is not a conformant vulkan implementation, testing use only.
MESA-INTEL: warning: Performance support disabled, consider sysctl dev.i915.perf_stream_paranoid=0

WARNING: lavapipe is not a conformant vulkan implementation, testing use only.

(However these are emitted by Steam, before I click the Play button to launch of the dota2 binary.)

In the output makes me suspicious that in my hybrid Intel+Nvidia laptop, on 21.05 it tries to use software Vulkan via Mesa somehow instead of Nvidia.

I also found this thread from May, which suggests something in that direction: https://forum.garudalinux.org/t/most-vulkan-applications-broken-due-to-llvmpipe/8599

Is there a way I can force Vulkan to consider Nvidia only?

[nh2]

I found a workaround:

diff --git a/pkgs/games/steam/fhsenv.nix b/pkgs/games/steam/fhsenv.nix
index 44bee8ff11a..75a319db4f5 100644
--- a/pkgs/games/steam/fhsenv.nix
+++ b/pkgs/games/steam/fhsenv.nix
@@ -281,7 +281,8 @@ in buildFHSUserEnv rec {

     export STEAM_RUNTIME=${if nativeOnly then "0" else "/steamrt"}

-    export VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/intel_icd.x86_64.json:/usr/share/vulkan/icd.d/intel_icd.i686.json:/usr/share/vulkan/icd.d/lvp_icd.x86_64.json:/usr/share/vulkan/icd.d/lvp_icd.i686.json:/usr/share/vulkan/icd.d/nvidia_icd.json:/usr/share/vulkan/icd.d/nvidia_icd32.json:/usr/share/vulkan/icd.d/radeon_icd.x86_64.json:/usr/share/vulkan/icd.d/radeon_icd.i686.json
+    export VK_ICD_FILENAMES=/nix/store/d6qsiyg6vwfvrzdr0m3vsbirwnzp6yw9-nvidia-x11-460.73.01-5.10.37-lib32/share/vulkan/icd.d/nvidia_icd.json:/nix/store/20g202m9ap5wxrdl7spifv8n2hhnnfcx-nvidia-x11-460.73.01-5.10.37/share/vulkan/icd.d/nvidia_icd.json
   '' + extraProfile;

   runScript = writeScript "steam-wrapper.sh" ''

Simply removing the line also fixes it:

diff --git a/pkgs/games/steam/fhsenv.nix b/pkgs/games/steam/fhsenv.nix
index 44bee8ff11a..75a319db4f5 100644
--- a/pkgs/games/steam/fhsenv.nix
+++ b/pkgs/games/steam/fhsenv.nix
@@ -281,7 +281,8 @@ in buildFHSUserEnv rec {

     export STEAM_RUNTIME=${if nativeOnly then "0" else "/steamrt"}

-    export VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/intel_icd.x86_64.json:/usr/share/vulkan/icd.d/intel_icd.i686.json:/usr/share/vulkan/icd.d/lvp_icd.x86_64.json:/usr/share/vulkan/icd.d/lvp_icd.i686.json:/usr/share/vulkan/icd.d/nvidia_icd.json:/usr/share/vulkan/icd.d/nvidia_icd32.json:/usr/share/vulkan/icd.d/radeon_icd.x86_64.json:/usr/share/vulkan/icd.d/radeon_icd.i686.json
   '' + extraProfile;

   runScript = writeScript "steam-wrapper.sh" ''

The line was introduced recently in PR #114024: https://github.com/NixOS/nixpkgs/pull/114024/files#diff-eb71ed3d7ca411e2ad9a8390f457a0959489417d26e8140ce7e39d35cc439a01R269

[nh2]

Simply removing the line also fixes it:

Shorter workaround: Using extraProfile to unset the variable:

{
  environment.systemPackages = with pkgs; [
    (steam.override { extraProfile = ''unset VK_ICD_FILENAMES''; })
  ];
}

[jonringer]

@nh2 we should probably make this configurable when people do programs.steam.enable = true;

[starcraft66]

Simply unsetting that variable is not a suitable fix, it is required for DXVK to work with games under steam play with pressure-vessel.

[timor]

@nh2 If you don't mind, could you post the contents of /usr/share/vulkan/icd.d/nvidia_icd.json and /usr/share/vulkan/icd.d/nvidia_icd32.json inside the non-working steam fhs-env?

[critbase]

I have the same issue with VK_ICD_FILENAMES; i had horrible performance in Hades, for example, until i changed my configuration.nix to the following:

boot.kernelPackages = pkgs.linuxPackages_zen;
hardware.nvidia.package = config.boot.kernelPackages.nvidia_x11;

(steam.override {
  extraLibraries = pkgs: [ pkgs.pipewire ];
  extraProfile = ''
    unset VK_ICD_FILENAMES
    export VK_ICD_FILENAMES=${config.hardware.nvidia.package}/share/vulkan/icd.d/nvidia_icd.json:${config.hardware.nvidia.package.lib32}/share/vulkan/icd.d/nvidia_icd32.json'';
})

it's important to mention that i'm running an optimus setup, in addition to using the linux-zen kernel (as seen above). I think the optimus setup means that the default value of VK_ICD_FILENAMES forces loading the intel vulkan files first, causing poor performance. Additionally, (i think) due to my use of linux-zen, merely reordering and putting /usr/share/vulkan/icd.d/nvidia_icd.json before the intel files doesn't work, and gives me poor performance still. I assume this is because the icd.json points to a different version of the nvidia drivers, but i'm not knowledgeable enough to say whether this is truly the case.

My suggestion would be to generate the VK_ICD_FILENAMES variable from the user configuration (like the above), and if necessary, add default values for things like hardware.nvidia.package, and to make sure files for discrete gpus are placed before those for integrated gpus (nvidia/amd before intel). My current configuration means I would be unable to run vulkan games on the intel gpu (as i haven't added them to the list).

[jonringer]

I created #126428 for the VK_ICD_FILENAMES, as it's slightly off topic, and we can probably resolve that issue separately from this issue thread.

[nh2]

@nh2 If you don't mind, could you post the contents of /usr/share/vulkan/icd.d/nvidia_icd.json and /usr/share/vulkan/icd.d/nvidia_icd32.json inside the non-working steam fhs-env?

How do I resolve the /usr/share/vulkan to a nix store path (or whatever other path on my system)? I'm not familiar with fhs-envs.

[timor]

@nh2 If you don't mind, could you post the contents of /usr/share/vulkan/icd.d/nvidia_icd.json and /usr/share/vulkan/icd.d/nvidia_icd32.json inside the non-working steam fhs-env?

How do I resolve the /usr/share/vulkan to a nix store path (or whatever other path on my system)? I'm not familiar with fhs-envs.

I know of the following possibilities: Either by using the "Browse local files" (or similar, don't know about the exact English naming) option in a game's settings menu in steam, which should give you a file manager inside the fhs-env, or by looking up the store path of the fhs-env by inspecting the contents of the steam wrapper script that is installed by NixOS. If it is installed system-wide, you could also grep like this: nix-store -qR /run/current-system | steam.

[Ashe]

I have had mixed success with NixOS + Steam + Proton lately. At one time everything worked perfectly, and at some point after doing nixos-rebuild I imagine something got updated and things started to break. Of course, Steam could have updated and broken things too, but shouldn't that only be the case for newer proton version?

I am on the unstable channel, running NixOS 21.11 and AMD mesa version 21.1.4. I am on Wayland with Sway as my compositor. I've tried every proton version and a few GE versions up to the latest one. Really not sure what's going wrong.

When things break, I constantly get errors like 'DX11 feature level 10.0 is required to run the engine' (Days Gone) or 'Support for DirectX 10 has ended' (Warframe). I have an AMD 6900XT and so clearly something is going wrong between NixOS, Proton and the game.

Is there a general consensus on the health of steam in NixOS? At the time of writing, my games have stopped working more often than not which is a shame. I don't have much time to tinker at the moment but it's always a shame when I try to boot up something that used to work only for me to get errors with DirectX for some reason.

[buckley310]

Steam is the main reason I use the stable channel. I've found it to be quite reliable on stable channels. On unstable I would run into frequent issues. When i was running the unstable branch, I actually had better luck with running Steam under flatpak.

[critbase]

@Ashe just to make sure it's not a similar issue to #126428/#126435, could you try and see if the issues persist with this in your config?

environment.systemPackages = with pkgs; [
  (steam.override {
    extraProfile = ''
      unset VK_ICD_FILENAMES
      export VK_ICD_FILENAMES=/usr/share/vulkan/icd.d/radeon_icd.x86_64.json:/usr/share/vulkan/icd.d/radeon_icd.i686.json:${pkgs.amdvlk}/share/vulkan/icd.d/amd_icd64.json:${pkgs.driversi686Linux.amdvlk}/share/vulkan/icd.d/amd_icd32.json
    '';
  })
];

(if you have steam installed through your home-manager config or something, just put the override there). What this config does is set VK_ICD_FILENAMES to the amd-specific ICD files. I think that your issues may be caused by DXVK not being able to find the proper ICD files, and thus DX11 games error out, especially if the fallback lavapipe implementation is selected, as this is slow even if games manage to run on it. note that #126435 should fix this, so if the above config works, I'd appreciate you testing if that PR also works, if possible.

[davidak]

Today i also had issues to start proton games. I created an issue here: https://github.com/NixOS/nixpkgs/issues/130699

[jbalme]

Looks like Pressure Vessel broke.

Proton 5.0 works fine for me, for games that will run with it. 5.13+ don't launch at all, with pressure-vessel related errors in console.

[starcraft66]

I've been having issues with Proton for a long time but never bothered to open an issue. All was looking great for a while after https://github.com/NixOS/nixpkgs/issues/100655 was merged but I started having issues a few months after. I can't even run super old games like Call of Duty: Modern Warfare 2 that have always worked fine in wine and run effortlessly on other distros.

[Ashe]

@Ashe just to make sure it's not a similar issue to #126428/#126435, could you try and see if the issues persist with this in your config?

(if you have steam installed through your home-manager config or something, just put the override there). What this config does is set VK_ICD_FILENAMES to the amd-specific ICD files. I think that your issues may be caused by DXVK not being able to find the proper ICD files, and thus DX11 games error out, especially if the fallback lavapipe implementation is selected, as this is slow even if games manage to run on it. note that #126435 should fix this, so if the above config works, I'd appreciate you testing if that PR also works, if possible.

Unfortunately, that didn't fix anything. Honestly it's hard to conduct tests since there's so many variables.

• Deep Rock Galactic didn't complain about DirectX10 stuff like before, but now freezes with a black screen depending on the proton version I use
• Other games which previously complained about DirectX just quit straight away. This might be a good sign, since this was the functionality I had when I tried flatpak with steam, so maybe the DirectX error was fixed, but there's an even bigger issue.

Looking at the main post in #130699 I too have some similar logging with regards to pressure-vessel-adverb: No such file or directory:

pressure-vessel-wrap[31951]: W: "/nix/store/wvgyhnd3rn6dhxzbr5r71gx2q9mhgshj-glibc-2.32-48/lib/ld-2.32.so" is unlikely to appear
in "/run/host"
pressure-vessel-wrap[31951]: W: "/nix/store/wvgyhnd3rn6dhxzbr5r71gx2q9mhgshj-glibc-2.32-48/lib/ld-2.32.so" is unlikely to appear
in "/run/host"
pressure-vessel-wrap[31951]: W: "/nix/store/d2lr6zj99qymk1c8qci433yjx1ggx5l4-glibc-2.32-48/lib/ld-2.32.so" is unlikely to appear
in "/run/host"
pressure-vessel-wrap[31951]: W: "/nix/store/d2lr6zj99qymk1c8qci433yjx1ggx5l4-glibc-2.32-48/lib/ld-2.32.so" is unlikely to appear
in "/run/host"
pressure-vessel-wrap[31951]: W: Found more than one possible libdrm data directory from provider
pressure-vessel-wrap[31951]: W: "/nix/store/d6i9rx79d0qzrz2cqwwc5sj78wwr919n-libdrm-2.4.106/share/libdrm" is unlikely to appear in "/run/host"
bwrap: execvp /usr/lib/pressure-vessel/from-host/bin/pressure-vessel-adverb: No such file or directory
Game removed: AppID 548430 "", ProcID 31950
Uploaded AppInterfaceStats to Steam
Exiting app 548430

If this comment is a separate thing then I'll exit this discussion but overall it seems like steam is rampant with bugs at the moment, I hope we can figure all these things out!

[critbase]

Huh, I just hit that bug. Yeah it seems it's separate. So it seems currently we have a few different bugs with steam:

130699, which seems to be an issue with an update to the steam soldier runtime not working on NixOS

126428, which is an issue with Vulkan/related environment variables

and maybe more that I haven't seen or personally hit.

[Ashe]

@critbase your overrides for the steam package fixed my DX11 issue, and the workaround for Steam Soldier posted in issue #130699. Thank you for your help! I think we're slowly getting through all these issues now!

[jtrees]

Since the latest Steam update, I now need two workarounds for Steam and Proton to work:

# configuration.nix

environment.systemPackages = with pkgs; [
  (steam.override {
      # Workaround for embedded browser not working.
      #
      # https://github.com/NixOS/nixpkgs/issues/137279
      extraPkgs = pkgs: with pkgs; [ pango harfbuzz libthai ];

      # Workaround for an issue with VK_ICD_FILENAMES on nvidia hardware:
      #
      # - https://github.com/NixOS/nixpkgs/issues/126428 (bug)
      # - https://github.com/NixOS/nixpkgs/issues/108598#issuecomment-858095726 (workaround)
      extraProfile = ''
        export VK_ICD_FILENAMES=${config.hardware.nvidia.package}/share/vulkan/icd.d/nvidia_icd.json:${config.hardware.nvidia.package.lib32}/share/vulkan/icd.d/nvidia_icd32.json:$VK_ICD_FILENAMES
      '';
    })
]

[jonringer]

first workaround has been merged into master, and may be backported already.

Second workaround is liking to be fixed by https://github.com/NixOS/nixpkgs/pull/135024

[tgunnoe]

We should make a nix-based command line that one shot installs steam or gog games. Why even invest so much time in making these platforms work in nixos? 90% of the time, it never works for me. Lets think about it from the outside instead, and use steam as a data source. I'm thinking one shot commands to download the steam data and set it up correctly on nixos. I'm very tired of only having a brief support window for this stuff, ie until steam or soldier updates again, etc.

[06kellyjac]

Is that not what programs.steam.enable is meant to do? I dont understand why we need an extra tool

[SuperSamus]

There are many issues that I think could be closed right now, other than the ones listed in #157907:

Surely: #25444, #73445, #76516, #136352, #148628, #151194.

Probably (I may be wrong): #33218, #63837, #126389, #150319, #134556 (and PR #126435).

[jonringer]

I poked through most of those, and closed the ones I know are no longer relevant

[tgunnoe]

@jonringer and others in this thread have already provided many cases where the nix way can solve all of steam's problems and beyond, yet, the solution is to just constantly follow downsteam steam support in nix, even though, in my experience and in many others it only works here a fraction of the time? we should be concentrating all of this hugely valuable engineering time on providing nix's alternate solution that is steam-data-api compatible. that will yield the most results long term

[tgunnoe]

I think we should support proton-based games using nix and steam/gog as a data sources. so make a basic user interface to dealing with user game data but with nix defined install methods. Look at this old lutris thread about making linux + nix a serious thing https://github.com/lutris/lutris/issues/666 This is one of the few markets that nix has huge potential to fix for users and that doesn't need to be developer focused. it can solve a overwhelming proprietary software world while being equally compatible with free software

[jonringer]

I don't really expect valve and 3rd parties to adopt nix, as nix still doesn't have amazing first class windows support.

Valve has provided documentation in how they expect proton and pressure-vessel to be communicated to with dependencies, and I think that's enough short term.

Obviously I'm hopeful that nix will eventually solve a lot of hard problems and would love for upstreams such as lutris or steam to adopt some or all nix into their workflows. Until then, we can just provide a pseudo FHS environment for it to thrive.

[pmarreck]

Ran into an issue with a game (Encased) which was definitely working a month ago or so but which must have stopped working correctly after some past update, which took me here. (Side note: Wouldn't it be great to be able to unit-test games after every update?)

Big fan of the Nix philosophy, relatively still new to it (honeymoon stage of technological awe).

I could care less if Windows is supported. Linux should be the "native gaming OS", IMHO. It's high time that gaming didn't almost entirely depend on a proprietary OS to be fully realized. That's the current situation, but I expect that to change (hopefully the Steam Deck helps push that needle over).

So in theory, Nix could get us a deterministically-reliable gaming environment. So what inputs are out of its derivation's control that could still affect its ability to work correctly? The GPU driver(s)? The kernel version? Specific Proton versions? xorg vs wayland? glibc? (I had to throw shade at glibc, as it's been a pain lately, so it might as well be causing problems here too.) I doubt we could get individual games, or Steam itself, to "see" a different GPU driver than the OS itself does, but maybe it could require a certain Nvidia/Radeon driver or whatnot to be installed at the OS level. Does each game need to be a separate derivation, or could some have optional overlays? (flakes, etc.) (Is it even possible to install a game without the Steam client being involved?)

I feel gross resorting to the flatpak version (can I even install proton-GE to that, or is it completely sandboxed?) I do know the game runs fine on Steam Deck, however.

I'm glad that there are people here who care about both gaming and corralling the inherent nondeterminism in much of Linux.

[ashkitten]

@pmarreck without any additional debugging information it's impossible to determine what might be causing your game to not work. please include:

• the output of "Help > System Information" in steam (wait for the full output to populate, it may take up to a minute)
• proton logs. you can get those by setting the game's launch arguments to PROTON_LOG=1 %command% in steam and launching the game. this will create a file called steam-<appid>.log in your home directory.
• relevant system information including nixpkgs revision

[pmarreck]

@ashkitten I wasn't asking for help with that here, which is why I didn't provide much detail; I do not want to derail the focus. That problem merely inspired me to add my thoughts here. I will attempt to fix that issue on another thread.

[06kellyjac]

I feel gross resorting to the flatpak version (can I even install proton-GE to that, or is it completely sandboxed?) I do know the game runs fine on Steam Deck, however.

As a note the steamdeck doesn't use steam from a flatpak AFAIK, it's just a carefully curated set of libs + steam on top of their arch base

if you use protonup-qt via flatpak it should be steam flatpak friendly from what I've read

[jonringer]

Many of the steam fixes have been merged 2 years ago in https://github.com/NixOS/nixpkgs/pull/157907, and steam support of NixOS is in a "working, but could use more refinement for some games".

Going to close this issue as the main topic (using nix like paradigms to ship binaries) is not super actionable.