Log in

activity wholist changelog info go back go back go forward go forward
switching graphics argh - now if you've got a pair of headphones...
you'd better get 'em on and get 'em cranked up
switching graphics argh
There's a new kind of toy that keeps showing up at the office. Laptop vendors are really starting to push multiple-GPU machines. The theory goes that you can use one low-power GPU while you're on battery, and a high-performance GPU when you're plugged into wall power. I've played with a couple of these so far and people are starting to ask about them, so I figured I'd write down what I know and what I think the plans are.

The best case is that you get a laptop like the Lenovo Thinkpad W500, where the BIOS has options controlling the GPU setup. You can pick GPU A, or GPU B, or switchable graphics. If you pick one or the other, that's all that will show up on the PCI bus, and so X will pick it up and run with it. Hooray!

If you pick switchable graphics, we'll see two GPUs on the PCI bus. And now, things get tricky. Which one is active? Well, you could look at the VGA routing bits in the PCI configuration and attempt to figure out which GPU the BIOS enabled. But on the above-mentioned Lenovo, that doesn't work, VGA is just not routed anywhere. Maybe you could look to see whether only one device has memory and i/o decoding enabled, but again, that doesn't seem to be reliable, and what do you do if there's more than one?

Ideally this is where ACPI would come to our rescue, and there'd be some platform method to call to tell us which ASIC to talk to. Maybe there is, but we haven't found it yet. Neither do we seem to get any unexpected ACPI events when switching from battery power to wall power. The Lenovo has an option in the BIOS that claims to automatically detect whether the OS supports GPU switching, but it doesn't seem to be reliable, in that if I turn detection on, I still see both chips on the PCI bus. Nonetheless this does indicate that there's some platform support there somewhere and we just need to look harder.

Of course, if you're unlucky, you got a machine like the Sony Vaio Z540, where the BIOS has no GPU options, period. If you end up in a situation where you see two video devices on PCI, just write out a minimal xorg.conf that picks the driver and the PCI slot, and hopefully things will work. If not, you have two pieces, and you can keep them or not.

Anyway, that gets you as far as doing the same boring single GPU stuff you've always done. As far as runtime switching goes, we're still pretty far off from making that a reality in the open drivers. We could hack up the relevant drivers such that we initialize them both but just only feed commands to one or the other, and then write the serialization exercise to move pixmaps and such from one to the other on switch events. Or, we might be able to start one X server on each GPU and then stick an Xdmx in front of them. In neither case will GLX work the way you expect (if at all), and there will be all kinds of fun corner cases trying to get the second chip to come up exactly compatibly with the first.

Getting this to work well should actually be a lot of fun, and there's lots of opportunity to sweep away old bad design and come up with something good.

In tangentially related news: my LCA talk was accepted! I'll be talking about shatter, which is a project to rewrite the X rendering layer to work around various hardware and coordinate limitations. This is not unrelated to the above problem, hopefully we'll get rendering abstracted far enough away from the driver to make it easier to switch among drivers at runtime.

music: local h - michelle (again)

pong! (x6) || ping?
From: notriddle Date: October 7th, 2008 03:23 pm (UTC) (link)


I know this is a silly-sounding idea, but if the card included has open specifications, maybe you could just ask how it works....
ajaxxx From: ajaxxx Date: October 7th, 2008 05:14 pm (UTC) (link)

Re: Ask?

I have. No answers yet, but at least promising noises. The thing I'm worried about is how much platform variation we're likely to encounter, it's not looking particularly standardized yet.
sneakums From: sneakums Date: October 14th, 2008 11:04 pm (UTC) (link)

runtime switching

ajaxxx From: ajaxxx Date: October 16th, 2008 05:37 pm (UTC) (link)

Re: runtime switching

Hah, awesome.
mr_thefter From: mr_thefter Date: February 10th, 2009 06:50 pm (UTC) (link)
The multi-xserver method sounds like a good stopgap measure in the meantime. Mostly, people will be using the discrete card for gaming or hidef output, which is a bit of a mutual exclusive activity, so we don't need concurrent access to the previous xserver.
Moreover, it'd be awesome if VT switching worked with this method, leading to an instant switch between, say, a fullscreen 3d app on the discrete card, and a window manager running other apps on the integrated card. That would put one over windows. =)
mr_thefter From: mr_thefter Date: March 17th, 2009 09:13 am (UTC) (link)
Something other things occurred to me.
You don't really need to decide which card to use, I think. Just pick the discrete card if available, otherwise, fallback to onboard. Any other time it's necessary to select an ASIC, it will be because of userspace (and/or driver/hw crashes, in which case, there's no consequence in autoselecting again)
As for ACPI events when wall un/plugging, you won't see any, because the EC doesn't switch the card based on AC status.
IMO, the bios option simply detects whether the OS is pre-Vista or not. It should probably be a good thing that it assumes Linux is capable (because it will, eventually!)

I think the only platform support there is is simply just powering on or off the discrete video card. If there was any other support, it'd have to be related to memory management, and if that were the case, it would be possible to support it in non-Vista OSes (but it can't, due to the driver model, which again, implies that memory management is the major part here)
Seeing as we (as in linux) are moving to GEM/TTM to get memory in-kernel, it seems we're in a good place to get support for this, as you stated.
pong! (x6) || ping?