Progress toward free GPU drivers

Did you know...? LWN.net is a subscriber-supported publication; we rely on subscribers to keep the entire operation going. Please help out by buying a subscription and keeping LWN on the net.

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.

