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 dairlie'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
-- 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