Log in

No account? Create an account

July 2017
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31

airlied [userpic]
hybrid graphics : the story continues (part 3)

v6 of the patch + another patch which needs some work before I can merge it are available now.

This mainly cleans up the patch architecture a lot and allow for Matthew to put his nvidia code in easier hopefully. Its moves the ATPX specific code to the radeon driver.

The second patch is from an experiment that I videod on a webcam but am now failing to upload, I'll probably get a better video tomorrow, the lighting was fairly bad for it today.

It basically allows for a delayed gpu switch ( it changes the debugfs API ), and allows gpu drivers to block the switch.

The switch file now takes ON/OFF like always, but the PCI IDs input is gone. There are 4 commands

IGD - try and switch now to the integrated device - can fail if drm drivers block it (mainly if X has the device open)
DIS - try and switch now to the discrete device - can fail if drm drivers block it (X again).
DIGD - try a delayed switch to integrated device
DDIS - try a delayed switch to discrete device.

So with X running you can echo DDIS to the file and log off X, it'll then switch as soon as X closes the drm device, and when
gdm restarts X it'll be running on the discrete GPU. If we had a shiny GUI on top of this it'd be as close as MacOSX can do it.
When you select to do a delayed switch we power up the other GPU straight away so the switch is quicker.

It needs more debugging, some open issues include:

after a few switches it can die on its ass
powering up the Intel glitches the display even when running the AMD
there may be race conditions in the patch, probably need a mutex around device open + this stuff
suspend/resume - since we D3 the card, if you do an s/r cycle it'll resume it, we need a flag in the
driver to say its powered off by the mux and to ignore s/r cycles - I've started adding this to radeon.

mjg59 has access to an nvidia laptop and is looking closely at how to make that all work.


Given something like shatter or similar to divide up the work (which I understand that we don't currently have), does any fundamental hardware limitation prevent running both GPUs simultaneously to share the load? For instance, making them run different displays, or different portions of the same display?

Re: Simultaneous?

only one GPU can draw to the screen at once. I haven't tested but I think on the W500 at least you drive the displayport with radeon while the panel is run by Intel, but you'd be running a pretty fast GPU with a pretty slow and not really getting any benefits. The Linux stack is a long way from being able to utilise this stuff on two similarly powered GPUs using SLI/Crossfire, this would be a step beyond it.

Also I'm not sure what the heat implications of running the two GPUs for long periods at full whack in a laptop.

xclients reconnect?

I wonder what is the architecture problem with switching the xserver while xclients (which application actually uses) will remain intact and just reconnect to new XServer (which will be now running on another graphic adapter).

Re: xclients reconnect?

where to start...

X stores lots of information on behalf of clients - so it can't just die and restart. We've had attempts to do Xscreen before, the usually fail.

X stores pixmaps on behalf of clients - these end up in the drivers.

GLX/Direct rendering - these two are just really really hard, AIGLX might sorta
be possible to migrate, if a DRI app is running you definitely can never migrate.

different acpi calls


Just to mention that in the last year I've been compiling DSDT.dsl files which have different hybrid graphics combinations: Intel/ATI, ATI/ATI, Intel/nvidia and nvidia/nvidia:

There is now a good sample of files to inspect, and at least 5 different ways of calling the on/off method:
status = acpi_get_handle(root_handle, "\\_SB.PCI0.P0P1.VGA._OFF", &handle);
status = acpi_get_handle(root_handle, "\\_SB_.PCI0.OVGA.ATPX", &handle);
status = acpi_get_handle(root_handle, "\\_SB_.PCI0.OVGA.XTPX", &handle);
status = acpi_get_handle(root_handle, "\\_SB.PCI0.P0P2.PEGP._OFF", &handle);
status = acpi_get_handle(root_handle, "\\_SB.PCI0.MXR0.MXM0._OFF", &handle);

If someone can make packages from your patches, there is a bunch of users that are willling to test these for a wide array of laptop models.

Re: different acpi calls

all the ATPX are ATI/ATI or Intel/ATI hopefully. Though the XPTX may need investigating.

the nvidia methods mjg59 is looking at are _DCM related, not sure where they fit in with the others.

Re: different acpi calls

The _OFF methods should never be called directly. They're all abstracted behind the _DSM methods. The rest of the path is irrelevent - they're simply the ACPI representation of a PCI device.



great work!

IIRC there is a hardware switch in most of these laptops, right? Cann't we detect an event from this switch, throw a corresponding delayed command into the kernel and then just pop up a notification (via d-bus) to the user to log out to make the actual switch occur?

none of the modern ones have a hw switch at all, they are the previous generation I think.

can't merge with git

Please someone tell me which git tree is able to apply these patches? i've tried Linus' 2.6 but it doesn't work :/

Switchable on ThinkPad

Hi Dave, using a ThinkPad T500 myself also with intel + Radoen HD 3650 I wonder how you managed to start an Xserver with the BIOS in switchable configuration. Whatever I tried so far, the radeon driver always complained about no screen with a usable configuration. The intel driver crashed, but that's a different story...

Re: Switchable on ThinkPad

You need to make sure you have a distro with KMS drivers for both gpus, and not using binary drivers.