Re: RANDR 1.4 and multiple GPUs

[Dave Airlie <airlied gmail com>]

On Sat, Feb 15, 2014 at 5:34 AM, Federico Mena Quintero
<federico gnome org> wrote:
> On Thu, 2014-02-13 at 20:52 -0500, Matthias Clasen wrote:
>
>
> > great that you are looking into this !
> > See  https://bugzilla.gnome.org/show_bug.cgi?id=704387  for previous
> > thoughts on this.
>
> Excellent, thanks!  There's a lot of good info there.  I've posted some
> questions - should we continue the discussion there?

I'll just summarize the other OSes here from what I know.

So the hardware comes in two variants, muxed and muxless. The muxed
hardware can swap the panel between the two graphics cards at runtime.
Originally all x86 Windows hw was muxed, now nearly all x86 Windows hw
is muxless. Apple always is muxed and they have a very special mux to
allow for a seamless switch.

Now you can run in muxless mode on muxed hw you just use a bit more
power and have a bit more latency copying stuff around, so we'll
probably aim for that first.

Some BIOSes let you pick Integrated/Discrete/OS picked. HW also all is
different, some hw has external outputs routed to the discrete GPU,
some hasn't, some has it routed to another mux. If you can think up a
way to screw it up, they've managed to do it.

Under windows, with OS control, with no external monitors plugged in,
you run on the integrated device, and so does the compositor. There is
a database of apps kept by nvidia and amd (not sure if MS is
involved), that trigger running on the secondary GPU. So you run a
game, if its in the database it'll get launched on the discrete GPU.
You can also override this with a right-click if memory serves. If you
plug in a second monitor and the connector is on the discrete gpu,
then windows will pivot to using the discrete GPU for the compositor.
This isn't a seamless pivot at least on Vista it looked rather ugly
and flashy, whether there was mux hw or not.

Now OSX is pretty much what you'd expect from Apple. You boot on the
integrated GPU and compositor runs on it, there is again an app
database, not sure who maintains it, most likely apple, apps on that
GPU get run on the more powerful one and compositor stays on
integrated. Plug in an external monitor, and it pivots the compositor
to the secondary GPU. Totally seamlessly, you don't even notice a
small glitch at all, only if you have a status app running would you
notice. Now Apple have a special mux that can sync up two independant
refresh rates and waits for both to end up in vblank to do the final
switch, hence the smoothness. but I've no idea how they restart and
redraw the whole compositor so fast.

So other OSes are fairly consistent on when they use the secondary
GPU, we currently do the wrong thing for when you plug in an external
monitor, and use the integrated gpu for compositing and copy results
to external GPUs. This is due to a few missing pieces to allow us to
get smooth switch operation,
X needs to handle moving rendering from one GPU to the other, I've
mostly written this, but never finished it.
we need our GL drivers to support
http://www.opengl.org/registry/specs/ARB/glx_create_context_robustness.txt
then our compositor stack would need to handle context loss, along
with knowing to restart on the other GPU, and switch X to the other
GPU.

In theory with those bits we could support a compositor pivot, but its
a fair bit of work.

Dave.