Hybrid graphics support strategy planning for Q

Registered by Timo Aaltonen

Review the current state of hybrid graphics and what's feasible for 12.10.

- base prime/dma_buf -support is now in 3.4rc
- prime sharing support for ttm/nouveau/i915 is queued for 3.5
- preliminary work towards a new driver api in the xserver has been submitted for review on 2012-05-05 (scrn->screen), 'drvmodelv3' staged in git
- randr api still being worked out, preliminary work in git

http://airlied.livejournal.com/75555.html

old blueprint for reference: https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-hybrid-graphics

Blueprint information

Status:
Complete
Approver:
Chris Van Hoof
Priority:
High
Drafter:
Timo Aaltonen
Direction:
Approved
Assignee:
Canonical Hardware Enablement
Definition:
Superseded
Series goal:
Accepted for quantal
Implementation:
Implemented
Milestone target:
milestone icon ubuntu-12.10-beta-1
Started by
Kate Stewart
Completed by
Timo Aaltonen

Related branches

Sprints

Whiteboard

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.
mlankhorst 2012-06-28: Redoing locking in i915, nouveau and radeon to prevent deadlock situations. Since every driver doing dma-buf may be affected this requires proper attention and care. Some testing done prelinary testing completed with intel synching to nouveau, but not complete yet. Argh!!

mlankhorst 2012-07-25: X1.13 will be the first X server supporting prime, together with ddx updates, mesa 8.1 and a newer libdrm with prime api support the userspace components will likely be ready in quantal. The kernel changes have proven to be harder and will likely become available in 3.7 or later, but a lot of prerequisites will
only see their first use in 3.6. Among which deferred fput, intel flushing list removal.

tjaalton 2012-09-13: Quantal has almost everything from this first push, only (unreleased) xrandr 1.4 and -ati ddx are missing. No need to provide a PPA anymore.

tjaalton 2012-10-03: Marking as implemented, all the bits that were targeted for quantal are now included.

(?)

Work Items

Work items:
[mlankhorst] make sure dmabuf synching framework is suitable for i915/nouveau: POSTPONED
[mlankhorst] review the nouveau ddx changes: DONE
[raof] Create installable package for disabling the unused GPU (see also http://pad.lv/955046 ): POSTPONED
[albertomilone] 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: DONE
[raof] Implement dma_buf stuff for radeon.ko (may be done by mlankhorst): POSTPONED
[mlankhorst] Investigate ARB_robustness in mesa (seems to be implemented already in mesa 7.11): DONE
[tjaalton] Add xrandr 1.4 (or a snapshot of master) to x11-xserver-utils: DONE

Dependency tree

* Blueprints in grey have been implemented.