Blueprint changed by Maarten Lankhorst: Whiteboard changed: UDS-Q notes: http://pad.ubuntu.com/uds-q-desktop-q-hybrid-graphics Continuation of last UDS' hybrid graphics session. What is possible to accomplish during this cycle? Currently, kernel drm subsystem feeds is complete. Most is queued for 3.5 kernel. If the binary drivers are allowed to hook into the DMA buffer modules is an open question. The outcome was that the drivers were going to remain GPL only, although they'd like other drivers to plug into that. That will either happen or it won't. Need to contact the nvidia folks to see what the status is. Won't be useful until the xserver supports it. which version? unlikely this cycle, because the changes are huge. Dave has sent a number of patches to the xorg-devel list for review. That would make it easier to actually test this. The patches decouple the X DDX from the protocol screen, so you can have multiple DDX feeding the same screen. How do you work out which GLX to load via mesa? Don't know... something we can reasonably do here. Rather than loading one GLX or the other, we'd need to load both. Switching GPUs on the fly is slightly different, but the patches should allow running one X server ... ARB robustness implementation in mesa would take about a week's work. (And needs piglit testing) Things using the desktop compositor could potentially permit some level of switching? (This should be *desperately* out of scope for Q) Another option to put effort in around some of the current temporary workarounds (Bumblebee, et al). If the proper upstream design is coming soon, then might be better focusing on that and continue encouraging community support for the temporary solutions. Another option is to put some time upstream somehow. E.g. Provide review to airlied's upstream patches. If this helps ensure the work matures quickly, this might be the lowest hanging fruit for us. How about powering off the the GPU not in use. RAOF developed a prototype to do this last cycle. It uses VGA switcharoo to turn off the one it believes is not active. Put this into package that users can opt into using? Testing in a desktop case might be feasible, using two discrete cards. Might also be possible to do an an internal + discrete combo *if* the BIOS does not shut off the Intel card when a discrete card is present (or if it can be toggled on/off) UI issues. If it looks like we'll get it for next cycle then it might be worth discussing UI design at that point. This cycle *maybe* worth collecting some rough mockups? And try to list the various usecases to aid the ui design process. open questions: - ddx patches, apparently dave has done some work on uxa support, intel is concentrating on sna: http://cgit.freedesktop.org/~airlied/xf86 -video-intel/log/?h=drvmodelv3 - acpi management with prime, currently no proposals in how to handle it - 'bbswitch' from the bumblebee project might be useful - This wiki page contains a table with working ACPI calls to turn off/on cards: http://hybrid-graphics- linux.tuxfamily.org/index.php?title=ACPI_calls (note: these calls may not be correct at all, see the huge warning on the top!) - Also, this bug report has a collection of DSDT tables: https://bugs.launchpad.net/lpbugreporter/+bug/752542 - which prime modes are possible in this and the next cycle?: http://cgit.freedesktop.org/~airlied/xserver/tree/drv/TODO?h=drvmodelv2 + + ================ + mlankhorst 2012-06-07: Following up with the linaro guys to get hopefully a good outcome on the synch api.
-- Hybrid graphics support strategy planning for Q https://blueprints.launchpad.net/ubuntu/+spec/desktop-q-hybrid-graphics _______________________________________________ Mailing list: https://launchpad.net/~hybrid-graphics-linux Post to : hybrid-graphics-linux@lists.launchpad.net Unsubscribe : https://launchpad.net/~hybrid-graphics-linux More help : https://help.launchpad.net/ListHelp