How about not showing "Gallium 0.4"? The gallium version number is rarely meaningful. Better to show the OpenGL (core context) version (which is interesting for AMD as you might have a really new mesa but don't get the highest OpenGL due to "outdated" LLVM).
Those are from glGetString (GL_RENDERER). Fix those, and you've fixed the display in the Settings panel. In short, nothing that I can, or would want to, fix from my end.
@fschwarz: Using "core context" is kind of pointless because, for instance, GTK+ will always require a core profile context by default. If you have an intel IGP and an nvidia discrete card you'd likely get the exact same title.
@Bastien: Could be useful to use GL_VENDOR instead of GL_RENDERER. But, yes: GL_RENDERER in Mesa is kind of busted for all Gallium-based renderers, and Mesa is the place to fix it appropriately.
@DimStar: I didn't even know something else existed. I have no plans to do any further work on this, and certainly not attempt to run this under fd.o, the past attempts have just been too painful.
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.
[Image]
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.
[Image]
Mooo Powaa!
This demonstration uses a slightly modifiedGtkGLArea example, which shows which of the GPUs is used to render the application in the title bar.
[Image]
on the integrated GPU
[Image]
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.
"Dual-GPU integration in GNOME"
6 Comments -
How about not showing "Gallium 0.4"? The gallium version number is rarely meaningful. Better to show the OpenGL (core context) version (which is interesting for AMD as you might have a really new mesa but don't get the highest OpenGL due to "outdated" LLVM).
26 October 2016 at 20:34
Those are from glGetString (GL_RENDERER). Fix those, and you've fixed the display in the Settings panel. In short, nothing that I can, or would want to, fix from my end.
26 October 2016 at 22:51
@fschwarz: Using "core context" is kind of pointless because, for instance, GTK+ will always require a core profile context by default. If you have an intel IGP and an nvidia discrete card you'd likely get the exact same title.
@Bastien: Could be useful to use GL_VENDOR instead of GL_RENDERER. But, yes: GL_RENDERER in Mesa is kind of busted for all Gallium-based renderers, and Mesa is the place to fix it appropriately.
27 October 2016 at 12:07
KDE also implemented a simple dbus service that only provides hasDualGPU - are there any plans to unite the two services instead of maintaining two?
Might be worthy to move it under the org.freedesktop scope?
16 February 2017 at 00:07
@DimStar: I didn't even know something else existed. I have no plans to do any further work on this, and certainly not attempt to run this under fd.o, the past attempts have just been too painful.
16 February 2017 at 03:35
Dual GPU is not working under OpenSuse Tumbleweed...
23 May 2017 at 09:06