Dual-GPU support: Launch on the discrete GPU automatically

*reality TV show deep voice guy*

In 2016, we added a way to launch apps on the discrete GPU.

*swoosh effects*

In 2019, we added a way for that to work with the NVidia drivers.

*explosions*

In 2020, we're adding a way for applications to launch automatically on the discrete GPU.

*fast cuts of loads of applications being launched and quiet*

Introducing the (badly-named-but-if-you-can-come-up-with-a-better-name-youre-ready-for-computers) “PrefersNonDefaultGPU” desktop entry key.

From the specifications website:

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. 

And support for that key is coming to GNOME Shell soon.

TL;DR

Add “PrefersNonDefaultGPU=true” to your application's .desktop file if it can benefit from being run on a more powerful GPU.

We've also added a switcherooctl command to recent versions of switcheroo-control so you can launch your apps on the right GPU from your scripts and tweaks.

Dual-GPU support follow-up: NVIDIA driver support

If you remember, back in 2016, I did the work to get a “Launch on Discrete GPU” menu item added to application in gnome-shell.

This cycle I worked on adding support for the NVIDIA proprietary driver, so that the menu item shows up, and the right environment variables are used to launch applications on that device.

Tested with another unsupported device...

Behind the scenes

There were a number of problems with the old detection code in switcheroo-control:
- it required the graphics card to use vga_switcheroo in the kernel, which the NVIDIA driver didn't do
- it could support more than 2 GPUs
- and it didn't really actually know which GPU was going to be the “main” one

And, on top of all that, gnome-shell expected the Mesa OpenGL stack to be used, so it only knew the right environment variables to do that, and only for one secondary GPU.

So we've extended switcheroo-control and its API to do all this.

(As a side note, commenters asked me about the KDE support, and how it would integrate, and it turns out that KDE's code just checks for the presence of a file in /sys, which is only present when vga_switcheroo is used. So I would encourage KDE to adopt the switcheroo-control D-Bus API for this)

Closing

All this will be available in Fedora 32, using GNOME 3.36 and switcheroo-control 2.0. We might backport this to Fedora 31 after it's been tested, and if there is enough interest.

Dual-GPU integration in GNOME

Thanks to the work of Hans de Goede and many others, dual-GPU (aka NVidia Optimus or AMD Hybrid Graphics) support works better than ever in Fedora 25.

On my side, I picked up some work I originally did for Fedora 24, but ended up being blocked by hardware support. This brings better integration into GNOME.

The Details Settings panel now shows which video cards you have in your (most likely) laptop.

dual-GPU Graphics

The second feature is what Blender and 3D video games users have been waiting for: a contextual menu item to launch the application on the more powerful GPU in your machine.

Mooo Powaa!

This demonstration uses a slightly modified GtkGLArea example, which shows which of the GPUs is used to render the application in the title bar.

on the integrated GPU

on the discrete GPU

Behind the curtain

Behind those 2 features, we have a simple D-Bus service, which runs automatically on boot, and stays running to offer a single property (HasDualGpu) that system components can use to detect what UI to present. This requires the "switcheroo" driver to work on the machine in question.

Because of the way applications are launched on the discrete GPU, we cannot currently support D-Bus activated applications, but GPU-heavy D-Bus-integrated applications are few and far between right now.

Future plans

There's plenty more to do in this area, to polish the integration. We might want applications to tell us whether they'd prefer being run on the integrated or discrete GPU, as live switching between renderers is still something that's out of the question on Linux.

Wayland dual-GPU support, as well as support for the proprietary NVidia drivers are also things that will be worked on, probably by my colleagues though, as the graphics stack really isn't my field.

And if the hardware becomes more widely available, we'll most certainly want to support hardware with hotpluggable graphics support (whether gaming laptop "power-ups" or workstation docks).

Availability

All the patches necessary to make this work are now available in GNOME git (targeted at GNOME 3.24), and backports are integrated in Fedora 25, due to be released shortly.

infra-red remotes in GNOME 3

gnome-lirc-properties has served its purpose. It will probably carry on working on GNOME 3 desktops, but you won't be happy when it drags in GTK+ 2.x Python bindings, HAL or doesn't integrate into the new control-center.

But things have changed since gnome-lirc-properties was first written, and the way to handle IR remotes has changed as well:

• A large majority of receivers are now supported in the kernel using rc-core (né ir-core).
• Some receivers aren't supported (iguanaIR amongst others), and some need porting from pure input drivers to rc-core. Some functionality for the ATI Remote Wonder remotes is also not supported by the new drivers. If you're interested in working on this, drop a mail to the LIRC list.
• Mauro Chehab is making progress at propagating the key events from the kernel up to the stack to X11 applications. There's some patches in that direction on the Red Hat Bugzilla.

This means that:

• Event delivery would still need a broker in the session, to get to unfocused applications. gnome-settings-daemon can step in that role (and step out of the way when the application is focused, so the app can bring context dependent behaviour). gnome-settings-daemon already handle some of the more common multimedia keys in its media-keys plugin.
• The only configuration one would need to do is selecting the type of remote for the receiver, eventually tweaking the keymap for that remote.

So to write a replacement for gnome-lirc-properties that would fit into GNOME 3, one would need:

• A way to enumerate receivers on the machine
• A way to change the remote configuration (changing the keymap) for that receiver
• Eventually a way to tweak the keymap

This could all be handled through a D-Bus version of ir-keytable. If Mauro's patches reach X.org mainstream, then a kernel/GNOME summer of code project could be had for this work. Best to start writing some kernel patches, or laying some code if you want to get a headstart.

PS: For completeness' sake, there are also "pure" input devices that are remotes that wouldn't be handled through this. Those would need to be blacklisted in the input layer, and handled through rc-core instead.

MythTV setup

I spend a bit of time yesterday and today, in between watching footie games, setting up my Mac Mini as a MythTV machine, after having tried it out successfully on my laptop.

The low-down:

• I needed to buy a USB keyboard with a proper cable. My 2 wireless USB Logitech keyboards weren't kicking off early enough to be able to press 'C' to boot from the CD.
• Colin's guide to installing Fedora on the Mac Mini is still up-to-date, pretty much.
• Getting the display to work (ie. outputting to the TV) was a real pain. The DVI-to-HDMI output didn't work under Linux (and even if it would, it would have clipped the image to the 720p resolution, 1280x720, when the full resolution is 1280x768). The manual only advertises 1024x768 as a resolution for the VGA input, but a lot more got listed when using my laptop with the XRandR 1.2-capable drivers. 1280x768 works.
  
• Wireless works, given the right version of the firmware.
• MythTV is pretty easy to install if you follow Jarod's guide to the install (the RPM is mythtv as opposed to mythtv-suite).
• I already had the firmware for my DVB-T tuner, I don't remember where I got it...
• I wondered what the reason for no menu items was when starting MythTV, but a quick Google fixed it.

I'm sure there's plenty to be done still. I'll probably switch to a different recording solution, if Sony's PlayTV ends up being any good. Now to get recording and fill the HD up a bit.

Does anyone know where I can get screen quirks added, so that people don't struggle like I did setting X up?