mirror of
https://github.com/games-on-whales/wolf.git
synced 2026-10-15 21:12:08 +00:00
[GH-ISSUE #350] GStreamer fails to link all symbols with CUDA > 11.0 #240
Labels
No labels
🧠 1 - 🤖 999
AMD
bug
bug
cannot reproduce
documentation
duplicate
easy
enhancement
enhancement
enhancement
fixed?
fixed?
good first issue
hard
help wanted
Intel
invalid
LXC
medium
moonlight-protocol
Multi GPU
nixos
not a bug
nvidia
pull-request
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
games-on-whales/wolf#240
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @LizardLad on GitHub (Feb 5, 2026).
Original GitHub issue: https://github.com/games-on-whales/wolf/issues/350
Hi team,
I've just tried using the instructions for running the NVIDIA containers, both container toolkit and manual. The container toolkit method seems to fail to see the NVIDIA card (which might be to do with the driver version in the image).
To work around this I tried the manual version which mostly worked. The first issue I came across was wolf finding the Intel iGPU first with libva, but eventually it decides to use the nvidia device. To fix this I pass only the /dev/dri/renderD129 device. Otherwise this is the compose I'm using.
My NVIDIA driver version is 590.48.01 with CUDA Version 13.1. When I built the volume it grabbed the right version but when I run the container it seems GStreamer has a mismatch with libnvrtc. It can't find the symbol nvrtcGetCUBINSize. I then found that /usr/local/nvidia/lib/libnvrtc.so.11.0 and /usr/local/nvidia/lib/libnvtrc-builtins.so.11.0, which appear to be CUDA 11. I think that's where the issue is but I'm not sure how to fix it. I couldn't find where it gets pulled into the image.
Even with that issue though I can connect through Moonlight and access the Wolf menu. I then launched the Steam container and then disconnected from the stream. When re-attaching to the stream though it seemed to crash GStreamer. Here's the log for that session.
If I can help in anyway please let me know :)
Thanks in advance for your help and thank you for the work you have put into this project.
@ABeltramo commented on GitHub (Feb 5, 2026):
Re
nvrtcGetCUBINSizethat is an absolutely normal warning, we all get it but it's nothing to be worried about; the important thing is:which means that we can use the Nvidia HW encoder.
As for the iGPU being picked up first, that's documented in our docs 😉
Now, to get to the bottom of what the issue is, in your
compose.ymlcan you add the env variableWOLF_LOG_LEVEL=DEBUGand grab the logs again?Also, have you checked that
nvidia-drmis loaded withAnd possibly add the output of
nvidia-smitoo?@LizardLad commented on GitHub (Feb 5, 2026):
Thank you for the quick reply! I didn't spot the multi-GPU part of the docs. It's also good to know that the GStreamer warnings aren't actually an issue :)
I can confirm that nvidia-drm is loaded and in my kernel modules list I have nouveau blacklisted and
options nvidia_drm modeset=1.Output of
nvidia-smion the hostOutput of
nvidia-smifrom the containerThe steps I use to replicate this are:
docker-compose upLogs with debug level:
@ABeltramo commented on GitHub (Feb 5, 2026):
That is odd, is there any reason why you are specifically requesting
H.264which isn't the default? Which Moonlight client are you using and have you changed any of the settings from the default?@LizardLad commented on GitHub (Feb 10, 2026):
Ok, I've been trying a couple things and it does seem to be that H.264 is the culprit.
I'm using moonlight-qt and I was using it on a laptop running stock KDE Manjaro (as far as the graphics stack and kernel is concerned) with an Intel i7-1065G7. I installed it through the official repositories and I didn't take any notice of it complaining about no hardware acceleration.
I hadn't changed any settings but because it thought there was no hardware acceleration it was defaulting to H.264 (I guess for software decode efficiency or something).
To test this I switched it to force HEVC (H.256) and it worked exactly as I would have expected. I can now open a stream, disconnect, and reconnect perfectly.
I also tested that forcing H.264 wouldn't even allow an initial connection to be made.
I thought it's a little odd that H.264 doesn't work though, given it says it has hardware accelerated encoding for it?
Either way it doesn't stop me from doing anything at the moment. Thank you for your help!
@JBailes commented on GitHub (May 12, 2026):
This has been fixed with recent merges!