Add PrefersNonDefaultGPU=true to .desktop file of Steam

[Eonfge]

Duplicate of the upstream issue:
ValveSoftware/steam-for-linux#7089

---

There is a new standard for aiding in multi-GPU setups. You can now set a flag called PrefersNonDefaultGPU which will tell the computer to use the alternative (generally speaking, dedicated) GPU.

By setting this flag, Steam and it's applications will run with the more powerful GPU by default, preventing many annoyed customers as they are rushing B with 20 fps.

Docs

• https://www.gamingonlinux.com/articles/the-linux-desktop-entry-specification-gets-a-way-to-automatically-use-a-discrete-gpu-merged-into-gnome.16598
• https://www.hadess.net/2020/05/dual-gpu-support-launch-on-discrete-gpu.html
• https://specifications.freedesktop.org/desktop-entry-spec/desktop-entry-spec-latest.html#recognized-keys

---

If upstream is not adding the feature, I would propose you guys add it manually.

[nanonyme]

Have you tested that it actually makes the games Steam launch run in the other GPU, not just Steam itself? Ideally Steam would run on primary GPU and games on secondary more powerful one.

[Eonfge]

Can confirm.

What I do:

• Search for Flatpak Steam
• Right click icon and select 'launch using Dedicated Graphics Card'
• Test a game, in this case Mindustry

What I see using Green With Envy, is that steam itself only takes a bit of video memory. Then when I start Mindustry, video game memory usage jumps up and the card starts actively running.

[crawfxrd]

Launching Steam on the dGPU and then launching Stardew Valley:

Tue May 12 14:55:09 2020       
+-----------------------------------------------------------------------------+
| NVIDIA-SMI 440.82       Driver Version: 440.82       CUDA Version: 10.2     |
|-------------------------------+----------------------+----------------------+
| GPU  Name        Persistence-M| Bus-Id        Disp.A | Volatile Uncorr. ECC |
| Fan  Temp  Perf  Pwr:Usage/Cap|         Memory-Usage | GPU-Util  Compute M. |
|===============================+======================+======================|
|   0  GeForce RTX 207...  Off  | 00000000:01:00.0 Off |                  N/A |
| N/A   44C    P8     8W /  N/A |    186MiB /  7982MiB |     38%      Default |
+-------------------------------+----------------------+----------------------+
                                                                               
+-----------------------------------------------------------------------------+
| Processes:                                                       GPU Memory |
|  GPU       PID   Type   Process name                             Usage      |
|=============================================================================|
|    0      1115      G   /usr/lib/xorg/Xorg                            14MiB |
|    0      1673      G   /usr/lib/xorg/Xorg                            89MiB |
|    0     35617      G   ...rd/.local/share/Steam/ubuntu12_32/steam    17MiB |
|    0     35626      G   ./steamwebhelper                               3MiB |
|    0     36178      G   ./StardewValley.bin.x86_64                    57MiB |
+-----------------------------------------------------------------------------+

Ideally Steam would run on primary GPU and games on secondary more powerful one.

Agreed, but it's been 7 years and Valve still hasn't implemented anything in the client for configuring GPUs (ValveSoftware/steam-for-linux#634). The only alternative is to add the environment variables to enable offloading to the launch options of every game.

[TiZ-HugLife]

It's not going to be possible to run Steam on the integrated GPU and specific games on the dedicated GPU unless a utility like optirun, or the prime-run utility apparently available in Ubuntu 20.04, is made available inside the flatpak such that users can edit launch options with optirun %command%

[evan-a-a]

@HugLifeTiZ Modern PRIME GPU is controlled via environment variables. DRI_PRIME in the case of nouveau and AMD, and __NV_PRIME_RENDER_OFFLOAD in the case of NVidia proprietary. There's no extra utility needed, Steam just needs to set the environment variables when launching games.

[TiZ-HugLife]

Actually, that doesn't work for Vulkan applications right now because the Flathub package for the nvidia driver doesn't have the optimus Vulkan layer: flathub/org.freedesktop.Platform.GL.nvidia#35

[soredake]

Any progress on this?

[smcv]

If upstream is not adding the feature

They might - it's also looking like a potential solution to some of the issues with the Steam container runtime on multi-GPU systems.

The Steam container runtime is not currently compatible with this Flatpak app (#642) but I'm working on it (flatpak/flatpak#3797).

Actually, that doesn't work for Vulkan applications right now because the Flathub package for the nvidia driver doesn't have the optimus Vulkan layer: flathub/org.freedesktop.Platform.GL.nvidia#35

We'll need access to the Optimus Vulkan layer if this is going to work usefully for NVIDIA users. Otherwise, __NV_PRIME_RENDER_OFFLOAD doesn't do anything.

[smcv]

steam-launcher beta 1.0.0.70 adds PrefersNonDefaultGPU=true, as well as the older X-KDE-RunOnDiscreteGpu=true. The Flathub package should automatically pick up that change next time the version is updated.

Actually, that doesn't work for Vulkan applications right now because the Flathub package for the nvidia driver doesn't have the optimus Vulkan layer: flathub/org.freedesktop.Platform.GL.nvidia#35

This is believed to be fixed in the latest builds of the fd.o Platform and its various NVIDIA driver extensions.

[nanonyme]

Relevant parts should now be in Flathub stable

• This app is using steam-launcher 1.0.0.70
• freedesktop-sdk 20.08 with Vulkan implicit layer support is released
• nvidia GL extension changes have been merged
  it would be great to have some testing and validation done.

[TiZ-HugLife]

It looks like Xubuntu 20.04 doesn't support PrefersNonDefaultGPU=true. Should that be considered a bug? I feel like the key has existed for a while now. That said, once the relevant environment variables are set for render offload, it does work as expected.

[smcv]

It looks like Xubuntu 20.04 doesn't support PrefersNonDefaultGPU=true. Should that be considered a bug?

A bug, maybe; a feature request, definitely. (However, you're running a LTS distribution, so you can't expect new features, or fixes for non-critical bugs, until your next upgrade - this is the price you pay for stability.)

That said, once the relevant environment variables are set for render offload, it does work as expected

For users of Optimus/Switchable Graphics systems with desktop environments that don't handle PrefersNonDefaultGPU=true or X-KDE-RunOnDiscreteGpu=true, I think we're heading towards this being the recommended workaround.

https://gitlab.freedesktop.org/hadess/switcheroo-control/ is what GNOME uses to implement PrefersNonDefaultGPU=true, and seems to be a reasonable implementation of enumerating GPUs and working out what the right environment variables are.

[Eonfge]

So, this issue is now completed? I'll leave it open if things still have to be discussed, but else I would say 'Mission Accomplished'.

Concerning Xubuntu 20.04 support, the standard was approved in May 2020 so every (LTS) release from before then obviously doesn't support it. GNOME only added support in 3.38 which came out in September 2020. So far as I know, Xfce doesn't support the parameter at all now, so I can't recommend any follow-up actions.

[nanonyme]

If someone can confirm shortcut now looks as expected, let's close.

[smcv]

I think as much as Steam can do here has already been done.

That change is only in beta versions of the upstream Steam launcher, and we might still find that we have to revert it. If we revert it, the most likely reason would be finding that it triggered a bad bug (for instance making games run on the "wrong" GPU on systems where the "right" GPU was previously used), in which case I suspect the Flatpak app would want to do the same.

Unfortunately, GPU selection is complicated, and GPU selection across container boundaries doubly so: presumably what most people want is a simple toggle for "run on least-power-consuming GPU" or "run on fastest GPU", but that is not something that actually exists right now, and instead we have multiple overlapping things, some of them GPU-vendor-specific and some of them rendering-API-specific.

[TiZ-HugLife]

For users of Optimus/Switchable Graphics systems with desktop environments that don't handle PrefersNonDefaultGPU=true or X-KDE-RunOnDiscreteGpu=true, I think we're heading towards this being the recommended workaround.

https://gitlab.freedesktop.org/hadess/switcheroo-control/ is what GNOME uses to implement PrefersNonDefaultGPU=true, and seems to be a reasonable implementation of enumerating GPUs and working out what the right environment variables are.

Is there any reason not to just... set all of the environment variables? My wrapper script for running stuff on the dGPU does try to be smart about it just because if I'm gonna share it I might as well, but do any of the environment vars conflict with each other?

If someone can confirm shortcut now looks as expected, let's close.

Yes, the expected keys are definitely in the .desktop file. :)

[smcv]

Is there any reason not to just... set all of the environment variables?

For you personally, on your specific system, probably not. For Steam in general, yes, there might be a reason.

DRI_PRIME=1 selects the first non-default GPU, whatever that is. If your default is a fast AMD/NVIDIA discrete GPU, and you also have a slow AMD/Intel integrated GPU, then DRI_PRIME=1 will do the exact opposite of what you want.

For example, a desktop gaming machine will often have an AMD or NVIDIA discrete GPU in a PCIE slot, an AMD or Intel integrated GPU built in to the CPU, a screen physically connected to the dGPU, and the dGPU set as the default in the system firmware. We want to stick to the dGPU on such systems, and we absolutely don't want to be asking the graphics stack to offload processing onto the iGPU.

In general people don't write completely unnecessary code, so if you ask "why can't you just do xyz by default", then the answer is usually "because xyz is sometimes what you want, and sometimes not".

If there's a straightforward way to always do the right thing, that doesn't result in the wrong thing on anyone's system, of course we want to do it - but just because it's the right thing on your system, that doesn't necessarily mean it's the right thing on every system.

[TiZ-HugLife]

Yes, there might be. DRI_PRIME=1 selects the first non-default GPU, whatever that is. If your default is a fast AMD/NVIDIA discrete GPU, and you also have a slow AMD/Intel integrated GPU, then DRI_PRIME=1 will do the exact opposite of what you want.

Oh yikes, that is... definitely not what we want, even though that's what the key says on the tin. I'd ask why it's not something more like PrefersGPU=performance but I know that debate is already happening and it was more important to have a working spec sooner rather than the perfect spec later.

If there's a straightforward way to always do the right thing, that doesn't result in the wrong thing on anyone's system, of course we want to do it - but just because it's the right thing on your system, that doesn't necessarily mean it's the right thing on every system.

You're absolutely right and I'm ultimately glad there is so much care going into this issue. 😀

As for things in XFCE-land, I'll start a thread on their forum for discussing support on their side so we have it ready for the next Xubuntu LTS at the latest.

[nanonyme]

Ack. @smcv can you please ping here if the feature gets reverted in the end?

[serhii-nakon]

@nanonyme Looks like I can not run Steam due this... I can run only from terminal using iGPU. If i trying to run Steam using discrete graphics by setting DRI_PRIME=1 or just from clicking UI icon I have infinite loop of Steam restarts.

[serhii-nakon]

DXVK or D3DVK anyway will use non default graphics.
I think if someone need it, better to add some additional option or even icon that will use some specific graphics or some window with question before run Steam.

[nanonyme]

I was afraid that this would not be generic solution.

[serhii-nakon]

Maybe better will request Valve to add functionality that will allow select graphic per game or globally inside Steam?

[TiZ-HugLife]

I was afraid that this would not be generic solution.

@nanonyme, I don't think this is the right mindset. The important thing is that it currently matches what upstream is doing. If they have the prefers non-default GPU key, the Flathub package should as well. It's only your job to care about a crash if it's caused by something the Flathub package is doing differently from upstream, and that is very likely not the case here.

This crash has also correctly been reported upstream at this issue in Valve's tracker and they are considering removing the key. There are plenty of folks experiencing this issue on traditional distro packages as well, so I'm of the mind that this crash is not for Flathub package maintainers to be concerned with. What is of concern to Flathub package maintainers is to follow what Valve decides to do about it. They may end up removing the non-default GPU key, leaving it to the applications to try to use the right GPU. OpenGL applications will get screwed up by this, but that will be a pain point for every version of the Linux Steam package, not just this one.

@serhii-nakon, this issue you're experiencing is most likely not specific to the Flathub package. Please contribute to and/or follow the linked issue instead of this one.

[nanonyme]

@HugLifeTiZ what do you mean? I thought the point of this issue was deviating from upstream defaults.

[TiZ-HugLife]

@nanonyme, the point of this issue was to try and remain in sync with upstream regarding the proposed change to the .desktop file. Notice that the OP made an issue report in Valve's tracker here and linked to it in this issue report. I think Valve made the change first, and then this package adopted it.

Keeping this issue open is fine since Valve might change their .desktop file in response to the DRI_PRIME issue, but it didn't really need to be reopened; with regards to non-default GPU usage, this package is not doing anything particularly special.

[nanonyme]

That is not at all my understanding. If Valve had done the change, it would propagate to this app. Instead, we override Valve setting.

[TiZ-HugLife]

No, we don't. The non-default GPU keys come directly from Valve, as per Simon's earlier comment in this issue. If you want, you can check it yourself. And the manifest isn't doing anything related to GPU selection either. It is editing the desktop file, but only to add a StartupWMClass. I don't believe steam_wrapper is doing anything either.

Actually, because of that, we can probably just close this outright. We're not doing anything with the .desktop file at all. We will simply inherit whatever change Valve decides to make to it.