Remove PrefersNonDefaultGPU=true from .desktop file of Steam

[Jan200101]

counter-part to #7089

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.

Relevant issues that showcase the feature acting incorrectly:
https://gitlab.gnome.org/GNOME/gnome-shell/-/issues/4796
#8074
flathub/com.valvesoftware.Steam#784
#8069
#8179
and many more

---

Alternatively the implementation for the xdg desktop key could be fixed.

There are many heuristics one can use to figure out if a GPU is discrete or integrated, none appear to be completely reliable.

I've made a proposed change to switcheroo-control that would give GPUs a "discrete" flag that could improve the situation.
https://gitlab.freedesktop.org/hadess/switcheroo-control/-/merge_requests/69

[TiZ-HugLife]

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

[Jan200101]

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)

[TiZ-HugLife]

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.

[Jan200101]

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.

[TiZ-HugLife]

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.

[lunaneff]

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

[Jan200101]

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.

[Jan200101]

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

[TiZ-HugLife]

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.

[Jan200101]

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.

[TiZ-HugLife]

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.

[netfab]

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

[Jan200101]

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

[michaelneverwins]

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 (bottlesdevs/Bottles#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.

[Jan200101]

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 linuxmint/xapp#178

[bmfkai]

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.

[moosey-moose]

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.