hybrid-graphics-linux team mailing list archive

[Alberto Milone <alberto.milone@xxxxxxxxxxxxx>]

Blueprint changed by Alberto Milone:

Whiteboard changed:
  Background
  An increasing number of laptops contain two GPU’s, one less powerful for basic use with lower power consumption, and a more capable one for graphics intensive work. The idea is to be able to “switch” between the two depending on the workload and increase battery lifetime by using the lower power GPU when possible.
  The problem, however, is that the user experience of hybrid graphics (HG) on Linux is basically non-existent at this time.
  Hybrid Graphics Implementations
  Presently there are two hardware implementations which provide Hybrid Graphics (HG) support.
      MUXed (with multiplexers, “switchable graphics”)
  Every output has a multiplexer that both the integrated (IGP) and discrete GPU’s are connected to and depending on the workload the GPU is switched to the more appropriate GPU.
  There are several downsides to this method of implementation [1]:
      * Manual mode changes - the user is required to make the change herself.
      * Transition time - mode change can take several seconds.
      * User Experience - The GPU switch results in screen flicker.
      * Increased cost - due to the need of hardware multiplexers.
  The user experience of this method of Hybrid Graphics is not that great even on Windows, due to aforementioned issues in addition to “blocking apps”  which reserve the hardware and prevent switching until closed.
      MUXless (“OPTIMUS” -style)
  In this implementation the video output is routed via the integrated (IGP) chipset and the more intense graphics work is offloaded to the discrete GPU.
  The benefits of this implementation  are:
      * Possible to automatically enable/disable the discrete GPU
      * Near-instant transition time
      * No screen flicker
      * Less complex/expensive hardware support
  Most, if not all new machines on the market with Hybrid Graphics support are shipped with this MUXless hardware design (eg: AMD PowerXpress 4.0+). The problem is that most NVIDIA-based systems actually have the digital outputs owned by the discrete GPU in order to support three monitor environments on Windows.
  Some machines allow selecting between the integrated graphics (IGP) and the discrete GPU from the BIOS, however most ‘low-cost’ implementations do not.
  Driver Support & Availability
  The situation of drivers for Hybrid Graphics  on Linux is rather confusing to say the least. One thing is clear though: NVIDIA does not support Hybrid Graphics at all in their driver [2].
      MUXed Configurations
  For Intel and Radeon open-source drivers there is an interface available called “vga_switcheroo” which does provide the ability to “switch”between integrated and discrete GPUs. This does still require a restart of the X server, resulting in a flawed user-experience. Lastly there has been mention of forthcoming Nouveau support within vga_switcheroo [3].
  The AMD Catalyst driver has no official support, though scripts have been provided to perform the switching and mucking with the mesa/fglrx libGL flavors. This implementation similarly requires a X server restart.
      MUXless Configurations
  Ironhide/bumblebee is currently the only way to provide MUXless systems support. Presently only NVIDIA discrete GPUs are supported. It is uncertain presently if support could be implemented for ATI/fglrx.
  Current Challenges
  MUXless hardware needs support for GPU-offloading in the stack, and serious re-architecting of the X server, as Dave Airlie from Red Hat put it on his blog [4]:
  "To make this as good as Windows we need to seriously re-architect the X server + drivers. At the moment you can't load an X driver without having a screen to attach it to, I don't really want a screen for the slave driver, however I still have to have one all setup and doing nothing and hopefully not getting in the way. We'd need to separate screen + drivers a lot better. Having some sort of dynamic screens would probably fall out of this work if someone decides to actually do it."
  One additional challenge seen on most NVIDIA based MUXless configurations is that the external HDMI/DP connection is wired directly to the NVIDIA discrete GPU. This limits the end-users option to VGA connections for external video support.
  Not all the implementations of MUXless designs allow the end-user to select which GPU will be the default in the BIOS configuration. Such machines need to use ‘acpi_call’ to activate the other (what Ironhide does).
  Upstream (OSS) Schedule
  So how does the upstream schedule look so far for the opensource drivers.
      Short term ( - 6mo)
  During the next 6 months there is not much anticipated to arrive in a usable form.
      Long term (6mo - 2y)
  The kernel DRM work required for sharing GPU objects is not too complicated, according to Airlie [4].
  The biggest blocker at the moment is that the X server has limitations which prevent using GPU’s without attaching a screen to them. Airlie proposed changes to the X server on the xorg-devel mailing list [5], and he has been doing some work on this area [6].
  Upstream (NVIDIA/AMD) Schedule
  Once the X server re-architecting is finished and released, the drivers just need to add support for the new ABI  in order to work. Highly dependant on when the actual X server release is, of course. Aaron Plattner from NVIDIA has already showed  interest in helping with the redesign work [7], so it’s likely that at least NVIDIA has support for it right from the start.
  Ubuntu Schedule
  What short-term and long-term options do we have to offer at least some support for Hybrid Graphics to our users and OEMs?
      Short-Term -- Ubuntu 12.04
  see below
          Long-Term -- Ubuntu 12.10 & Beyond
  TBD: This is largely based on the development of not only Hybrid Graphics support within Xorg, but also Wayland. There has also been question as to how future Hybrid Graphics solutions will be designed at a hardware level. The current trend certainly appears to be gearing towards MUXless designs being the common choice by OEMs.
  References
  [1] http://www.nvidia.com/object/LO_optimus_whitepapers.html
  [2] http://www.nvnews.net/vbulletin/showthread.php?t=144750
  [3] http://airlied.livejournal.com/74176.html
  [4] http://airlied.livejournal.com/71734.html
  [5] http://lists.x.org/archives/xorg-devel/2011-March/020557.html
  [6] http://cgit.freedesktop.org/~airlied/xserver/log/?h=drvmodelv2-wip
  [7] http://lists.x.org/archives/xorg-devel/2011-April/021225.html
  - - - - - - - - - - - - - - - - - - -
  NOTES:
  Problems:
   - binary drivers do not coexist with builtin graphics well
   - installing the binary drivers commits you to the discrete graphics
   - sometimes outputs are only available via the discrete grahics (which may not be in use) - would like the Displays GUI to indicate possibly *why* they are not available (or at least that any but the suppored outputs ones are not available).  Also, the GUI should show pictures of the socket types to help less techincal users.
  
  Work Items:
  [hlh] Ask if AMD can make info available on how they do the config switching: TODO
  [albertomilone] Whitelist for systems we know jockey should not install nvidia proprietary on.  Some other installed by nvidia-common: [DONE by pitti]
- [albertomilone] Early boot startup script to switch the alternatives if user has switched gfx in bios: TODO
+ [albertomilone] Early boot startup script to switch the alternatives if user has switched gfx in bios: INPROGRESS
  [raof] Corner case of hybrid graphics where both cards come up and show in lspci.  Need blacklist to power down the non-loaded one.  Need to do some investigation around this: INPROGRESS
  [apulido] List of types of hybrid breakage being seen in cert testing: TODO
  [awe] Braindump on OEM experience with hybrid graphics on a wiki: TODO

-- 
Hybrid graphics support strategy planning
https://blueprints.launchpad.net/ubuntu/+spec/desktop-p-hybrid-graphics