If we're going to do this, I think it'll be important for Steam to provide a UI for launching programs using the discrete GPU. UI-wise, it can be as simple as a checkbox in the properties: "Run on discrete GPU". In the backend, it should set the environment variables that are relevant to the discrete GPU in the system when running a given app/game. For Intel and AMD, DRI_PRIME=<pci ID of discrete GPU>, and for NVidia, __NV_PRIME_RENDER_OFFLOAD=1, __GLX_VENDOR_LIBRARY_NAME=nvidia, and __VK_LAYER_NV_optimus=NVIDIA_only

The Nvidia prime flags do not lend themselves to multi Nvidia GPU setups and DRI_PRIME is, to my knowledge, not compatible with the Proprietary Nvidia drivers.

Without replicating a lot of the work, the Switcheroo dbus service could be queried, it will return all the relevant env vars to be used, but it also suffers the issue with the nvidia flags.

(EDIT: this was originally a note about fixing it upstream, added it to the OP instead)

If we decide to approach this problem by changing the way each desktop behaves, it's going to take way too long for it to actually reach even people who are using the latest versions of each desktop, never mind people on stable distros. Not that I believe this is reason enough not to fix it at all, but we can't rely on desktops changing their behavior to fix Steam running on them.

Besides, Steam should be able to make decisions on its own--and empower users to make these decisions too--on what games run on the discrete GPU. On Windows systems, this is done via the control panel by selecting the executable in question and telling it what mode to use. This is honestly pretty clunky and unfriendly! We have the pieces necessary to do it better on Linux.

Switcheroo is a GNOME service that is not available on Plasma systems by default, but its logic is fairly easy to adapt.

Switcheroo is a GNOME service that is not available on Plasma system

Switcheroo is the kernel component for switching between GPUs on thefly

Switcheroo-control is an independent (not GNOME or KDE related) dbus service that can be installed on most distros and is installed by default by some.

Sorry, made an incorrect assumption; I don't have the Switcheroo Control DBus service in KDE Neon, so I presumed it was GNOME-centric. If most distros aren't shipping it, or if it ships along DE lines, then it's not something Steam can rely on.

GNOME and KDE both have UI for switcheroo-control.

From reading KDE's code, it falls back to a custom implementation using the DRI_PRIME env var if switcheroo-control isn't available. GNOME doesn't have such a fallback.

Ubuntu and Fedora both have it as a hard dependency of gnome-shell

On Arch, it's an optional dependency of GNOME, Cinnamon, and Budgie

On NixOS, Cinnamon installs it by default

From reading KDE's code, it falls back to a custom implementation using the DRI_PRIME env var if switcheroo-control isn't available. GNOME doesn't have such a fallback.

Quick note:
KDE's fallback for switcheroo-control is the Solid Power API, which only reports if switcheroo in the kernel is enabled.
Switcheroo is only supported by the existing in-kernel drivers, so it cannot detect GPUs using Nvidias proprietary drivers.

switcheroo-control has been archived for the time being.
I'll see what I can do, but there is guarantees.

I don't know why you decided all of this hinges on Switcheroo-control. It's not that important. What it's doing is not actually that hard; I replicated much of its functionality--albeit very slapdash--in this shell script. And I didn't even know Switcheroo-control existed when I made it; I just wanted an easy thing to prepend to commands so I could easily run things on my dGPU on XFCE. Switcheroo-control was never going to be worth relying on anyways since there are a lot of distros not shipping it at all.

The core of the functionality is:

1. Find out if the system you're running on has two GPUs
2. Figure out what vendor is providing the non-default GPU
3. Export the appropriate vendor-specific environment variables before running the app

And because Steam should really have a checkbox in the properties for this, you wouldn't worry if the "non-default" GPU isn't the dedicated one, because if that's the case, you shouldn't check the box anyways.

I don't know why you decided all of this hinges on Switcheroo-control.

Because that is quite literally what the major desktop environments use to support the desktop key.

What it's doing is not actually that hard; I replicated much of its functionality--albeit very slapdash--in this shell script.

This proves my point. Your script:

• is only based on heuristics, not actual data
• Assumes Nvidia devices are always discrete (they made integrated GPUs)
• Assumes Radeon GPUs are always discrete (they were much are not)
• Does not consider Intel discrete GPUs
• Does not consider if the relevant GPU is the default or not. (DRI_PRIME=1 when your default is the discrete GPU will fall back onto the integrated GPU)

A correct implementation would query the GPU where possible, amdgpu and nouveau provide open source interfaces for it and the proprietary nvidia drivers can be queried through nvml.

Switcheroo-control was never going to be worth relying on...

This point is completely moot.
Everyone having the issue with PrefersNonDefaultGPU are having issues because they have switcheroo-control.
This issue is not about steam adding their own GPU selection, its about either removing what is broken or fixing it, which would mean fixing it at the Desktop Environment level.
Since both major desktop environments, KDE and Gnome, either support or completely rely on switcheroo-control, its the best place to make this change.

I have spend more than enough time to realize that this problem is far from trivial, which is why the current behavior is how it is.
Please do not pretend its something that can easily be hacked away at using a shell script.

Like I said, my script was very slapdash, and it's not even really the point anyways. Because not only is my script doing it wrong, so is switcheroo-control. And exactly as you say, the fact that switcheroo-control is doing it wrong is part of what's causing people trouble. You made a PR request, but the repo is archived. So like... how is any fix to the DEs' behavior going to reach anyone, anyways?

But admittedly, I've gone off course here. Exactly as you say once again, this issue is about whether we should remove the PrefersNonDefaultGPU key from the desktop file. You want to focus on fixing the desktops' behavior to do the right thing and run all of Steam on the actual discrete GPU. I want to focus on users not losing functionality if this key is removed, and being able to at least run the games they want on the discrete GPU without juggling confusing env vars.

Either way, I think we can agree that with the way things are at the moment, the answer to the question of "should we remove this key" is no.

Hi here,

Just to say that since several weeks I'm getting a segfault in dmesg each time a game is exiting (see the link above).
Everything else is working fine, I do not have any other error.
The segfault no longer appears if I set PrefersNonDefaultGPU to false in steam desktop file.
This happens :

• if I use only the nvidia card (with intel iGPU disabled)
• with intel iGPU enabled and NVIDIA's PRIME render offload

Update on this front:

• cleaned up and remade the switcheroo-control PR. Its now cleaner and supports all major GPU drivers (nouveau, nvidia, amdgpu, i915) https://gitlab.freedesktop.org/hadess/switcheroo-control/-/merge_requests/69
  • I've made a Fedora COPR for developers to use since god knows when it will get merged
• Opened KDE PR https://invent.kde.org/frameworks/kio/-/merge_requests/1556
  • KDE recently got a bug report made against this broken behavior https://bugs.kde.org/show_bug.cgi?id=480797
• Opened Gnome PR https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/3193

If there are any other projects that are broken by this, feel free to point them out so I can propose a change.

Since I had posted this Bazzite and Nobara have adopted this patch with Bazzite even shipping the needed Desktop Environment changes.

For Fedora or Silverblue users a COPR has also been made

If there are any other projects that are broken by this, feel free to point them out so I can propose a change.

My system has both integrated graphics and a dedicated GPU, and for a while I had both enabled with the dedicated GPU as the default, so I've seen related issues a couple of times. However, I'm not sure whether these were distinct issues or just manifestations of the same problem that your switcheroo-control PR would already fix.

After I upgraded Linux Mint (Cinnamon Edition) from 21.1 to 21.2 last year, I noticed that right-clicking a game in the menu would reveal a "Run with dedicated GPU" option.

Using this option would actually cause certain games — namely OpenGL games but not Vulkan games — to use the integrated graphics instead, presumably due to my dedicated GPU being the default device.

I don't know how this "Run with dedicated GPU" option is implemented, but I assume it has the same effect as adding PrefersNonDefaultGPU=true to a game's desktop entry, which also caused the same behavior. (My desktop entry for SuperTuxKart had PrefersNonDefaultGPU=true by default. The game used my integrated graphics until I changed it to PrefersNonDefaultGPU=false, at which point it used the dedicated GPU. Launching it from the menu with the "Run with dedicated GPU" option would then make it use the integrated graphics again.) Both the "Run with dedicated GPU" option and PrefersNonDefaultGPU=true also seem to have the same effect as setting DRI_PRIME=1. (When running supertuxkart from the command line, it used my dedicated GPU, and when running DRI_PRIME=1 supertuxkart, it used the integrated graphics).

Prior to that, I'd had a similar issue with the "Discrete Graphics" toggle in Bottles (https://github.com/bottlesdevs/Bottles/issues/2967), and was confused because I didn't even realize at first that my dedicated GPU was the default device. Ultimately I closed that issue because I wasn't convinced that there was a bug in Bottles itself; it seemed that the "Discrete Graphics" switch just had the same effect as setting DRI_PRIME=1 (although I'm not sure if that's really what it does, let alone whether that would be correct).

After figuring out what was going on, I actually disabled my integrated graphics entirely. (I could have set it as the default to get the "normal" behavior out of all these GPU-switching options, but I didn't want the hassle of dealing with any of it). I temporarily re-enabled the integrated graphics today (again as non-default) just to verify that all of this behavior is still the same as of Linux Mint 21.3 and Bottles 51.11.

However, I'm not sure whether these were distinct issues or just manifestations of the same problem that your switcheroo-control PR would already fix.

the common DEs (Gnome, KDE, Cinnamon, etc.) implement support this kind of GPU support via switcheroo-control so it should fix it.

For Cinnamon specifically a PR exists that adds support for it https://github.com/linuxmint/xapp/pull/178

stumbled across this in PopOS but the weird thing is that the literal desktop shortcut works fine, with the same .desktop configuration as the shortcut in /usr/share/applications/. Removing "PrefersNonDefaultGPU=true" from this shortcut solves the problem. No idea why it would be different launching it from the desktop or from the applications modal.

My configuration consists of an eGPU so it may be possible that the modal is executing under different conditions.

On fresh Arch install with Hyprland, this flag causes Steam to repeatedly open and the window die:

[2024-10-04 02:23:39] X Error of failed request:  BadWindow (invalid Window parameter)
[2024-10-04 02:23:39] Major opcode of failed request:  20 (X_GetProperty)
[2024-10-04 02:23:39] Resource id in failed request:  0x1
[2024-10-04 02:23:39] Serial number of failed request:  9
[2024-10-04 02:23:39] xerror_handler: X failed, continuing

Interestingly, this wasn't happening with a similar setup where the only difference was using an nvidia card and the proprietary nvidia drivers, now I'm using AMD and vulkan-radeon. Setting this to false allows steam to launch from wofi without any issue.

Hi,
starting steam from desktop file crash X11 , as I use as DefaultGPU the discrete GPU , but lunch from bash shell works pretty well

I'm on fedora 40 and every time steam updates, it sets PrefersNonDefaultGPU to true, which prevents it from launching properly. It does start, but the steam UI won't open.

I just got bitten by this. Last time I successfully ran Steam was end of April. Yesterday, I tried to run it again, but Steam launcher now gets caught in a loop, crashing and restarting. Took a while to figure out that the key PrefersNonDefaultGPU actually sets DRI_PRIME to point to my integrated GPU, as this bug describes. Removing PrefersNonDefaultGPU from the desktop file solves the problem.

PrefersNonDefaultGPU is broken by design, intended to mean "Use the Discrete GPU if possible" but instead generalized to mean "Use anything that we aren't using by default" which, on full tower setups, may very well be the the integrated GPU.

The Description from the specification supports that the Key was generalized to the point of being useless:

If true, the application prefers to be run on a more powerful discrete GPU if available, which we describe as “a GPU other than the default one” in this spec to avoid the need to define what a discrete GPU is and in which cases it might be considered more powerful than the default GPU. This key is only a hint and support might not be present depending on the implementation.

Just my 2 cents but I do not understand why the key is claimed to be broken by design (apart that its name is very unclear). It seems to me that from the description, setting PrefersNonDefaultGPU to true indicates a preference for the “fastest” GPU. (Whether Steam launcher should set this or rather let the user decide is of course worth asking, this is a different point, as is the question of how to work around the wrong implementation when setting the key to true actually chooses the integrated GPU, as on my system.)

Just my 2 cents but I do not understand why the key is claimed to be broken by design (apart that its name is very unclear). It seems to me that from the description, setting PrefersNonDefaultGPU to true indicates a preference for the “fastest” GPU.

You are correct in how the key is suppose to be used (and how application developers use it) If true, the application prefers to be run on a more powerful discrete GPU if available […] but Desktop developers implemented it according to its name […], which we describe as “a GPU other than the default one” in this spec to avoid the need to define what a discrete GPU is.

In my eyes its broken by design because:

• its impossible to figure out what it does by the name alone
• the description doesn't define which GPU should be used other than “a GPU other than the default one”
  • you could argue that the application prefers to be run on a more powerful discrete GPUspecifies this but "more powerful" is vague and impossible to fullfil for every use case.
• a Desktop file doesn't specify which type of work an application might do so its impossible to figure […] in which cases it might be considered more powerful than than the default GPU.

On Fedora 42 this is also broken due to the inclusion of the PrefersNonDefaultGPU=true..
This is a bad param to be setting by default. My Default GPU, as I am on a desktop with a GPU, is the "More powerful" one. It seems to me this keeps attempting to use the integrated GPU on my motherboard, which doesn't have anything connected to it, and is definitely not "The more powerful" one..

My guess is this is some kind of laptop-centric workaround where the iGPU drives the display and the dGPU is only used when called directly, but really merely giving a vague description and saying "I declare this to be the more powerful gpu" with a lot of hand waving is nonsensical.

I think it makes way more sense to expect the "Default GPU" is the one people want to run things on, and if they do not want to use their "default gpu" then they can hack around and make silly workarounds to make THEIR setup work rather than punish people using the obvious path.

the switcheroo-control PR has been merged
once a release has been tagged, distros are upgraded and Desktop Environments support the new option the issue will be fixed.

Gonna update this so people won't get spammed with notifications

• 2025-06-27: switcheroo-control added Discrete flag
• 2025-07-03: KDE merged (and released) support for the new Discrete flag
• 2025-07-30: Cinnamon merges support for the new Discrete flag
• 2025-08-29: new switcheroo-control release tagged
  • At the time of writing its already available in Fedora, Arch, Debian testing, Gentoo testing and more

the gnome PR is a bit behind due to disagreements and possible misunderstandings on how it should it be implemented.

Gnome has merged support which will be released with Gnome 50.
There are still some compositors out there that don't support this properly, for example Cosmic, but I hope this will improve over time.
I'll close this issue once the Gnome release is out.

Gnome has merged support which will be released with Gnome 50.
There are still some compositors out there that don't support this properly, for example Cosmic, but I hope this will improve over time.
I'll close this issue once the Gnome release is out.

Reminder that this can be closed