NVIDIA releases drivers with an open flavor

NVIDIA releases drivers with an open flavor

This year we’ve already seen significant leaks of NVIDIA source code and a release of open-source drivers for NVIDIA Tegra. It seems that NVIDIA decided to step it up and just released open source GPU kernel modules for Linux. The GitHub link named open-gpu-kernel-modules people were happy and we’re already testing the code, making memes and speculating about the future. This driver is currently considered experimental, only “production ready” for data center cards – but you can already try it!

Of course there are nuances. This is new code and has nothing to do with the known proprietary driver. It only works on cards from the RTX 2000 and Quadro RTX series (aka Turing and higher). The good news is that even at this point the performance is comparable to that of the closed source driver! A distinctive feature of this project – a good part of the functions that AMD and Intel drivers implement in the Linux kernel are instead provided by a binary blob inside the GPU. This blob runs on the GSP, a RISC-V core only available on Turing GPUs and younger – hence the limitation of the series. Now each GPU loads a piece of firmware, but this one is strong!

That being said, this driver already offers a more coherent integration into the Linux kernel with massive benefits that will only increase in the future. Not everything is open yet – NVIDIA’s userspace libraries and OpenGL, Vulkan, OpenCL and CUDA drivers remain closed for the time being. Ditto for the old proprietary NVIDIA driver, which I felt would rot – fitting, since that driver previously had to “rotte” generations of old but perfectly usable cards.

Upstreaming this driver will certainly be a gargantuan effort, but that’s definitely the goal and the benefits will be significant as well. Even as it is, this driver has a lot more potential. Much like a British policeman, the Linux kernel checks the license of every kernel module it loads and restricts the APIs it can use if it’s not GPL-licensed — which the previous NVIDIA driver wasn’t, since its open parts were essentially a thin layer between the kernel and the binary drivers and therefore not GPL-licensable. As this driver is MIT/GPL licensed they now have a larger set of interfaces at their disposal and could better integrate it into the Linux ecosystem instead of having a set of proprietary tools.

A GPU on a kind of riser card with a Raspberry Pi Compute Module box in front of it
Now with 65% more drivers per driver!

Debugging capabilities, security, and overall integration potential should improve. In addition, a whole range of new possibilities open up. First of all, it definitely opens the door for porting the driver to other operating systems like FreeBSD and OpenBSD and might even help free computing. NVIDIA GPU support on ARM will become easier in the future, and we could see more cool efforts to take advantage of what GPUs help us with when paired with an ARM SBC, from exciting video games to high-performance ones machine learning. Red Hat’s release says there’s still more work to be done when it comes to properly integrating NVIDIA products into the Linux ecosystem.

You will generally see that everyone welcomes this for good reason. Traditionally, we celebrate such radical moves, even if imperfect, by big companies — and rightly so, given the benefits I’ve just listed and the potential for the future. If we see more moves like this from big players, we’ll have a lot to be happy about and a lot of problems will be left in the past. However, when it comes to being open about what we value, the situation becomes kind of weird and difficult to deal with.

Openness helps us add features we need, solve problems we encounter, learn new things from the work of others, and explore the frontiers as we interact with technologies that are increasingly defining our lives. If all the exciting sci-fi literature we read as kids is to be believed, we are indeed destined to collaborate with technology. In many ways, this driver isn’t the kind of openness that helps our hardware help us, but it certainly checks a lot of boxes for what we perceive to be “open”. how did we get here

It’s a well-known fact that big companies don’t open every single piece of code – they have to hide the DRM bits and the patent violations somewhere. Here much of the code that used to reside in the proprietary driver is now running on a different CPU and is as opaque as before. No driver relies as much on binary blob code as this one, and yet, semi-irically, it’s not that far off could technically be RYF certified. It’s just that the offending binary blobs are now “firmware” instead of “software”.

Photo of a Thinkpad X200 on a desk, display showing a GRUB menu with a cute picture of the GNU mascot in the background
Something is wrong if this is seen as more open than novena

The Free Software Foundation’s RYF (Respects Your Freedom) certification, while well-intentioned, has recently garnered a lot of attention for being counterproductive to their goals and the making of hardware more complex without need and even the Libreboot project lead says its principles leave a lot to be desired. We’ve implicitly taken RYF certification as a guide to openness, which we strive for, but the Novena laptop chose not to adhere to it, and it certainly is better off. We can learn a lot from RYF and it’s clear we need more help.

From here – what do we take as “open”? And who can help us keep track of what “open” is – specifically the kind of openness that moves us to a more utopian but realistic world where our relationship with technology is healthy and loving? A few guidelines and principles help us verify that we’re staying on track – and the world has changed so much that old ideas don’t always apply, just like with the cloud-hosted software gap that’s emerging difficult to solve.

But still, a lot more code has just been opened, and that’s a win on some fronts. At the same time, we won’t get where we want to be if other companies choose to follow suit, and as hackers we won’t achieve many of the groundbreaking things that you will achieve with open source tools in our hands. And if we’re not careful, we could mistake this for the kind of openness we all come here to learn from. So it’s a mixed bag.

As mentioned, this driver is for the RTX series 2000 and beyond. Legacy cards are still limited to either the proprietary driver or Nouveau – which has been crippled by NVIDIA in the past. Case in point: NVIDIA has in recent years reimplemented key functions like clock control in a way that can only be accessed via a signed firmware shim with a closed API that’s difficult to reverse engineer, and has been uncooperative ever since – demeaning the Nouveau -Project with no damage remedy in sight. Unlike AMD, which is helping to revise the code for the cards that were released before their open driver was dropped, this issue will remain.

From here, however, Nouveau will live on. Partly it will still be usable for older maps that aren’t going anywhere, and partly it seems to be able to help replace the above userspace libraries that remain closed-source. The official NVIDIA disclosure page says it’s not impossible that Nouveau’s efforts and NVIDIA’s open driver efforts could be merged into one, a victory for all, albeit a bit bittersweet.

You might not get a GPU to run this driver on anyway due to bottlenecks. However, we will recover from the scarcity and mining-induced frenzy, and prices will come down to the point where our systems will perform better – maybe not your MX150-equipped laptop, but certainly a whole lot of powerful systems, that we have left will build. NVIDIA isn’t where AMD and Intel are yet, but they’re getting there.

[Tux penguin image © Larry Ewing, coincidentally remixed using GIMP.]

Leave a Reply

Your email address will not be published.