ValveSoftware
Latest steam-runtime (soldier_0.20210126.1) upgrade breaks games and primusrun integration
Games were working fine before the upgrade. Actually, I had to use "previous version" in steam to get it to work, but with this upgrade I can't downgrade (and I didn't back up the version that did work, nor do I know how to compile previous versions; this is all to new for a bunch of us). I've browsed around the issues here and did't quite find my issue, except for https://github.com/ValveSoftware/steam-runtime/issues/312, and it's not quite the issue.
Games worked perfectly before, I didn't even jot down the version thinking it would run stable for ever... now I know better, rookie mistake. I use a lenovo y520 with Debian (Parrot OS) and I run everything within a firejail container, which worked perfectly until this last set of upgrades. I'm using steam's beta version and have tried all proton versions 5.13 and glorious eggroll versions. The error so far is: pressure-vessel-wrap[1020]: 'TEXTDOMAIN=steam' pressure-vessel-wrap[1020]: Replacing self with bwrap... ### Maybe this is the issue? ERROR: ld.so: object '/home/localhost/.steam/debian-installation/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. ERROR: ld.so: object '/home/localhost/.steam/debian-installation/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. primus: fatal: failed to connect to Bumblebee daemon: No such file or directory Game removed: AppID 1172380 "", ProcID 1018
-- As suggested in https://github.com/ValveSoftware/steam-runtime/issues/312#issuecomment-741785479. I ran the command you suggested and added primusrun:
PRESSURE_VESSEL_VERBOSE=1 primusrun ./run -- steam-runtime-system-info --verbose 2>&1 | tee container.log
}, "glx/gl" : { "renderer" : "Mesa Intel(R) HD Graphics 630 (KBL GT2)", "version" : "4.6 (Compatibility Profile) Mesa 20.3.4", "library-vendor" : "glvnd" }, "egl_x11/gl" : { "renderer" : "Mesa Intel(R) HD Graphics 630 (KBL GT2)", "version" : "4.6 (Compatibility Profile) Mesa 20.3.4", "library-vendor" : "glvnd" }, "egl_x11/glesv2" : { "renderer" : "Mesa Intel(R) HD Graphics 630 (KBL GT2)", "version" : "OpenGL ES 3.2 Mesa 20.3.4", "library-vendor" : "glvnd" }
It's not recognizing my nvidia 1050.... Drivers: nvidia-driver 460.39-1; bumblebee-nvidia 3.2.1-27;
I used to be able to run everything smoothly, nothing in my config has changed, except for the latest runtime upgrade. I've tried mixing other pressure-vessel verisions (because have no idea how to get the whole steam-runtime downgraded) to no avail. I've reinstalled, upgraded to beta, downgraded to the previous version... nothing has worked. Please let me know if I can provide further details, and I appreaciate the efforts to bring us gaming to our linux world... for real.
tl;dr: you have several layers of extra complexity (multiple GPUs, an uncommon OS, firejail) on top of the considerable amount of complexity inherent in pressure-vessel and Proton, so I'm not really surprised this is going wrong.
I'm going to need quite a lot more information, and anything you can do to reduce the number of layers of complexity involved will probably help us to figure out what is wrong sooner.
It would be useful to check that a "known-good" game has the behaviour that you report. I often use Floating Point and Life is Strange, episode 1 for this purpose, because they're available at no cost (so anyone can install them), they aren't particularly big, they'll run on relatively weak hardware (especially Floating Point), they are single-player (so there's no anti-cheating mechanism getting in the way), and they have a native Linux version that can be used for comparison. By default Steam will install the native Linux version for these games, but if you use Properties -> Compatibility -> Force the use of a specific Steam Play compatibility tool and select Proton 5.13, Steam will install the Windows version and run it under Proton instead.
Latest steam-runtime (soldier_0.20210126.1)
This is not the latest. The default version is currently 0.20210208.0, and the beta version is 0.20210217.0.
If you find that the default version has a regression (default version does not work but previous_release branch does), please report that as a bug before it is too late - otherwise we will not know that anything is wrong, and will continue to make regular releases, each of which will overwrite the previous_release.
I run everything within a firejail container
This is not necessarily a configuration that we can support, because firejail can arbitrarily change our view of the host system, breaking our assumptions. There is an unlimited number of possible firejail combinations, some of which will work and some of which will break things.
What does Steam have access to in your firejail configuration, and what does it not have access to? If there is a configuration file or command-line options that set up the firejail configuration, what are they?
Is the bug reproducible when not running in firejail? If you don't want to run Steam as your primary user ID for privilege separation, I can understand that - a way to get privilege separation that is less likely to break things would be to create a new, unprivileged user account, then run Steam while logged in as that user. (That's what I do myself, in fact.)
Debian (Parrot OS)
Which is it? Debian, or Parrot OS?
If Parrot OS is a Debian derivative, which branch of Debian is it based on?
Replacing self with bwrap... ### Maybe this is the issue?
No, this is intended. This is how pressure-vessel works: it sets up a (very long) bwrap command-line, and then replaces itself with that bwrap command using execve().
primus: fatal: failed to connect to Bumblebee daemon: No such file or directory
I suspect this might be happening because pressure-vessel has had some bugs fixed, and is now loading Vulkan layers that previously didn't work. Previously it might well have just not been loading whatever Primus component (Vulkan layer?) was meant to be included, which meant it wasn't an immediate problem that Primus wouldn't work, because it wasn't in use anyway.
Multi-GPU systems are difficult to deal with, because they use various mechanisms to force games onto a particular GPU/driver combination by injecting arbitrary code into the game's process, which is rather fragile. The exact code path that is required is not at all obvious, and varies according to the exact configuration of your system. Many of the modules used to select a GPU are vendor-specific (the Mesa device selection layer, and its equivalents in recent NVIDIA and AMD drivers), and if more than one is active, they can fight. Third-party addons like Primus and Bumblebee increase the complexity of the overall system further by trying to overrule the vendor drivers, to a point where a small change to the overall system can lead to completely different results.
pressure-vessel originally didn't support Vulkan layers at all, and we have been gradually improving it to match the behaviour of the host system more closely. In your case, because you're using firejail, what we think is the host system is really the firejail container, which introduces extra variables.
Proton games make this even worse, because the game thinks it's running on Windows and using DirectX, but it's really running on Linux (via a modified version of Wine) and probably using DXVK.
I don't have access to a multiple-GPU test system that is new enough to have working Vulkan, so I'm completely relying on information from users for this.
As a starting point, please undo whatever workarounds you have applied. It's probably best if you move the SteamLinuxRuntime_soldier directory out of the way, and use Properties -> Local Files -> Verify integrity of game files in your Steam library to re-download it. Having done that, please provide the full system information (Help -> System Information) and the pressure-vessel log file as attachments or Github gists, as described here: https://github.com/ValveSoftware/steam-runtime/blob/master/doc/reporting-steamlinuxruntime-bugs.md#essential-information. Please do that with the client_beta version if you can, or with the default (non-beta) version. Newer versions have better diagnostic information that will tell us more about your multiple GPUs and exactly how their drivers and layers are set up, which is why we would prefer to get this from a version that is as new as possible. Please do this first, before attempting workarounds or downgrades, otherwise I will never know what is wrong and it will not be possible to fix it permanently.
After doing that, if you are confident with Linux shell commands, you could try rolling back to an older version of pressure-vessel while leaving the rest of the runtime the same. To do that, look in https://repo.steampowered.com/steamrt-images-scout/snapshots/ (yes, I know the URL says scout rather than soldier, but pressure-vessel is compiled in the scout environment) for a version that is about the same age as the oldest version that was working successfully for you. Each of the numbered subdirectories has a tar archive named pressure-vessel.tar.gz. Delete the SteamLinuxRuntime_soldier/pressure-vessel/ directory and replace it with the result of unpacking that archive, then try to run a game. Keep going back to an older version or going forward to a newer version until you find the newest version that works for you. When you have found it, please capture the Help -> System Information again, and provide that, together with the version number of pressure-vessel that you were using (you can find this by running SteamLinuxRuntime_soldier/pressure-vessel/bin/pressure-vessel-wrap --version or looking in SteamLinuxRuntime_soldier/pressure-vessel/metadata/VERSION.txt).
First off, thank you for taking the time to browse around the issue. I completely understand the hardships and difficulties to bring us gaming to our linux world. I still can't believe I can finally play on my linux machine.
I apologize, i was trying out the most recent update's "previous_version", which (according SteamLinuxRuntime_soldier/var) is
Latest steam-runtime (soldier_0.20210126.1)
I suspect this might be happening because pressure-vessel has had some bugs fixed, and is now loading Vulkan layers that previously didn't work. Previously it might well have just not been loading whatever Primus component (Vulkan layer?) was meant to be included, which meant it wasn't an immediate problem that Primus wouldn't work, because it wasn't in use anyway.
I think you might be on to something... Because, as you suggested, I downgraded the vessel to https://repo.steampowered.com/steamrt-images-scout/snapshots/0.20201104.0/pressure-vessel-bin.tar.gz and my games are working again! I deleted all the SteamLinuxRuntime_soldier directory and verified all files to the "previous_version" using 04-11-2020 pressure-vessel and everything is working again (can I completely backup this config?? I'm worried about some symlinks i might need to back up as well)
I have been using steam beta for a while and all my games run in 5.13-xx and glorious eggrolls' latest versions based on 5.13-xx. My firejail config is quite simple: I run everything with a private directory, so it doesn't write something outside this (almost like a restricted user) and some additional restrictions which I'll share here. However, when I run into issues I always run it without a firejail profile to look for bugs (either on the firejail profile or my steam config). I know this adds much more complexity and your solution might be easier (creating a new restricted user), I'll give it a shot. Btw, Parrot is basically Debian testing.
Ok, so I tried this with 0.20210208.0 and the pressure-vessel (https://repo.steampowered.com/steamrt-images-scout/snapshots/0.20201104.0/pressure-vessel-bin.tar.gz) I mentioned above and it worked too!!!
SteamLinuxRuntime_soldier/pressure-vessel/bin/pressure-vessel-wrap --version
gave me this: Package: pressure-vessel Version: 0.20201022.0+srt1
I got the system information and my gpu (GTX 1050) did not appear, this might be because i run each game with the "primusrun %command%" but not steam as a whole, so keep that in mind. Within the game, however, the card is identified correctly (2gb vram --it sucks I know but it gets the job done). Here's the link to the system information: https://crypt.parrot.sh/code/#/2/code/view/shOyWb8sFuE-qQ1aDbtr5yqa18Jbjvq6Kc5yTFtvzJU/TzEsIgpPNiYnraYBdh4uExh9ewogNgyZpbl4hKw3e77TWT8SXxSglZAkATMEB-Nsgs2-olAgEgQaKP29aq8EaA/ (this will self-destruct, there's a lot of information I can't follow up on and don't know if it's safe to make it widely available, if need be I can always make another link) and this is the link to the firejail config (which has been tweaked to work on my machine and config, I haven't tested this elsewhere): https://crypt.parrot.sh/pad/#/2/pad/view/TQ3JW5fNlt722A2-ZOdYjg5d0c4dqMRRJVx2qcHTwMw/mG39ASu1Ikk09d-j6bjVPf1ZmVOUtKssnh0R+cCYTo5EGnl6cko-7lWUtgW3Cl522AInNimaugO6+w603i+dNw/ . Keep in mind that I also run this with --private=/path/dir to make a private home for it, somewhat like a limited user.
Thank you so much for your help. this workaround can help me play my games once again for the time being. Please let me know if I can provide further information to help solve this issue for myself and others.
[working version was] 0.20201022.0+srt1
This is probably a regression between 0.20201022.0 (last good) and 0.20201124.0 (first bad). 0.20201124.0's changelog says: pressure-vessel: Add support for Vulkan layers. So in the older version, it probably works for you "by mistake" because no Vulkan layers are loaded...
Here's the link to the system information
I've saved a copy of this locally (other Steam Runtime developers: let me know if you need a copy) and will investigate it later. (Note to self: issue372.log)
don't know if it's safe to make it widely available
It's meant to be suitable for publishing as a gist or on a pastebin. Usually the most sensitive thing in it is your username.
The quick tl;dr analysis is that your Vulkan driver seems to be broken: we can't load Vulkan drivers, at all, even without being in the container. Native Linux games that use Vulkan would probably also not work.
Thanks for the quick response. I didn't know it could be widely shared, I'm sorry.
I have the following installed: vulkan-tools/rolling,now 1.2.162.0+dfsg1-1 amd64 [installed,automatic] vulkan-utils/now 1.2.141.0+dfsg1-1 all [installed,local] primus-vk/rolling,rolling,now 1.6.1-1 all [installed] primus-vk-nvidia/rolling,now 1.6.1-1 amd64 [installed] nvidia-vulkan-common/rolling,now 460.39-1 amd64 [installed] nvidia-primus-vk-wrapper/rolling,now 1.6.1-1 amd64 [installed,automatic] nvidia-primus-vk-common/rolling,now 1.6.1-1 amd64 [installed] mesa-vulkan-drivers/rolling,now 20.3.4-1 amd64 [installed] (This one?*) libvulkan1/rolling,now 1.2.162.0-1 amd64 [installed] libvulkan-dev/rolling,now 1.2.162.0-1 amd64 [installed] libvkd3d1/rolling,now 1.1-5 amd64 [installed,automatic]
and installed vulkan-validationlayers/rolling 1.2.162.0-1 amd64 (but this didn't do anything) I'm missing these two: libvkd3d-dev/rolling 1.1-5 amd64 Direct3D 12 to Vulkan translation - development files
libvkd3d-utils1/rolling 1.1-5 amd64 Direct3D 12 to Vulkan translation - utilities library
Would any of these work or is it an issue with the driver itself? Is there a specific path for these drivers? I can check it out on my machine... maybe there's an error on my config. Let me know if I can check anything else on my system.
Hello @samsamros, can you test if adding NODEVICE_SELECT=1 to your environment has an effect? You can add it before %command% in a game's launch options.
@kisak-valve I reverted to the original pressure-vessel in version (0.20210208.0) and added NODEVICE_SELECT=1 primusrun %command% but it didn't work... same error as before:
Adding process 3716 for game ID 1172380 ERROR: ld.so: object '/home/localhost/.steam/debian-installation/ubuntu12_32/gameoverlayrenderer.so' from LD_PRELOAD cannot be preloaded (wrong ELF class: ELFCLASS32): ignored. primus: fatal: failed to connect to Bumblebee daemon: No such file or directory Game removed: AppID 1172380 "", ProcID 3694 Uploaded AppInterfaceStats to Steam Exiting app 1172380 No cached sticky mapping in ActivateActionSet.
We already know that pressure-vessel has difficulty with multi-GPU systems at the best of times (see https://github.com/ValveSoftware/steam-runtime/blob/master/doc/steamlinuxruntime-known-issues.md#vulkan-layers-and-driverdevice-selection) so you're lucky it worked as well as it did. Multi-GPU Vulkan is complicated, pressure-vessel is complicated, and Proton/DXVK is complicated, so when the three collide, there are lots of things that can go wrong. Firejail adds an extra layer of complexity on top of this, and so does Primus/Bumblebee.
Our graphics stack expert tells me that Primus/Bumblebee are considered to be problematic, and the preferred way to handle multiple-GPU systems on modern distributions is with "PRIME Render Offload" (e.g. see https://wiki.debian.org/NVIDIA%20Optimus#Using_NVIDIA_PRIME_Render_Offload and http://us.download.nvidia.com/XFree86/Linux-x86_64/460.56/README/primerenderoffload.html for NVIDIA).
can I completely backup this config?? I'm worried about some symlinks i might need to back up as well
Obviously I can't support older versions or fix bugs in them, so this is entirely at your own risk.
Keeping a copy of an entire known-working SteamLinuxRuntime_soldier directory is going to be the best way to preserve a version that happens to work on your system. Overwriting the pressure-vessel directory is usually enough, but sometimes there are changes that affect both pressure-vessel itself and the wrapper scripts around it, for which they need to be upgraded in lockstep - and I'm expecting to make one of those changes relatively soon.
primus: fatal: failed to connect to Bumblebee daemon: No such file or directory
You might find that it helps to run Steam with the environment variable PRESSURE_VESSEL_FILESYSTEMS_RW=/run/bumblebee.socket. It's more reliable to put things like this into the environment for the whole of Steam rather than putting them in Launch Options, because the Launch Options are not taken into account for the "setup commands" that run before a Proton game, and obviously can't be taken into account for Help -> System Information.
If you can confirm that it helps, we can make pressure-vessel do the equivalent of that automatically, but I'd want confirmation that this workaround is successful first.
i run each game with the "primusrun %command%" but not steam as a whole
Running all of Steam through primusrun might be more reliable, and it would be useful to be able to look at the System Information having done this.
Hello! I browsed around your suggestions. I wasn't aware the official offload was already available. I had been using bumblebee for a very long time as it was the only software avaialable.
So I reverted everything, including pressure-vessel:
Package: pressure-vessel Version: 0.20210203.0+srt1
And ran the offload method at the game level:
__NV_PRIME_RENDER_OFFLOAD=1 gamemoderun %command%
(I haven't uninstalled bumblebee yet, Im trying to figure out this native Nvidia offload first)
My games launched, at least the ones I've tested. I still have to check out performance and other stuff, but that's not the issue at hand right here. I also gave this a shot
You might find that it helps to run Steam with the environment variable PRESSURE_VESSEL_FILESYSTEMS_RW=/run/bumblebee.socket. It's more reliable to put things like this into the environment for the whole of Steam rather than putting them in Launch Options, because the Launch Options are not taken into account for the "setup commands" that run before a Proton game, and obviously can't be taken into account for Help -> System Information.`
Halo MCC broke but ran on __NV_PRIME_RENDER_OFFLOAD=1 Jedi Fallen Order ran on __NV_PRIME_RENDER_OFFLOAD=1 and PRESSURE_VESSEL_FILESYSTEMS_RW=/run/bumblebee.socket primusrun %command% GTA V broke with this method but ran with __NV_PRIME_RENDER_OFFLOAD=1
I will continue to run games with both setups and checkout errors, bugs and performance... but I'm guessing the offload method might be more stable and efficient performance-wise for what I've read...
Regarding
Obviously I can't support older versions or fix bugs in them, so this is entirely at your own risk.
Of course, I would never take away your time to maintain older versions, especially for an error that might be affecting a handful of systems. I would have just kept it for the time being until a fix or a more adequate workaround --such as this one-- was available. You guys are doing great work already with this whole compatibility framework!
I'm currently testing
Running all of Steam through primusrun might be more reliable, and it would be useful to be able to look at the System Information having done this.
and will get back to you guys with more info regarding the offload and PRESSURE_VESSEL_FILESYSTEMS_RW=/run/bumblebee.socket methods. If you agree, I'll keep the issue open to send further feedback as I run and play my games, but I'm guessing the __NV_PRIME_RENDER_OFFLOAD=1 might be the solution...
According to the debian website I might need to uninstall bumblebee to get this method up and running correctly, can anyone else confirm this? My system is working with both, but I might remove bumblebee entirely if this proves to be energy efficient and stable.
Many thanks devs and mods
There are several things going on here.
If you are trying to use Primus (primusrun), then PRESSURE_VESSEL_FILESYSTEMS_RW=/run/bumblebee.socket might be necessary. If that works, please tell us (as clearly as possible!) that it is helpful, so that we can make pressure-vessel do this automatically.
If you are trying to use Prime offloading, then __NV_PRIME_RENDER_OFFLOAD=1 is what activates that.
Those two mechanisms are orthogonal. You can use either one or the other, but probably not both: using both primusrun and __NV_PRIME_RENDER_OFFLOAD=1 at the same time is probably not right.
Hi @smcv I used each individually and exlusively on each of these games. Using PRESSURE_VESSEL_FILESYSTEMS_RW=/run/bumblebee.socket primusrun %command% was done so individually without __NV_PRIME_RENDER_OFFLOAD=1 and viceversa.
I tested these with the following games with these results:
Halo MCC broke but ran on __NV_PRIME_RENDER_OFFLOAD=1 Jedi Fallen Order ran on __NV_PRIME_RENDER_OFFLOAD=1 and PRESSURE_VESSEL_FILESYSTEMS_RW=/run/bumblebee.socket primusrun %command% Only this one worked GTA V broke with this method but ran with __NV_PRIME_RENDER_OFFLOAD=1
The primus: fatal: failed to connect to Bumblebee daemon: No such file or directory error was gone in all of the games tested with PRESSURE_VESSEL_FILESYSTEMS_RW=/run/bumblebee.socket, but other errors showed up. Halo MCC and GTA V didn't open at all, while Jedi Fallen Order opened without any problems. I would suggest adding this line to run automatically in pressure-vessel because the error is gone, but there are other erros that jumped. So far, Fallen Order has worked using either __NV_PRIME_RENDER_OFFLOAD=1 %command% or PRESSURE_VESSEL_FILESYSTEMS_RW=/run/bumblebee.socket primusrun %command%, but Halo MCC and GTA V had some other errors and didn't open with PRESSURE_VESSEL_FILESYSTEMS_RW=/run/bumblebee.socket primusrun %command%, but did open using solely __NV_PRIME_RENDER_OFFLOAD=1 %command%
I did the same procedure but with __NV_PRIME_RENDER_OFFLOAD=1 and excluded PRESSURE_VESSEL_FILESYSTEMS_RW=/run/bumblebee.socket primusrun altogether. I didn't run it with primusrun.
As such:
__NV_PRIME_RENDER_OFFLOAD=1 %command% # no primusrun was run for this test
The "primus: fatal: failed to connect to Bumblebee daemon: No such file or directory" error was gone in all of the games tested with
PRESSURE_VESSEL_FILESYSTEMS_RW=/run/bumblebee.socket, but other errors showed up. [...] I would suggest adding this line to run automatically in pressure-vessel because the error is gone
pressure-vessel 0.20210305.0 (present in today's soldier 0.20210309.0 beta) automatically does the equivalent of this. I realise this doesn't completely solve the problem you had, but it should help a bit.
It sounds as though __NV_PRIME_RENDER_OFFLOAD=1 is the better long-term solution. I don't think pressure-vessel should be setting this itself, but perhaps some other layer should. Configuring your NVIDIA drivers is not really pressure-vessel's job, and I don't want to risk breaking previously working systems - for example if they have a working Intel or AMD GPU, and non-functional NVIDIA drivers left over from an older hardware configuration.
If we give steam.desktop the PrefersNonDefaultGPU=true setting as requested in https://github.com/ValveSoftware/steam-for-linux/issues/7089, then that should also help this.
@smcv Thank you for all the help!
I think this is a great improvement and would advise all users who can to use the __NV_PRIME_RENDER_OFFLOAD=1 solution instead of bumblebee.
I don't think pressure-vessel should be setting this itself, but perhaps some other layer should. Configuring your NVIDIA drivers is not really pressure-vessel's job, and I don't want to risk breaking previously working systems - for example if they have a working Intel or AMD GPU, and non-functional NVIDIA drivers left over from an older hardware configuration.
I couldn't agree more. I think this could cause more problems rather than solving them, if users are already using primusrun %command%, it could easily be changed to the offload method by the user when needed.
Please let me know if I can continue to provide information about the issue, I'd be glad to help.
The list of known issues now recommends "NVIDIA-on-demand" mode and __NV_PRIME_RENDER_OFFLOAD=1 for NVIDIA Optimus systems like yours, and the analogous DRI_PRIME=1 for AMD Switchable Graphics.
If we give
steam.desktopthePrefersNonDefaultGPU=truesetting as requested in ValveSoftware/steam-for-linux#7089, then that should also help this.
This has not been done, but we're evaluating that as a possible future change in steam-launcher.
If you want to try this out (at your own risk), you could put your system in "NVIDIA-on-demand" mode, then edit /usr/share/applications/steam.desktop so it starts with:
[Desktop Entry]
PrefersNonDefaultGPU=true
X-KDE-RunOnDiscreteGpu=true
to make Steam and all its child processes prefer to use the NVIDIA GPU. I don't know which desktop environment or desktop environment version you're using, or whether it supports this feature. GNOME does (since 3.38), and KDE Plasma Desktop does (since 5.30 I think?). I don't know about Cinnamon or other desktops.
If your desktop environment has this feature, this should hopefully make it unnecessary to set the environment variables yourself.
If your desktop environment does not have this feature, this change won't do anything useful, but is hopefully harmless, and might help in a future version.
Quick update!! I've been using the offload method for a month now... trying to at least. All games succesfully launch, but they all run with massive stuttering and lag. I decided to reinstall bumblebee to see if the new driver upgrade did anything, which it did not. Only Jedi Fallen Order launched using bumblebee and it actually ran flawlessly, with absolutely no tearing and even better performance than with the offload method. However, other games did not even launch under bumblebee. I've changed the config to see if that helped to no avail.
I added these lines in steam.desktop as suggested and everything ended up pretty much the same, didn't help, but also didn't cause any trouble. I've tried to add the PRIME synchronization option also to no avail... according to https://bbs.archlinux.org/viewtopic.php?id=258265 this doesnt work, but according to nvidia it does.... but cannot add it.
Although this is another issue, I thought it would be important to report it here so that other users facing this issue might stumble upon it. All games have massive stuttering, tearing and lag, previous frames pop up in new frames and games are basically unplayable. I've tried opening everything in compton via openbox and absolutely no settings have got this working. However, Jedi Fallen Order (the only game running in bumblebee) ran smoothly under primusrun and had massive lag and stuttering under the Prime offload method. I currently run my games using:
__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia-current __GL_SYNC_TO_VBLANK=1 __GL_SYNC_DISPLAY_DEVICE=eDP-1 DPAU_NVIDIA_SYNC_DISPLAY_DEVICE=eDP-1 %command%
I've tried most combinations I've stumbled upon online and none seem to help get games back to normal.
Have you guys had any luck figuring out how to get bumblebee back?
Could you guide me towards figuring out this massive tearing, stuttering and lag problem? I know this might not be related to the first issue but maybe I can find guidance over here.
Quick edit:
As a last resort I turned off compton's vsync option in ./usr/bin/marco-compton (I'm usign Mate btw) and used glx as a backend instead of xrender and lag and stutter have stopped by 90% at least... far from working flawless, but good enough to be playable.
Compton settings:
compton
--config /dev/null
--backend ${BACKEND}
# --vsync ${VSYNC} \ # This is commented out
--detect-rounded-corners
--detect-client-leader
--detect-transient
--detect-client-opacity
--paint-on-overlay
--glx-no-stencil
--glx-swap-method undefined
--unredir-if-possible
--unredir-if-possible-exclude "class_g = 'Mate-screensaver'"
--inactive-opacity-override
--mark-wmwin-focused
--mark-ovredir-focused
--use-ewmh-active-win
-r 10 -o 0.225 -l -12 -t -12
-c -C -G
--fading
--fade-delta=4
--fade-in-step=0.03
--fade-out-step=0.03
--shadow-exclude "! name~=''"
--shadow-exclude "name = 'Notification'"
--shadow-exclude "name = 'Plank'"
--shadow-exclude "name = 'Docky'"
--shadow-exclude "name = 'Kupfer'"
--shadow-exclude "name *= 'compton'"
--shadow-exclude "class_g = 'albert'"
--shadow-exclude "class_g = 'Conky'"
--shadow-exclude "class_g = 'Kupfer'"
--shadow-exclude "class_g = 'Synapse'"
--shadow-exclude "class_g ?= 'Notify-osd'"
--shadow-exclude "class_g ?= 'Cairo-dock'"
--shadow-exclude "class_g = 'Cairo-clock'"
--shadow-exclude "_GTK_FRAME_EXTENTS@:c
@samsamros Probably it should be wise to launch Steam client itself with __NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia __VK_LAYER_NV_optimus=NVIDIA_only to reduce your stuttering and lag.
Because currently , Steam client sees your igpu as selected adapter and Fossilize system ( compiling shaders against your gpu, downloading pre compiled shaders for your gpu if available ) works against your igpu. So without launching Steam client that way you are missing a great service.
@Leopard1907 thank your for your suggestion... This did improve with some games, but some (like fallen order) still don't work as expected.
You may want to try the fixes I applied on my Manjaro system: https://github.com/ValveSoftware/Proton/issues/3189#issuecomment-1177829820
