[pressure-vessel] NVIDIA encoding libraries (libnvidia-encode.so.1) and VA-API driver not captured on Manjaro/Arch

[Reverberation1]

Your system information

• Steam Runtime Version: 1.0.20251202.187498
• Distribution (e.g. Ubuntu 18.04): Manjaro Linux
• Link to your full system information (Help -> Steam Runtime Diagnostics) in a Gist: System Information
• Have you checked for system updates?: Yes
• What compatibility tool are you using?: Steam Linux Runtime (scout/soldier/sniper)
• What versions are listed in steamapps/common/SteamLinuxRuntime/VERSIONS.txt?

depot 0.20240806.0
scripts 0.20240806.0

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

pressure-vessel 0.20251210.0 (scout)
scripts 0.20251210.0
soldier 2.0.20251216.191773

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

depot 3.0.20251216.191774
pressure-vessel 0.20251210.0
scripts 0.20251210.0
sniper 3.0.20251216.191774

Please describe your issue in as much detail as possible:

Remote Play from this NVIDIA host fails to initialise hardware encoding. The streaming_log.txt reports NVENC - No CUDA support and attempts to fall back to VAAPI, which also fails with va_openDriver() returns -1.

The issue appears to be a failure in pressure-vessel to capture the NVIDIA encoding libraries from the host, even though they are present and correctly installed.

I have verified that the 32-bit and 64-bit libraries exist on the host via ldconfig -p | grep libnvidia-encode:

    /usr/lib/libnvidia-encode.so.1
    /usr/lib32/libnvidia-encode.so.1

In the attached Steam Runtime Diagnostics, libcuda.so.1 is successfully mapped into overrides, but libnvidia-encode.so.1 is completely absent from the container overrides list.

nvidia_drv_video.so is not found in the container's DRI paths, preventing the hardware fallback.

I attempted to force-mount the libraries using PRESSURE_VESSEL_FILESYSTEMS_RW, but the runtime rejected this with the message: W: Not sharing path ... with container because "/usr" is reserved by the container framework.

This suggests that the runtime's discovery logic is intentionally or unintentionally skipping these specific libraries on this distribution/driver combination (NVIDIA 590.48.01) (?).

SLR Log
Streaming Log

Steps for reproducing this issue:

1. Launch Steam on a Manjaro/Arch host using NVIDIA 590.xx drivers with lib32-nvidia-utils installed.
2. Attempt a Remote Play session to a client (e.g., Steam Deck).
3. Observe the "No CUDA support" error in logs and the fallback to software encoding (libx264).
4. Run "Steam Runtime Diagnostics" and note that libnvidia-encode is missing from the mapped libraries section.

[smcv]

Unfortunately we have to capture the Nvidia libraries individually, rather than being able to take libnvidia-*, because a few of them are specifically things we don't want (capturing libraries with a GTK dependency would defeat the purpose of the container). Perhaps libnvidia-encode.so.1 is not on our list but should be.

It seems to only depend on libnvcuvid.so.1 plus glibc, so hopefully that won't cause any problems.

[smcv]

Remote Play from this NVIDIA host fails to initialise hardware encoding. The streaming_log.txt reports NVENC - No CUDA support

Am I correct to think that this is Remote Play with the Nvidia machine as the streaming server (the one that runs the actual game), using some non-Nvidia machine (e.g. Steam Deck) as the streaming client?

With a similar setup on a test machine, I'm seeing that on the Nvidia machine (Ubuntu 24.04 with Nvidia driver 580 in my case), libnvidia-encode.so.1 is captured: I get /proc/$pid/root/overrides/lib/x86_64-linux-gnu/libnvidia-encode.so.1 -> /run/host/usr/lib/x86_64-linux-gnu/libnvidia-encode.so.580.126.09, for a $pid that is the process ID of my game.

Perhaps libnvidia-encode.so.1 is not on our list but should be.

In fact it is already on the list, so the relevant question is: why is it not captured on your system? I'll see what happens if I boot the Nvidia machine into Arch...

If you can collect a SLR log with STEAM_LINUX_RUNTIME_VERBOSE=1 in the environment, that might have useful information.

attempts to fall back to VAAPI, which also fails with va_openDriver() returns -1

It is expected that fallback to VA-API won't normally work on Nvidia systems. There is an unofficial VA-API driver for Nvidia systems, https://github.com/elFarto/nvidia-vaapi-driver, but we can't safely use that in our container even if you have it installed, because it has too many dependencies (GStreamer!).

[Reverberation1]

@smcv Thank you for looking into this!

Yes, you are correct. The NVIDIA machine (Manjaro, 590.48.01) is the streaming server/host, and a Steam Deck is acting as the client.

Here is the verbose SLR Log: Link.

[smcv]

In the attached Steam Runtime Diagnostics, libcuda.so.1 is successfully mapped into overrides, but libnvidia-encode.so.1 is completely absent from the container overrides list.

This doesn't seem to be true any more in the verbose log:

<7>18:01:56.614775: pressure-vessel-wrap[1237840]: D: overrides/lib/x86_64-linux-gnu/libnvidia-encode.so.1 points to container-side path /run/host/usr/lib/libnvidia-encode.so.590.48.01

[smcv]

/run/host/usr is your host system's /usr, so that one should work, I think.

[smcv]

ldconfig inside your container also seems to be finding the library successfully:

<7>	libnvidia-encode.so.1 (libc6,x86-64) => /usr/lib/pressure-vessel/overrides/lib/x86_64-linux-gnu/libnvidia-encode.so.1
<7>	libnvidia-encode.so.1 (libc6) => /usr/lib/pressure-vessel/overrides/lib/i386-linux-gnu/libnvidia-encode.so.1

[Reverberation1]

Strange that both versions of libnvidia-encode.so.1 are found correctly. Perhaps in the initialisation there are missing sibling dependencies required by the Nvidia driver overrides?

I don't wish to jump the gun on saying that specific files are missing as I am really not sure if they are required, but I noticed a few libraries on my host like libnvidia-sandboxutils.so.1 that don't appear to be captured in the overrides. Could be a complete red herring.

[smcv]

I can reproduce NVENC - No CUDA support on Arch with Nvidia 590 (unlike Ubuntu 24.04 with Nvidia 580), so this is either a regression with the 590 driver, or an OS-specific issue. My first guess would be that it's more likely to be a regression with the 590 driver.

[smcv]

I noticed a few libraries on my host like libnvidia-sandboxutils.so.1 that don't appear to be captured in the overrides

Possibly relevant, yes. On my test system I see

libnvidia-egl-wayland2.so.1
libnvidia-egl-xcb.so.1
libnvidia-egl-xlib.so.1
libnvidia-nvvm70.so.4
libnvidia-present.so.590.48.01
libnvidia-sandboxutils.so.1
libnvidia-tileiras.so.590.48.01
libnvidia-vksc-core.so.1

in addition to the ones we already know about.

If a library that we already known about has an ELF hard dependency (DT_NEEDED) on one of these, then we'd pick it up automatically, but if it will dlopen() them at runtime, we can't track that automatically.

[smcv]

Another possibility is that the Nvidia driver wants to be able to load the dri_gbm.so provided by Mesa, which pressure-vessel isn't yet aware of (#797, already being worked on).

[Reverberation1]

@smcv Thanks for the update. It’s interesting that it's specific to the 590 drivers.

I'll stay tuned for the GBM fix and can test any beta builds you need.

[smcv]

Unfortunately adding dri_gbm.so to the container didn't solve this for me, and neither did adding more Nvidia libraries to the container or combining both changes, so the reason that Steam is reporting NVENC - No CUDA support must presumably be something else.

[smcv]

Actually no, my test machine's GPU is sufficiently old that https://github.com/NVIDIA/open-gpu-kernel-modules doesn't support it, so those test results are inconclusive.

@Reverberation1, to start with, please could you try testing your theory about adding more Nvidia libraries to the container? To do this, delete the steamapps/common/SteamLinuxRuntime_sniper/pressure-vessel/ directory and replace it with the result of unpacking https://gitlab.steamos.cloud/steamrt/steam-runtime-tools/-/jobs/2162713/artifacts/raw/_build/pressure-vessel-bin.tar.gz. (Note to self, this is steam-runtime-tools!925 v1.)

The GBM change isn't quite ready yet, but when it is, we can also try with that, or with the combination of both.

[Reverberation1]

@smcv I tested the custom build. Unfortunately, no dice on the theory. The streaming_log.txt still reports NVENC - No CUDA support.

I’ve verified the following inside the container shell:

• Device Nodes: /dev/nvidia-uvm is present and correctly mapped.
• Overrides: The new build successfully captured and mapped the additional libraries, including libnvidia-sandboxutils and libnvidia-tileiras.