Welcome to Ubuntu Developer Summit!
#uds-p #desktop #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

    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

    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


ACTIONS:
[tjaalton, mlankhorst] build a ppa with the new api for testing
[mlankhorst] review the nouveau ddx changes
[raof] Create installable package for disabling the unused GPU (see also http://pad.lv/955046 )
[tseliot] contact nvidia to see if they're in sync with airlied's plans/patches, and revisit the patch to expand the use of dma buffers in the kernel
Targets of opportunity:
[raof/mlankhorst] Implement dma_buf stuff for radeon.ko
[raof/mlankhorst] Port x-x-v-ati to drivermodelv3
[raof/mlankhorst] Implement ARB_robustness in mesa (seems to be implemented already in mesa 7.11)