Hi Bastien, sorry for the delay. On Sat, Mar 05, 2016 at 05:31:55PM +0100, Bastien Nocera wrote: > We could, on boot, force using the integrated GPU, turning off the > discrete GPU that we're not interested in. Yes, many people "solve" this by having grub write the requisite commands to gmux' I/O ports, however this approach won't work with gummiboot. Also, the commands that need to be sent to gmux differ between retinas and pre-retinas. > So I'd push DIGD to the switch sysfs entry on boot. But I'm guessing > that won't turn off the other output we're not interested in. IGD and DIGD switch to the integrated GPU and also turn off the discrete GPU. However if the machine is already switched to the integrated GPU, the commands are no-ops and the discrete GPU is not turned off. In other words you need to check (by reading the switch file) which GPU the machine is switched to. If it's the integrated GPU, write OFF to the switch file. If it's the discrete GPU, write DIGD to the switch file. Once runtime pm works, writing DIGD is sufficient. > DIGD and DDIS should help (you need to log out/log in again), and if > the current GPU is the integrated one, you could force running, say, a > game on the discrete GPU using DRI_PRIME=1, correct? If runtime pm works, then yes. Otherwise you'd have to manually power up the GPU before using DRI_PRIME=1 and power it down afterwards. > FWIW, using OFF at runtime made my machine hang, and without any ways > for me to get debug output. Which GPU were you switched to? Did you issue the command while X11 was running? Since the machine is switched to the AMD on boot, I guess you were powering down the Intel GPU. This works on my machine, I get a log entry "i915: switched off". If this doesn't work on your machine it might be an i915 bug on your Sandy Bridge GPU or it might be because X11 is running. Try booting with "drm.debug=0xf log_buf_len=10M" and see if this gets you log output. If it doesn't, netconsole might help if the hang occurs while the console is locked. > Ok, so using GIGD or DDIS would just switch the output, but not turn > off the unused GPU without runtime PM management. No. They do switch off the other GPU if runtime pm is disabled. > > http://wunner.de/mbp_switcheroo_v5-4.5.tar.gz => gpu switching > > for 4.5 > That's the same patch that's already applied to the kernel above (the > ones from this patchset thread), right? I'm not sure, the patches in the copr repository might be an earlier test version. > My concerns here would be: > - Do we know how to turn off the integrated GPU automatically, if the > user only used the internal screen and wanted to use the discrete GPU? Runtime pm is currently disabled by default for i915. The Intel folks are on it. Until that works, the integrated GPU will be powered down when the user manually switches to the discrete GPU with DIS / DDIS and powered up when switching back with IGD / DIGD. > - If only the discrete GPU is powered on, do we know how to power on > the integrated GPU so it can drive the external screen when plugged in? On the MBP5 2008/09 and MBP6 2010, the external DP port can be switched between GPUs and we switch it together with the panel. So if you switch to the discrete GPU, you can also drive the external DP port on these models and the integrated GPU can be turned off. On the MBP8 2011 and newer, external ports are combined DP/Thunderbolt ports which can only be driven by the discrete GPU. For some reason the HPD/AUX pins of the ports can still be switched but not the other pins. We should nail these ports to the discrete GPU and not switch those pins together with the panel as we currently do. There's a patch in mbp_switcheroo_v5-4.5-runpm.tar.gz which fixes that. The patch also wakes up the discrete GPU on hotplug, which obviously needs runtime pm. > - While plymouth is short-lived at boot, Wayland and X11 GNOME sessions > use the GPU. The first user session will run on a VT that's separate > from the greeter to implement fast-user switching. So, if we wanted to > force using the other GPU for future sessions, we'd need to tell gdm to > kill its graphical session and to respawn it so it doesn't hog the GPU > and avoid the switch happening. Correct? I think so, yes. > On the 8,2, still, and with the kernel from the COPR repo[1]. > > I tried running: > echo DIGD > switch > > to (later) switch to the integrated GPU. Log out, get to gdm, log back > in to a black screen with the cursor visible and nothing else. > > I'm wondering if it's the gdm X11 session running in the background > that makes this fail. That's possible, I have no idea. I have zero issues with GPU switching on my Nvidia-based MacBook Pro, though I only switch on the console with no X11 running. On the AMD-based MBP8 that you're using, the patches have only been tested by William Brown, a colleague of yours at Red Hat Australia. If you send me dmesg output with "drm.debug=0xf log_buf_len=10M" I can see if I spot any issues. > I'd like to try and get this working properly before bringing the > runtime PM support into it. Absolutely. Best regards, Lukas _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
