The Challenge In Delivering Open-Source GPU Drivers

Written by Michael Larabel in Intel on 3 January 2011 at 04:49 PM EST. 49 Comments
As illustrated today by the release of Intel's "Sandy Bridge" CPUs there is a new desire by Linux users: open-source drivers "out of the box" at launch. Over the years the expectations of Linux users have gone from simply wanting Linux drivers for their hardware to wanting open-source Linux drivers (read: no binary blobs) to now wanting open-source drivers in the distribution of their choice at the time the hardware first ships. This is a great problem to now be experiencing, as since starting Phoronix seven years ago, the Linux hardware experience has improved a great deal where it's no longer a question if there will be Linux support but when. Some hardware vendors, such as Intel, are now working towards this goal of same-day open-source Linux support -- and in some cases achieving it -- but for open-source Linux drivers for graphics it's a particularly tall hurdle to jump.

Mentioned a few times now at Phoronix, the new Intel Sandy Bridge processors and H67/P67 motherboards will largely work with any modern Linux distribution like Ubuntu 10.10 and Fedora 14. Intel's Open-Source Technology Center has been working on the Sandy Bridge support for months (it was in February of last year when I first commented on Sandy Bridge DDX driver patches being publicly available) and putting the graphics aside, you will be set with a fairly pleasant "out of the box" experience. For the graphics drivers though it's more difficult to provide this same level of support at launch for due to the architecture of the open-source GPU drivers with multiple software components in play and the release cycles for these different components.

For proper Sandy Bridge GPU support under Linux you are looking at the Linux 2.6.37 kernel, Mesa 7.10, and xf86-video-intel 2.14.0 as being the critical pieces of the puzzle while also an updated libdrm library to match and then optionally there is the libva library if wishing to take advantage of the VA-API video acceleration. All of these components are not yet in a stable release form, but will be in the coming days. Linus is expected to release the 2.6.37 kernel this week, Mesa 7.10 is about to be released late this week, and the xf86-video-intel 2.14.0 X.Org driver will be here at that point too. While the code will be available then in the released form (or you can pull it right now from Git or development snapshots), it's not as easy for end-users to actually take advantage of this until their Linux distribution of choice does their next major update, except for the rolling-release distributions like Arch and Gentoo, but those distributions are not usually for the light-hearted.

In order to see same-day support "out of the box" for Sandy Bridge graphics, in the case of Ubuntu 10.10 the Intel developers would have had to mainly meet the Linux 2.6.35 kernel and Mesa 7.9 releases of months ago. The final Sandy Bridge bits would have had to be done over six months ago when the 2.6.35 merge window was open and Mesa 7.9 was released this September. The 2.6.35 kernel merge window, which is what's used by Ubuntu Maverick, opened in early May and per the Linux kernel development process, only bug-fixes would have been allowed after that window closed. While the Linux kernel release schedule is predictable for the most part, the Mesa updates come every quarter too and are generally released by Intel's own Ian Romanick. Even if Ubuntu 10.10 shipped with "out of the box" OpenGL acceleration support for these new Intel processors, the code would have still been months out of date. There certainly would have been new features and bug-fixes the users would have wanted, like the VA-API Sandy Bridge support not going into libva until early December and the many Mesa Sandy Bridge fixes since then.

Unlike the proprietary drivers from ATI/AMD and NVIDIA or any of the drivers on the Microsoft Windows side, it's not easy to provide updated drivers post-release in distributions like Ubuntu due to the inter-dependence on these different components and all of these components being critical to the Linux desktop's well being for all users. With drivers for hardware components like wireless adapters and USB devices, it's much easier as it's generally a single driver within the kernel and the premature drivers are allowed within the kernel's staging area. Even shipping a more recent kernel in a distribution like Ubuntu would cause implications for non-Intel users when the ATI Catalyst driver often lags behind in supporting new kernel releases, the VMware and VirtualBox drivers for virtualized guests often have problems with the very latest kernels, etc.

In some aspects, it's a shortcoming of Linux with an unstable API/ABI and there also not being a stable API for Mesa (though Luc proposed such a separation between Mesa core, the drivers, and libdrm, but it was quickly shot down; see our Cleaning Up The Linux Graphics Driver Stack) where the Intel-specific bits could be selectively updated post-release in an easy manner for the user or distribution vendor without touching other graphics drivers. Instead the complete kernel and Mesa driver stack must be updated, which affects all users. We can at least be a bit thankful though that the X.Org drivers were not merged back into the X Server like was proposed by Keith Packard and others, which would have placed the additional burden of updating your entire X.Org stack (and its new dependencies) in order to use the new Intel DDX code; Luc also went as far as saying this would kill the Linux desktop. In this case we would also be waiting until X.Org Server 1.10 in February.

With Gallium3D this may eventually be a bit nicer when there is a mature Xorg state tracker for accelerating EXA and X-Video rather than being dependent upon the DDX driver, but still without an easy way to selectively update Gallium3D drivers since they live within the Mesa code-base. The DDX driver is also one of the easiest pieces to build for users or to ship as an update without potential consequences for non-Intel customers. Intel though is not currently backing a Gallium3D driver but are focusing upon investments to their existing DRI "classic Mesa" driver. This will also mean there's more work forthcoming in delivering any potential OpenCL support or for other interfaces provided by Gallium3D state trackers like OpenVG and OpenGL ES.

If the Linux desktop is to ever go truly mainstream, there will need to be "out of the box" support in modern Linux distributions or at least a sane way to update the driver stack without the risk of hosing your entire Linux installation or forcing the distribution vendors to make choices that could have negative consequences on other users. This is not a problem specific to Intel, but AMD also faces a similar issue with their open-source drivers (albeit they provide the choice to the user as well for installing the Catalyst driver, which one can easily install into an existing Linux distribution without the potential for blowing up your system). The Radeon HD 6000 series support has not yet landed in Mesa or the mainline Linux kernel DRM (Direct Rendering Manager) code-base, which would put it at the Linux 2.6.38 kernel and Mesa 7.11 as a minimum. This already rules out having nice "out of the box" 3D support for the AMD Radeon HD 6000 series graphics cards in Ubuntu 11.04, but postpones it to Ubuntu 11.10, even though these discrete GPUs have been out longer than Sandy Bridge.

Intel can at least be applauded for having their Sandy Bridge Linux support available, especially as open-source, even though it may not be easy to install at this point for most Linux desktop users -- even for (non-Phoronix) Linux journalists -- but it's progress in the right direction. In fact, it's progress like this, as to why I may be departing from my seven-year tenure in an editorial role at Phoronix to be able to better focus upon other areas of the Linux desktop with regards to the Phoronix Test Suite and its offerings.

More thoughts as they come about... I happen to be stuck in MSP at the airport with Charlie and Copper of Semi Accurate right now (four hour flight delay), of the Sandy Bridge is the biggest disappointment of the year article, so am seeing a different perspective of a normal Linux desktop user.
Related News
About The Author
Michael Larabel

Michael Larabel is the principal author of and founded the site in 2004 with a focus on enriching the Linux hardware experience. Michael has written more than 20,000 articles covering the state of Linux hardware support, Linux performance, graphics drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and automated benchmarking software. He can be followed via Twitter, LinkedIn, or contacted via

Popular News This Week