Linux Graphics Essay

Linux Graphics, a Tale of Three Drivers

James Bottomley
Linux Foundation Technical Advisory Board Chair and SCSI Maintainer

The purpose of this essay is to illustrate by example the strengths
and weaknesses of the open source development model versus the binary
driver one.

The three graphics drivers in question are Intel, ATI and Nvidia.
Between them they account for a majority of the graphics market (on
all operating systems, not just Linux).

History

Intel initially got into the graphics market in 1997 with the i740 graphics card. Later, in 1999 as it saw itself losing market share, it moved to the i810 integrated graphics driver trying both to leverage it’s chipset market as well as the cheapness of integrated components to remain a player in the graphics space. Starting with the i810, Intel outsourced the driver to Tungsten Graphics, but commissioned it as an open source one for Linux. Both ATI and Nvidia graphics cards initially had poor support on Linux (mainly from either very old devices whose documentation was eventually released or which were reverse engineered). Eventually, in response to the criticism from the growing Linux market, both ATI and Nvidia began to produce drivers specifically for Linux in binary form. However, for whatever reason, these Linux drivers were never as functional as the corresponding Windows drivers for the same hardware and as graphics devices have become more sophisticated and powerful, the gap between the Linux and the windows drivers has grown. It can be argued that
graphics driver problems are one of the main inhibitors to Linux desktop adoption. Certainly the number one complaint for a long time was the amount of configuration and tweaking you had to do just to get a windowing system up and running on Linux. Worse still, the fact that device coverage was spotty coupled with a lag getting drivers for the newer devices meant that given any computer, there was always a chance that the graphical windowing system wouldn’t work. Worse that chance increased drastically with brand new hardware.

Around 2005, Intel took the decision to dominate the Linux graphics market using the Open Source philosophy. It formed a team within its Open Source Technology centre to work with the community to produce and distribute drivers for all of its graphics chips which were released to the world in 2006. This strategy has been resoundingly successful in that today the best way to get a laptop that will work with Linux involves the simple question “does it have Intel integrated graphics” rather than having to get the graphics specs before purchase and check a variety of sources to see what the support is (or indeed whether it is likely to work at all). Furthermore, from Intel’s point of view it can take advantage of co-operative interactions with open source developers to get its drivers developed and tested. This is particularly advantageous from a QA cost perspective, because it allows a comparatively small team to develop and test the driver within Intel on a wide ranging (but not exhaustive) set of hardware and rely on the open source community for feedback and even fixes on other hardware in the field. This strategy allows Intel to get a much greater return on its engineering investment than if it had to employ a large team to work on supporting binary drivers in all Linux variants.

Unfortunately, using Intel integrated graphics means using Intel chipsets, which means using Intel processors, and it had low 3D performance.

ATI remained firmly in the binary driver camp up until September 2007 when, pushed by the success of Intel, its declining market share and by its acquisition by AMD to be more open source, it contracted with Novell to develop from scratch an open source version of its drivers called radeonhd. As part of this development effort it began to release publicly the documentation Novell was using to do the port. One of the side effects of this was that when there was an argument between the radeonhd team at Novell and the graphics development team at X.org (the keepers of the X window system) over the strategic and design direction of the radeonhd driver, members of the Xorg team were able to resume development of the original ati driver using the now released documentation to give it identical features to the radeonhd driver but using their design principles. In 2008 ATI recognised the value of this rival development by hiring one of the Xorg developers to work for them full time to help their Open Source driver effort.

Nvidia, at the time of writing, is still firmly in the Binary Only camp. Although there is a serious reverse engineering project called Nouveau underway to try and produce an open source driver for modern Nvidia hardware.

Where Things Stand Today

Intel and Nvidia between them account for more than three quarters of the total global graphics market. Their market shares are roughly equal and they both grew at around 40% from 4Q06 to 4Q07. AMD accounts for about one fifth of the global market and it saw its shipments sink by around by around 20% in the same period.

For Linux, the best way of demonstrating user satisfaction objectively is with the kerneloops project, which tracks reported problems with various kernels (an oops is something that’s equivalent to a panic on Unix or blue screen on windows). For instance looking at the recently released 2.6.25 kernel one can see

http://www.kerneloops.org/version.php?start=1671168&end=1703935&version=25-release

that both the binary Nvidia driver and binary ATI firegl driver account for positions in the top 15 oopses. If one follows the history, one finds that the binary drivers are always significant contributors to this list, whereas open source drivers appear and disappear (corresponding to people actually seeing the bugs and fixing them). This provides objective support for a significant kernel developer contention that it’s harder to get fixes for binary drivers. The other bright spot is that the Intel graphics drivers rarely figure at all in the list also showing that if you want graphics to “just work” then Intel is the one to choose.

However, there’s a deeper reality underlying these figures: Since most experienced Linux users know either to pick Intel or to carefully research their choice of graphics card, most of the reported oopses are coming from less experienced or even novice Linux users. The problem here is that these people quickly get frustrated with the problems which they will ascribe to Linux in general, not the problem binary driver in particular. Even worse, they may report the problem to a Linux forum only to be told that it’s a binary driver issue and can’t be fixed, thus leaving the reporter with few options to try a working Linux system beyond an expensive graphics hardware
replacement. These users aren’t likely to continue their experiment with Linux; nor will they recommend it to their friends. In fact, they’re probably turned off Linux for a considerable period (if not for life). This last is an illustration of the active harm binary modules do to the Linux ecosystem: Linux gets classified as unusable because of a problem in a binary module which no open source developer can fix.

What Can we Learn from This?

The first observation is that although Intel’s Linux Graphics strategy is undoubtedly very successful, it hasn’t been completely painless. Indeed, in the early years because there was very little public documentation for Intel chip sets, Intel had to write all the drivers themselves (although they later rectified this by releasing a lot of graphics documentation in 2008). This process is actually more complex and time consuming than initially producing a binary driver because of the reviews and feedback from the Open Source community, so the initial investment is greater. Obviously, since the drivers now work nicely, the community helps with testing and bug fixing to keep them out of the oops top ten list, the user experience is the best and the ongoing maintenance and support cost is lower, especially contrasted with a closed source driver whose authors must add glue layer after glue layer to keep up with ongoing kernel changes and which significantly adds to the cost.

Secondly, one can see that ATI was actually initially being more open than Intel since they were releasing documentation that allowed any skilled developer to write the driver (Intel released the documentation for its graphic chips up to the G35 in January 2008). One can also see that this level of openness directly precipitated a split in the driver (radeonhd vs ati), which effectively signalled ATI’s loss of control over the project. On the other hand, ATI is in the business of making money by selling hardware; as long as this happens (and it will if the ati driver is technically better than the radeonhd driver) it doesn’t need to control its own driver project (indeed controlling the project can just become a distraction). The great advantage of the Open Source development model is that it is driven by considerations of technical excellence, so if you give people enough information, they’ll not only assist you writing the driver, they’ll even help you design it. By hiring one of the Xorg developers, ATI recognises this and hopes to build on it. It will be interesting to see if ATI can leverage the steep learning curve it has climbed into greater innovation and progress in its open source driver that will allow it to start gaining on Intel.

Finally, setting aside the philosophical issues, economically it’s obvious from this data that binary drivers don’t make sense: Nvidia isn’t in the list of top oops causers as part of some grand strategy to make itself (and Linux) look bad. It’s there because the cost of doing the QA and continuous engineering to support the changing interfaces and to detect and correct these problems outweighs the revenue it can bring in from the Linux market. In essence this is because binary drivers totally negate the shared support and maintenance burden which is what makes Open Source so compelling. Additionally, there is also a drag effect these binary drivers have on the rest of the ecosystem: for instance, Fedora was under enormous pressure not to release Fedora 9 until there was a solution that allowed it to run with the Nvidia binary driver (Fedora chose to ship with a pre-release of the X windows system which Nvidia refused to support and because the driver was binary Fedora couldn’t simply fix the problems and ship anyway).

What does the Future Hold?

Obviously, if the Linux desktop suddenly took off tomorrow Intel would be perfectly poised to capitalise on its successful open source strategy, slap a “Designed for Linux” sticker on all its desktops and laptops and wait for the profits to come rolling in.

However, the current trend is for the future to go smart and mobile, with Linux becoming a strongly competitive choice in the mobile market primarily because of it’s commodity support and speed of innovation. The most commonly touted feature of the new generation of mobile devices is graphics and multi-media, so anyone with a graphics device strategy that supports Linux seamlessly and can innovate down to the low power hand held devices is nicely positioned to capitalise on an emerging market.