Bug 6713

Should I report that the same issue persists? The weirdest thing about it is how typing "steam" on a Terminal and pressing enter will just work, but launching from Gnome simply doesn't. The behaviour is the same as previously reported.

I will add that the only way to launch Steam after trying and failing to do so via Gnome is by killing the process. As in "top | grep steam" and the kill xwyz process. After this, launching from Terminal becomes possible again.

after upgrade to Fedora 38 , my first run doesn't worked .

I killed all steam processes 
ps -ef | grep steam 

kill -9 573043

I started steam again and it worked

As per various threads such as https://forums.linuxmint.com/viewtopic.php?t=400351 and manually mending this issue for my own install, it appears that steam is having issues (at least between two GPUs running with mesa-type drivers) that Steam is attempting to launch on the secondary GPU and immediately failing for some reason. The reason Steam is attempting to target running on the secondary GPU is due to the configuration line { PrefersNonDefaultGPU=true } in the .desktop file included in the package. As per the Linux Mint forums post, simply cloning the system .desktop entry into the user and changing the line to false will allow Steam to launch fine. As in the past, one can still pass DRI_PRIME, prime-run, and vulkan icd overrides as needed to games.

Obviously the core issue is with Steam itself, but a quick patch to the .desktop file associated with the package should probably be changed to a more compatible default until the issue is resolved properly.

Indeed this is an issue documented upstream too https://github.com/ValveSoftware/steam-for-linux/issues/9383

Given how common this can be, wouldn't it be good to, temporarily, remove the lines generating the issues in the .desktop files? Those would be

PrefersNonDefaultGPU=true
X-KDE-RunOnDiscreteGpu=true

This is what they are doing for the flatpak too: https://github.com/flathub/com.valvesoftware.Steam/pull/1086/files

Thank you.
Kind regards.

In case of dual GPU laptops (all of the gaming ones nowadays), removing the line makes Steam itself and all subsequent games launched from it to not use the discrete GPU.

Then people start adding all sort of environment variables everywhere to use it.

The statement that games know and pick up which GPU to use based on Vulkan extensions is not entirely true.

It should work 100% unless the user is trying to run it on a system where the second card is for example being driven by Nouveau and not the Nvidia driver.

Avoiding people putting variables everywhere that they don't know exactly about is what made Valve add it in the first place, so I'm very reluctant to remove it. Personally I never had any issue. So far I've seen people playing with these variables even if they don't pertain to the hardware/driver combo they have installed:

MESA_VK_DEVICE_SELECT
__NV_PRIME_RENDER_OFFLOAD
GLX_VENDOR_LIBRARY_NAME
DRI_PRIME

Also users can right click on the desktop icon and just select to run it on the integrated cards instead of the predefined discrete card (the opposite of all desktop menus that don't have that line).

Might not be a perfect solution, but is generally better than random wrong advices everywhere.

I see you point, it's a lose - lose situation. But keep in mind that with the Linux most common hardware configuration, according to the Steam statistics, so AMD GPUs on desktops (which usually don't have an iGPU) Steam doesn't start at all with these options. That's what happens on my setup. I started it from command line until now, when I finally figured out the issue.

In the end it's a bug either in Mesa or Steam, I'm not entirely sure. Making it work out of the box on laptops runnig OSS drivers covers the smaller amount of user. I assume the .desktop file options do nothing when running the Nvidia proprietary driver.

What about this: don't change the current desktop file, but add a second one, calling it something like "Steam default GPU" and make it identical to the original lines, but without the two options for the dGPU. It's a bit quirky, but there is a good chance people will try both and use the one that works.

Thank you.
Kind regards.

(In reply to Simone Caronni from comment #5)
Yeah , in Nvidia case, I had a brain stop 


we need configure correctly the nvidia as primary GPU 

cat /etc/X11/xorg.conf.d/nvidia.conf

Section "OutputClass"
  Identifier "nvidia"
  MatchDriver "nvidia-drm"
  Driver "nvidia"
  Option "AllowEmptyInitialConfiguration"
  Option "PrimaryGPU" "yes"
  Option "SLI" "Auto"
  Option "BaseMosaic" "on"
EndSection

Section "ServerLayout"
  Identifier "layout"
  Option "AllowNVIDIAGPUScreens"
EndSection


dnf install xorg-x11-drv-nvidia-cuda 

read https://rpmfusion.org/Howto/Optimus#NVIDIA_PrimaryGPU_Support 
if you use sddm or lightdm

in my /etc/sddm/Xsetup I had to add : 

xrandr --setprovideroutputsource modesetting NVIDIA-G0 >> /tmp/nvvv
xrandr --auto >> /tmp/nvvv

I notice I need restart sddm on boot because nvidia is not yet loaded when X start , you may check with 

xrandr --listproviders | grep -qi nvidi
grep_return_code=$?
echo return code = $grep_return_code >> tmp/nvvv


at last but not least configure LIBVA ( https://rpmfusion.org/Howto/NVIDIA#VDPAU.2FVAAPI  ) 

dnf install nvidia-vaapi-driver libva-utils vdpauinfo
and I need add on bashrc :

export LIBVA_DRIVER_NAME=nvidia

(In reply to Sérgio Basto from comment #7)


I did remove it some days ago Option "PrimaryGPU" "yes" by mistake, because I read in /var/log/Xorg.0.log "NVIDIA(0): Option "PrimaryGPU" is not used", but is in use, we can read in other line "OutputClass "nvidia" setting /dev/dri/card1 as PrimaryGPU" .


if you don't have  Option "PrimaryGPU" "yes" , all sort of strange things can happen

(In reply to Enrico Tagliavini from comment #6)
> What about this: don't change the current desktop file, but add a second
> one, calling it something like "Steam default GPU" and make it identical to
> the original lines, but without the two options for the dGPU. It's a bit
> quirky, but there is a good chance people will try both and use the one that
> works.

You can just right click on the icon and select "Launch using Integrated Graphics Card". The non-default one will have "Launch using Discrete Graphics Card".

I think it's a bit redundant.

Created attachment 2542 [details]
Right click has no option for discrete or primary GPU

Right clicking from the menu doesn't give any option for integrated or discrete GPU

(In reply to Simone Caronni from comment #9)
> (In reply to Enrico Tagliavini from comment #6)
> > What about this: don't change the current desktop file, but add a second
> > one, calling it something like "Steam default GPU" and make it identical to
> > the original lines, but without the two options for the dGPU. It's a bit
> > quirky, but there is a good chance people will try both and use the one that
> > works.
> 
> You can just right click on the icon and select "Launch using Integrated
> Graphics Card". The non-default one will have "Launch using Discrete
> Graphics Card".
> 
> I think it's a bit redundant.

Unfortunately this doesn't work for me. I have no such option, see the screenshot I just attached. I'm running KDE Plasma with a Wayland session, for the record. I think in GNOME you have that option, but not in KDE.

Nevertheless yes, it can be a bit redundant, I agree. But even if I use Linux since 2001 I didn't think of that, it's an advertised feature. Also, it's meant to be temporary until the issue is actually fixed (i.e. the issue on github is closed as solved).

In any case, thank you for maintaining the package, it's very appreciated.

Kind regards.

Fedora Linux 38 entered end-of-life (EOL) status on 2024-05-21.

Fedora Linux 38 is no longer maintained, which means that it
will not receive any further security or bug fix updates. As a result we
are closing this bug.

If you can reproduce this bug against a currently maintained version of Fedora
Linux
please feel free to reopen this bug against that version. Note that the version
field may be hidden. Click the "Show advanced fields" button if you do not see
the version field.

If you are unable to reopen this bug, please file a new report against an
active release.

Thank you for reporting this bug and we are sorry it could not be fixed.

I'm reopening this issue, as it still affects Fedora 40.

An alternative workaround, which allows games to keep defaulting to the dGPU, is to add the -cef-disable-gpu flag when launching Steam.

This disables GPU acceleration in Steam's embedded browser, which is the source of the crashes. However this might be undesirable for users not affected by this issue, whom may benefit from GPU acceleration.

The best solution would be pointing the .desktop entry to a shim launcher that introduces the -cef-disable-gpu flag if it detects that it's running in an environment that will trigger this bug.

Here's an implementation of such a launcher:

--------8<--------
#!/bin/bash
# Shim to work around issues with Steam

declare -a steam_options

# Disable GPU acceleration in Steam's embedded browser when using
# non-default GPU, to avoid crashes.
# See: https://github.com/ValveSoftware/steam-for-linux/issues/9383
if [ -n "$DRI_PRIME" ] ; then
    steam_options+=(-cef-disable-gpu)
fi

exec steam "${steam_options[@]}" "$@"
--------8<--------

The test is just looking for the DRI_PRIME environment variable being set.
I'm assuming this variable isn't set if the system doesn't have multiple GPUs, but I haven't tested this assumption.
If I'm wrong, then users on single GPU systems will also have GPU acceleration disabled.

*** Bug 6942 has been marked as a duplicate of this bug. ***

I wrote a script that cleanly installs the workaround I described earlier.

You can find it here: https://gist.github.com/major-gnuisance/4fad491e37c5ac7efa72f9473d4e95bd

You can run it as a normal user or as root.
If you run it as root, the workaround is installed for all users by placing files in /usr/local/.
Otherwise, the files will be placed under ~/.local/ and it will only affect your user.

That being said, I will personally continue to launch Steam using integrated graphics and then set DRI_PRIME in particular games' launch options.
I don't like the idea of games defaulting to the dGPU when they might not need it.

(In reply to Major Gnuisance from comment #16)
> That being said, I will personally continue to launch Steam using integrated
> graphics and then set DRI_PRIME in particular games' launch options.
> I don't like the idea of games defaulting to the dGPU when they might not
> need it.

By chance does your system have only open source drivers? I.e. one of your GPUs is NOT an Nvidia card powered by the proprietary Nvidia driver?

DRI_PRIME is not set (as Prime is not used) and vga_switcheroo is disabled when the Nvidia driver is loaded.

(In reply to Simone Caronni from comment #17)
> (In reply to Major Gnuisance from comment #16)
> > That being said, I will personally continue to launch Steam using integrated
> > graphics and then set DRI_PRIME in particular games' launch options.
> > I don't like the idea of games defaulting to the dGPU when they might not
> > need it.
> 
> By chance does your system have only open source drivers? I.e. one of your
> GPUs is NOT an Nvidia card powered by the proprietary Nvidia driver?
> 
> DRI_PRIME is not set (as Prime is not used) and vga_switcheroo is disabled
> when the Nvidia driver is loaded.

That's right, it's an all AMD system.

I was under the impression Nvidia's drivers supported PRIME render offloading in pretty much the same way nowadays. Silly me. It's Nvidia, after all.

Would it suffice to look for __NV_PRIME_RENDER_OFFLOAD in addition to DRI_PRIME to make it work with Nvidia as well?

I'm judging from this: https://download.nvidia.com/XFree86/Linux-x86_64/555.42.02/README/primerenderoffload.html

Wait, is this not even a problem on hybrid graphics systems with Nvidia dGPUs running proprietary drivers?

Now I see why this issue has languished for so long without mobs of people complaining.

Beside my own devices, I used to maintain a fleet of laptops with Intel/Nvidia GPUs at work.

The way it works with the proprietary Nvidia drivers is that on Optimus laptops the Nvidia GPU powers off if not in use and in desktop systems it just stays on without doing anything.

The switch is done via GLVND for GL libraries and Vulkan loaders for Vulkan contexts. Having said that, you just start Steam or run "lspci" (for example) and the Nvidia GPU wakes up and you transparently use it.

On the laptops I used, one particular USB-C port and the HDMI port would always fire up the Nvidia GPU when a display is connected as described in the laptop manual.

On my desktop with an integrated AMD GPU and a desktop Nvidia GPU, I can connect the output to either the AMD output or the Nvidia output and it's the same as the laptop, the usage is pretty transparent.

As I said before, loading the Nvidia driver makes the system turns off vga_switcheroo (https://docs.kernel.org/gpu/vga-switcheroo.html) and it's not using DRI, the system uses another mechanism. Setting DRI_PRIME with the Nvidia driver loaded actually throws an error:

$ DRI_PRIME=1 glxinfo -b
glx: failed to create dri3 screen
failed to load driver: nouveau
33

The variables used by the Nvidia driver are these (for example I deployed this on all laptops):

$ cat /etc/profile.d/nvidia-run.sh 
# Optimus laptops with Intel as the primary video card.
# Vulkan and EGL programs do not need to specify a library.

# Run a program offloading to the Nvidia card and forcing the Nvidia GLX library:
alias nvidia-3d='__NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia "$@"'

# Same, but run the program under Xwayland:
alias nvidia-3d-x='XDG_SESSION_TYPE=X11 __NV_PRIME_RENDER_OFFLOAD=1 __GLX_VENDOR_LIBRARY_NAME=nvidia "$@"'

# Force libva to use the nvidia driver backend:
alias nvidia-video='LIBVA_DRIVER_NAME=nvidia "$@"'

After a confuse ex colleague that maintains now the laptop fleet in my place, I came up with a blog post on the topic: https://negativo17.org/prime-optimus-laptops-and-multi-gpu-systems/

Hope it clarifies things a bit.

Great article!

I'm not sure where that leaves us exactly, though.

I think the key questions for this issue are these:
1. What kinds of systems are affected by this bug?

2. How can affected systems be detected by a process launched via the .desktop file?

3. Does the -cef-disable-gpu flag prevent this bug from manifesting in all of those systems?


For my system, the answers are as follows.
1: an all AMD laptop, where:
 - An AMD iGPU is the default rendering device and is driving the displays
 - A "headless" AMD dGPU is available for PRIME GPU offloading
 - All GPUs are using FOSS drivers
2: check if DRI_PRIME environment variable is set
3: yes

By answering these questions we can prepare a shim with these properties:

A. Keep the behavior of Steam games defaulting to the dGPU, in all systems.*

B. APPLY the -cef-disable-gpu flag in AFFECTED systems, providing a workaround for this issue.

C. DON'T APPLY the -cef-disable-gpu flag in AFFECTED systems IF launching Steam with integrated graphics, allowing Steam to use GPU acceleration in its embedded browser.

D. DON'T APPLY the -cef-disable-gpu flag in UNAFFECTED systems.


Maybe just apply -cef-disable-gpu if either DRI_PRIME *or* __NV_PRIME_RENDER_OFFLOAD is set?

Would that be enough to make everyone happy while the underlying issue isn't fixed on Valve's end?


* (The desirability of this is debatable. I'd rather use `switcheroo launch %command%` in the launch options for any game that I actually want to be using the dGPU. But this is another issue entirely. The process of choosing the GPU for each game should be handled by Steam, really.)

Does setting -cef-disable-gpu on the command line change the equivalent setting in the GUI?

It's under Settings / Interface / Enable GPU accelerated rendering in web views (requires restart).

If you start it fBecause if it's yes, we can set it for everyone and then individual users can re-enable itrom the command line without the -cef-disable-gpu, can you turn the setting off and then it works also when clicking from the menu?