I second this.

But remember that we also have Primus, so it wouldn't be a checkbox, more like a combobox.

Autodetection of installed backends would be much better (primusrun => optirun => none), and THEN show the combobox so you can pick the best one suitable for your particular setup.

There's a Bumblebee branch that adds primus transport: https://github.com/Bumblebee-Project/Bumblebee/tree/common-primus

Also, just wanted to say that the [Reviewed] label is one of the greatest ideas I've seen :)

I also suggest that steam should detect the hybrid vga scenario, and suggests/prompt the user to install bumblebee/primus.

This detection could be made with:

joao@joao-nb:~$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core processor Graphics Controller (rev 09)
01:00.0 VGA compatible controller: NVIDIA Corporation GF108 [GeForce GT 630M](rev ff)

Counting GPUs isn't the best idea. Won't really work with SLI setups.
Checking for an Intel one and an Nvidia one should cover most cases though.
12.01.2013 1:44 пользователь "João Vitor P. Moraes" <
[email protected]> написал:

I also suggest that steam should detect the hybrid vga scenario, and
suggests/prompt the user to install bumblebee/primus.

This detection could be made with:

joao@joao-nb:~$ lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 3rd Gen Core
processor Graphics Controller (rev 09)
01:00.0 VGA compatible controller: NVIDIA Corporation GF108 GeForce GT
630M http://rev%20ff

—
Reply to this email directly or view it on GitHubhttps://github.com/ValveSoftware/steam-for-linux/issues/634#issuecomment-12165031.

official nvidia hybrid support should be imminent, wouldnt hold my breath for bumblebee support on steam

Do you have a source for this? PRIME helpers don't count.

aww comon, PRIME helpers.... well yes i meant exactly those
http://lists.freedesktop.org/archives/dri-devel/2013-January/033476.html

I wouldn't say it's imminent. I guess there's no reason behind that for NVIDIA, other than sneaking their own code past EXPORT_SYMBOL_GPL. But that doesn't mean we'll see Optimus in the coming weeks or even months. It's all just prep work for now with no official statement to back it.

"imminent" is a relative term, and i suspect my understanding of it isn't widely shared, as i would count ~1 +/-1 year fitting to that term. anyways, time to stop bugging the bugtracker with stuff valve should know better than any of us anyways. :dancers: nice emoticons.

@kisak-valve

Are you sure that request to implement native DRI_PRIME support (which is works for dGPU and eGPU) is the same as request to implement optirun support?

Hi @kisak-valve

It would be nice to have the feature of selecting vulkan driver provider via VK_ICD_FILENAMES
I already launch steam with only radv json and the application is forced to use secondary and powerful graphic card.

Thank you in advance.

I'm dealing with the same problem on Steam (PRIME offloading) and I would love to have the ability to select secondary GPU.

Currently I'm doing it this way:
sh ~/prime.sh %command% Works perfectly if a game binary was launched (CS:GO)
It doesn't work correctly if the game is launched via a wrapper (such as Left 4 Dead 2, Goldsrc games, etc)

My prime.sh cointains this
export __NV_PRIME_RENDER_OFFLOAD=1 export__GLX_VENDOR_LIBRARY_NAME=nvidia exec "$@"

Running Fedora 31, would also like to see this feature.

Just as adding more information,
Mesa added a vulkan selection layer.
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/1766

DRI_PRIME=1 should work as well for vulkan in the near future.

Waiting for mesa 20.1.0 :tada:

PS: I've never tried before but somebody can try laptopmodetools to export some variables when laptop is plugged in.

switcheroo-control provides a DBus interface for enumerating available GPUs. It will provide the environment variables needed to offload to them, and supports the NVIDIA proprietary drivers.

gdbus introspect --system --dest net.hadess.SwitcherooControl --object-path /net/hadess/SwitcherooControl --only-properties

node /net/hadess/SwitcherooControl {
  interface net.hadess.SwitcherooControl {
    properties:
      readonly b HasDualGpu = true;
      readonly u NumGPUs = 2;
      readonly aa{sv} GPUs = [{'Name': <'NVIDIA Corporation TU106M [GeForce RTX 2070 Mobile]'>, 'Environment': <['__GLX_VENDOR_LIBRARY_NAME', 'nvidia', '__NV_PRIME_RENDER_OFFLOAD', '1']>, 'Default': <false>}, {'Name': <'Intel Corporation UHD Graphics 630 (Mobile)'>, 'Environment': <['DRI_PRIME', 'pci-0000_00_02_0']>, 'Default': <true>}];
  };
};

GNOME uses this to provide the context menu item "Launch using Dedicated Graphics Card" on laptops configured for PRIME render offload.

Huh, I figured since Steam itself was running the dGPU it would prevent the card from suspending. But that seems to not be the case if it's minimized to the tray (nothing to draw, after all).

$ cat /sys/bus/pci/devices/0000\:01\:00.*/power/runtime_status
suspended
suspended
suspended
suspended

Anyway, we did just get support merged into GNOME master: GNOME/gnome-shell!1226

KDE has been using X-KDE-RunOnDiscreteGpu for a while, so KDE users could potentially use this already.

steam-launcher beta 1.0.0.70 adds PrefersNonDefaultGPU=true, as well as the older X-KDE-RunOnDiscreteGpu=true.

(If you get your Steam client through an unofficial distro-specific package, they will need to update to 1.0.0.70 before you see this change.)