On Mon, 2016-03-14 at 13:41 +0100, Lukas Wunner wrote: > 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. Which is why I'd be fine with having user-space doing it later on. I don't think users should have to poke at the boot parameters under normal circumstances. > > 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. This isn't the greatest API, but let me make a note of that: https://github.com/hadess/switcheroo-control/issues/1 I guess that's only useful until we get runtime PM support. > > 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. Another need for run-time PM. > > 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. I'll try it out with your runtime PM patches on top of the latest upstream one. > > 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. Might explain the problems I had. > > 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. Do we have a way to know whether runtime PM is available for one/both GPUs in the machine? Otherwise this really explodes the testing grid, and it really makes everything harder. > > - 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. So that's something else that we can't handle properly without runtime PM support. > > - 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. After looking at our use cases in the GNOME wiki, I think that might not be necessary as we'll want to always run the desktop on the integrated GPU. That'll something to keep in mind if we ever want to support running the desktop on the discrete GPU. > > 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. OK. Something else to test on my MBP then. > > I'd like to try and get this working properly before bringing the > > runtime PM support into it. > Absolutely. Thanks for your help. Reading through the whole mail it seems to me that it's close to impossible to implement a decent integration without runtime PM support: - DRI_PRIME wouldn't work - no external display detection on some machines Do you have references for the i915 runtime PM support, a bugzilla or mailing-list thread? Cheers _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/intel-gfx
