User: Password:
Subscribe / Log in / New account

Progress toward free GPU drivers

Please consider subscribing to LWN

Subscriptions are the lifeblood of If you appreciate this content and would like to see more of it, your subscription will help to ensure that LWN continues to thrive. Please visit this page to join up and keep LWN on the net.

By Jonathan Corbet
March 5, 2014
The fact that a free operating system needs free drivers for the hardware it runs on would seem to be relatively easy to understand, but the history of Linux makes it clear that this is a point that must be made over and over. In recent times, one of the toughest nuts to crack in the fight for free drivers has been graphics processing units (GPUs), and mobile GPUs in particular. Recent events suggest that this fight is being won (albeit slowly), and that the way to prevail in this area has changed little in the last decade or so.

Last September, longtime holdout NVIDIA announced that it would start providing documentation to the Nouveau project, which has worked for many years to provide high-quality, reverse-engineered drivers for NVIDIA's video chipsets. That was a major step in the right direction, but things got even better in February, when NVIDIA made some initial, tentative contributions to Nouveau directly. Given that NVIDIA has been seen as the epitome of an uncooperative vendor in this area for many years, these steps marked a major change. NVIDIA is far from fully open, but there appears to be a will, finally, to move in that direction.

Another longtime purveyor of closed-source GPU drivers has been Broadcom, which, to all appearances, had no interest in cooperating with the development community in this area. So it came as a surprise to many when, on February 28, Broadcom announced the immediate release of its VideoCore driver stack under a three-clause BSD license. By all appearances, this code (and the documentation released with it) is sufficient to implement a fully functional graphics driver for a number of Broadcom's system-on-chip products, including the system found in the Raspberry Pi. Closed-source graphics drivers should soon be a thing of the past on such platforms.

Along with releasing the source and documentation, Broadcom appears to be saying that it understands the problem:

Binary drivers prevent users from fixing bugs or otherwise improving the graphics stack, and complicate the task of porting new operating systems to a device without vendor assistance. But that’s changing, and Broadcom is taking up the cause.

That said, Broadcom has not contributed a driver that will make its way upstream in the near future. What we have instead is a code (and documentation) dump that will make writing that driver possible. It is unlikely that the existing code is suitable for the mainline kernel or the user-space parts of the graphics stack; code that has lived for years behind a corporate firewall is rarely even close to meeting the community's standards. But the important part — the information on how the GPU works — is there; the community should be able to do the rest.

Of course, there are many other manufacturers of mobile GPUs, and few of them have been forthcoming about programming information for those GPUs. So the fight against binary blobs in this area will continue. In a number of cases, there are projects working toward the development of free drivers for these GPUs; see Freedreno, Etnaviv, and Lima, for example. None of those projects is yet ready to replace the vendor's binary-only drivers, but progress is being made in that direction.

These projects demonstrate one facet of what has proved to be a successful strategy against closed hardware. This is, after all, a discussion that the community has had to undertake many times with different groups of vendors. Each time around, what has appeared to work is a combination of these techniques:

  • First and foremost: make it clear that proprietary drivers are simply not acceptable to the community. These drivers receive little cooperation from developers or development projects and little love from users. The displeasure expressed by the Raspberry Pi community may have had a lot to do with Broadcom's change of heart; note that Broadcom's announcement was written by Eben Upton, co-founder of the Raspberry Pi Foundation.

  • Address vendors' excuses for not releasing their drivers. Wireless network drivers were held proprietary for years out of fears of legal problems with spectrum-regulatory agencies; over time, kernel developers made it clear that they had no interest in operating wireless devices in non-compliant ways, and those fears eventually went away. NVIDIA once claimed that the community couldn't possibly handle the complexity of a driver for its hardware; the community has proved otherwise, even when handicapped by a lack of documentation.

  • Emphasize the costs of maintaining out-of-tree code and the benefits that come from merging code upstream. A responsible company cannot shed all of its maintenance costs by upstreaming code, but it can certainly reduce them and, often, drop the maintenance of in-house infrastructure that duplicates upstream kernel mechanisms entirely.

  • When vendors refuse to cooperate, reverse engineer their hardware and write drivers of our own. As the Nouveau experience shows, these projects can be successful in creating highly functional drivers; they also often end up with the original vendor deciding to contribute to the community's driver rather than maintain its own.

  • Demand hardware with free-driver support from equipment manufactures who, in turn, will apply pressure to their suppliers. This technique worked well in the server market; there is no real evidence that companies like NVIDIA and Broadcom are responding to similar incentives in the mobile market, but certainly that kind of pressure can only help.

In the GPU market, it has long been speculated that vendors have insisted on holding onto their source as a result of patent worries. It would be hard to argue that these concerns are entirely out of line; the patent troll situation does not appear to be getting any better. But, perhaps, some recent high-profile victories against patent trolls, combined with increasing membership in organizations like the Open Invention Network, have helped to reduce those fears slightly. And, if nothing else, patent trolls, too, are able to perform reverse engineering; a lack of source seems unlikely to deter a troll with multi-million-dollar settlements in its eyes.

So we might, just maybe, be moving toward a new era where open GPU drivers will be the rule, rather than the exception. That can only lead to better hardware support, more freedom, and increased innovation around mobile devices. One thing it will not do is signal an end to problems with closed-source drivers; that particular fight seems to go on forever. But the free software community has shown many times that it has the techniques and the patience to overcome such obstacles.

(Log in to post comments)

Progress toward free GPU drivers

Posted Mar 6, 2014 20:02 UTC (Thu) by robclark (subscriber, #74945) [Link]

I just wanted to say, a BIG congrats to broadcom for showing the other mobile gpu vendors how it's done! This is the event that many of us working on r/e and writing open src drivers for mobile gpu's have been waiting for. I was surprised that it was broadcom and that it happened so quickly (expecting this to be a more prolonged fight).

If intel and AMD can open up, there is no (good) reason for mobile GPU vendors to not also open up and release docs. Nvidia/ARM/Vivante/Qualcomm/IMG, I hope you are paying attention.

Progress toward free GPU drivers

Posted Mar 7, 2014 17:30 UTC (Fri) by jhhaller (subscriber, #56103) [Link]

It's also nice to see Broadcom participating in Open Compute for their switch silicon. Dealing with setting up 3-way NDA between Broadcom and embedded OS vendors to solve problems always took some time to complete.

Progress toward free GPU drivers

Posted Mar 9, 2014 4:53 UTC (Sun) by Max.Hyre (guest, #1054) [Link]

One thing I’ve never understood about hardware suppliers is why they have’t long since recognized what a thoroughgoing win it is for them to open driver software. Aren’t they making their money selling goods? What could the availability of software lose them? (Along the same lines, why are the drivers’ licenses always so strict? Since the driver code is only useful to someone who has bought their widget, what does it matter if a copy resides on every website?) Are they somehow making money off the code itself, absent a hardware sale?

In addition to the advantages mentioned in the article, open drivers also

  • improve much faster than they possibly could with the limited in-house software team available to the company, and
  • provide the freedom of modification which could easily lead to design wins they otherwise wouldn’t realize.
Other than simple inertia (“Our software has always been a trade secret.”), I can think of only two possibilities:
  1. Fear that the availability of source would ease their competitors’ reverse-engineering of a truly significant hardware advance, or
  2. They’re doing something nefarious down there, and it would harm their relations with some three-letter (or, in Britain, four-letter) agency.
I can’t really believe in the first one—the other makers would surely do the reverse engineering if they thought there was gain to be had, and the nature or order of instruction issue couldn’t be much of a help.

Or am I too naive and/or paranoid?

Progress toward free GPU drivers

Posted Mar 9, 2014 5:16 UTC (Sun) by dlang (subscriber, #313) [Link]

> Or am I too naive and/or paranoid?

I think the answer is naive. saying the code is open and having people look at it opens them up to problems that may have been caused years ago by some low-level employee who doesn't work there any more. It's not a big risk, but it's a risk. And if you ask someone "should we do this new thing, with this risk" the automatic answer is "**** no"

There have to be strong enough benefits to outweigh the risks, and those can take time to show up.

Remember that broadcom licensed their GPU to the Pi folks without including licensing to use some of the embedded hardware decoders (mpeg2 for example), whose cost more. but you can only license use of parts of the chip separately if the code to access those portions isn't open, so opening up will translate into a loss of license revenue (and potential lawsuits from the mpeg alliance if they decide that it's broadcom's fault that people are using mpeg without them getting a cut)

it's lots of little, niggling reasons that make it hard for companies to open up.

Progress toward free GPU drivers

Posted Mar 9, 2014 17:25 UTC (Sun) by excors (subscriber, #95769) [Link]

> Or am I too naive and/or paranoid?

In this case, I think you're being paranoid. The closed-source graphics driver code is accessible to probably thousands of people, across many countries and many companies. If it was doing anything seriously nefarious, someone would probably notice, and NDAs can be violated, and at least one major international market for the product is likely to object strenuously to whichever TLA the code is being nefarious on behalf of, so it seems like a massive risk.

(And many of those people can rebuild the source and verify that it matches the binaries distributed to end users. And they have the source code for the toolchain it's built with, all the way back to the original GCC provided by their choice of Linux distro.)

If it was up to me, I'd certainly hide the nefarious code somewhere else.

> Other than simple inertia [...]

In general I think inertia is a major factor - there are lots of those little, niggling reasons to keep the status quo, but they can be overcome when some critical mass of people inside the business believe that openness is a good thing and are willing to put the effort in and can argue to the relevant decision-makers that it's worthwhile. That sounds like the situation with the Raspberry Pi - Eben Upton said "I'm an advocate of [openness] within Broadcom, as you can imagine. The trick is to present the positive business case for openness as we did in this case. Then people are often very receptive." (

Progress toward free GPU drivers

Posted Mar 9, 2014 17:24 UTC (Sun) by npitre (subscriber, #5680) [Link]

As I once wrote on this topic here:

The conclusion is: "The Open Source way always ends up prevailing eventually."

Progress toward free GPU drivers

Posted Mar 11, 2014 10:26 UTC (Tue) by jonnor (guest, #76768) [Link]

I think two important mechanisms are missing
* Presenting a specific business case on open sourcing, tailored for specific goals and overall strategy of the project/company.
* Having people on the "inside" champion open sourcing, someone who the decision makers trust and identify with.

FOSS minded individuals who work in, or consult for, companies making proprietary drivers (or software in general) are in a very good position to push in this way.

Copyright © 2014, Eklektix, Inc.
This article may be redistributed under the terms of the Creative Commons CC BY-SA 4.0 license
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds