search

ValveSoftware / steam-for-linux

Issue tracking for the Steam for Linux beta client
4.21k stars 174 forks source link

Remove PrefersNonDefaultGPU=true from .desktop file of Steam #9940

Open Jan200101 opened 1 year ago

Jan200101 commented 1 year ago

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 https://github.com/ValveSoftware/steam-for-linux/issues/8074 https://github.com/flathub/com.valvesoftware.Steam/issues/784 https://github.com/ValveSoftware/steam-for-linux/issues/8069 https://github.com/ValveSoftware/steam-for-linux/issues/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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

TiZ-HugLife commented 1 year ago

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 commented 1 year ago

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:

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 commented 1 year ago

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 commented 8 months ago

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 :

Jan200101 commented 7 months ago

Update on this front:

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 commented 5 months ago

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. mint-cinnamon-run-with-dedicated-gpu 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.

Jan200101 commented 5 months ago

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

bmfkai commented 3 weeks ago

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.