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]
GPU switching update

Okay I've been busy elsewhere but dragged myself back to try and finish this for upstream

v10 of the patch is up

changes are mainly that mjg59 was right about keeping ugly things in the drivers.

adding ATRM support to get the ROMs on ATI hybrid for the discrete card was actually a pain with the previous code design,
so I moved lots of it around again, and now the discrete ROM can be retrieved via the ATRM method.

I've tested it on the W500 and it works as well as before, which means still the 3rd or 4th switch fails and locks the machine up,
I need to debug this further.

The refactored code should hopefully make it easier to fill in the nvidia/nvidia and intel/nvidia blanks for mjg59.

Update 1: v11 is now up
It should fix the failure to switch to IGD the 2nd time hopefully.

Update 2: v13 is now up, it blindly implements nvidia DSM changing, but I've no idea if it works. Hopefully someone can test it and give me some feedback. Its nearly all guesswork from work mjg59 did.

One day on desktop ?


Is this system could be one day ported to desktop too ? For instance, in my PC I have a Intel G33 motherboard (D-Sub) and a Radeon HD4850 (DVI). My screen also have D-Sub and DVI. So if I connect the two GPU with the screen, it's theorically possible to use the GPU switching. Not a good idea ?


Re: One day on desktop ?

No it doesn't work like that the two GPUs are connected to the one display directly not via two different wires, and the laptop is designed to do it all.

You could just do it all in userspace on a desktop, with xorg.conf and some way to powerdown the GPU not in use.

how much if any of this work can be used for D3 / power-down'ing a video card on a system with only one graphics card?

an AMD HD4870 is someplace over 50 watts, even at idle. a 4870x2 is double that. it'd be keenly green to be able to reduce these draws to near zero, without shutting a system down.

none really its all designed around the BIOS ACPI methods.

It should be easy to expose a suspend/resume method for a GPU separate to system suspend/resume via sysfs.

How to test this?

Sounds cool, do you have any estimate when some bits are available in F13 for testing? Or what would be the required steps to do some testing now? Or too early for that?

Re: How to test this?

see the next comment, once I get it upstream I'll get a backport into F13 kernel

Thanks & HowTo

Thanks a lot for your work!
I made a small HowTo to make easier for people to test your patch:
(I will keep it updated)

Re: Thanks & HowTo


thanks for your great work !
I have a laptop asus ULV30VT (intel + discrete nvidia G 210M).
I compiled this patch (V13) on my mandriva 2010.1 x86-64 (kernel 2.6.33).
But I haven't the "vgaswitcheroo folder" in /sys/kernel/debug
(I read the howto here : http://asusm51ta-with-linux.blogspot.com/)
It's normal or abnormal ?
For information in my xorg.conf I have that :

Section "Device"
Identifier "device1"
VendorName "nVidia Corporation"
BoardName "NVIDIA GeForce 6100 and later"
Driver "nouveau"
Screen 0
BusID "PCI:1:0:0"
Option "DPMS"

Section "Device"
Identifier "device2"
VendorName "Intel Corporation"
BoardName "Intel 810 and later"
Driver "intel"
Screen 0
BusID "PCI:0:2:0"
Option "DPMS"

Thanks for your help,

Re: Thanks & HowTo

don't use an xorg.conf, make sure you are using i915 and nouveau kms drivers.

I don't think the nouveau switcinh works too well yet, file a bug on bugzilla.kernel.org against dri maybe and attach the dmesg.

Re: Thanks & HowTo

OK, I removed the xorg.conf and reboot my computer on the new kernel.
But I had the same problem, no vgaswitcheroo folder on the /sys/kernel/debug

I saw in dmesg an error (with the original 2.6.33 kernel and in the custom version) :

# dmesg | grep drm
[drm] Initialized drm 1.1.0 20060810
[drm] MTRR allocation failed. Graphics performance may suffer.
[drm] set up 31M of stolen space
fb: conflicting fb hw usage inteldrmfb vs VESA VGA - removing generic driver
fb0: inteldrmfb frame buffer device
[drm] Initialized i915 1.6.0 20080730 for 0000:00:02.0 on minor 0

I tried "CONFIG_MTTR_SANITIZER_ENABLE_DEFAULT=1" in the grub options, without effect.

And here the Xorg.0.log, I understand that the Nouveau driver isn't used :
(--) PCI:*(0:0:2:0) 8086:2a42:1043:1af2 Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller rev 7,
Mem @ 0xfcc00000/4194304, 0xd0000000/268435456, I/O @ 0x0000cc00/8
(--) PCI: (0:1:0:0) 10de:0a74:1043:1af2 nVidia Corporation rev 162, Mem @ 0xfd000000/16777216, 0xe0000000/268435456, 0xfa000000/33554432, I/O @ 0x0000dc00/128, BIOS @ 0x????????/524288
(==) Using default built-in configuration (30 lines)
Section "Device"
Identifier "Builtin Default intel Device 0"
Driver "intel"
Section "Device"
Identifier "Builtin Default vesa Device 0"
Driver "vesa"

Is there a way to force the use of "nouveau"?

Re: Thanks & HowTo

can someone with an nvidia/intel or nvidia/nvidia setup email me on
airlied at gmail.com with dmesg with i915 and nouveau kms running.

I'll try and figure it out. You definitely don't want an xorg.conf and you definitely need an X server 1.7 or greater.

Re: Thanks & HowTo

Hi, thank you it's awesome :)

I'm using Ubuntu 9.10 and Asus UL30VT (Intel/Nvidia)
Kernel 2.6.33 compiled with your patch v13 without problem but like the previous poster, i don't have any "vgaswitcheroo folder" in /sys/kernel/debug.

I missed something ?

on the fly?

I know that this switcharoo doesn't have support for this, but do you envision any way of doing this on the fly - ie. without logging out?

I'm talking about future X infrastructure to either support just hardware with on-the-fly switching support like nVidia's Optimus, or X infrastructure to somehow preserve all the state and bring X back up on a different card. (I'm thinking of an X proxy (like "screen" or "xpra"), or leveraging the xorg state tracker with two different gallium drivers underneath, ...)

I have no idea how feasible this would be, but I suspect you have a better idea...

Re: on the fly?

nvidia optimus is a completely different architecture to the current hybrid stuff.
Its probably easier to implement dynamic switching on the optimus arch under X/DRI, as you'd only run 3D apps like games on the discrete processor. Some sort of DRI enhancements, of course I've never seen the hardware so have no idea where to start.

Doing it with current X is a real pain, and X proxies are also an area that are really really hard to write since hte X server keeps so much state (like pixmaps and atoms). Lets just say the X part is about 1000 times more work, and 1000 times more intricate than this.

GPU switching

I found this landed into 2.6.34, so I immediately compiled -rc1.

On my Acer timeline 3810tg (with an Intel IGP and an external radeon hd4330), I don't get the vgaswitcheroo folder in /sys/kernel/debug. It's simply not their. I've compiled both the i915 and radeon (with kms support) into the kernel.

I've been using the lenovo_acpi module successfully so far.

Re: GPU switching

as long as you load i915 and radeon at some point, it should print in the logs
if it detects the ACPI methods.

Can you file a bug on bugzilla.kernel.org? or send me dmesg wiht i915 and radeon loaded to airlied at gmail.com