NVIDIA releases open-source drivers

NVIDIA releases open-source drivers

This year, we’ve already seen significant NVIDIA source code leaks and an open source driver release for NVIDIA Tegra. It looks like NVIDIA has decided to step up and just released open source GPUs for Linux. The GitHub link was named open-gpu-kernel-modules people are happy and we are already trying the code, making memes and guesses for the future. This driver is currently claimed to be experimental, just “ready to go” for datacenter cards – but you can already try it!

Of course, there is a nuance. This is a new code, and is not related to the known proprietary driver. It will only work on cards starting with the RTX 2000 and Quadro RTX series (also known as Turing onwards). The good news is that performance is comparable to a closed source driver, even at this point! A peculiarity of this project – a large part of the capabilities that AMD and Intel drivers implement in the Linux kernel is, instead, provided by a binary blob from inside the GPU. This blob runs on GSP, which is a RISC-V kernel that is only available on GPU Turing and newer – hence the series limitation. Now, every GPU loads a piece of firmware, but this is heavy!

Besides, this driver already provides more coherent integration into the Linux kernel, with huge benefits that will only increase in the future. Not everything is open yet – NVIDIA user libraries and OpenGL, Vulkan, OpenCL and CUDA drivers remain closed for the time being. The same goes for the old proprietary NVIDIA driver, which, I guess, will be left to rot – fits, as “leaving to rot” is what this driver has done in the past in generations of old but perfectly usable cards.

Upstream of this guide will definitely be a huge effort, but that is definitely the goal and the benefits will also be significant. Even so, owning one is still beyond the reach of the average person. Unlike a British police officer, the Linux kernel controls the licensing of each kernel module it loads and restricts the APIs it can use if it does not have a GPL license – something that NVIDIA’s previous driver did not have, as it was essentially open parts of a thin layer between the kernel and the binary drivers, and therefore can not be licensed GPL. Because 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 their own set of tools.

A GPU on something that looks like a lifting card of some sort, with a Raspberry Pi Compute Module frame in front of it
Now with 65% more drivers, per driver!

Troubleshooting, security, and overall integration capabilities need to be improved. In addition, there are a number of new possibilities that open up. For starters this is a great way to get started with porting your driver to other operating systems such as FreeBSD and OpenBSD, and could even help free calculation. NVIDIA GPU support for ARM will become easier in the future and we could see more interesting efforts to take advantage of what GPUs help us with when combined with an ARM SBC, from exciting video games to powerful machine learning. The release of Red Hat says that more needs to be done to integrate NVIDIA products into the Linux ecosystem properly, without any problems.

You will generally see everyone welcoming this, for good reason. The tradition is that we celebrate such radical moves, albeit imperfect, from big companies – and rightly so, given the advantages I just mentioned and future opportunities. As we see more such moves from big players, we will have a lot to be happy about and a lot of problems will be left in the past. However, when it comes to honesty about what we value, the situation becomes a bit strange and difficult to deal with.

Openness helps us add functions we need, correct problems we face, learn new things from the work of others, and explore boundaries as we interact with technology that increasingly defines our lives. If all the fascinating science fiction we read as children is believable, it’s really meant to work alongside technology. This driver, in many ways, is not the kind of aperture that helps our hardware help us, but it certainly controls many frameworks for what we perceive as “open”. How did we get here?

It is well known that opening up every piece of code is not what big companies do – you have to hide DRM bits and patent infringements somewhere. Here, much of the code that was in the proprietary driver now runs on a different CPU and is as opaque as before. No driver relies as much on binary blob code as it does, and yet only ironically, it’s not that far from where it’s located could technically obtain RYF certification. Just unacceptable binary blobs are now “firmware” instead of “software”.

Photo of a Thinkpad X200 on a desk, screen showing a GRUB menu that has a cute image of the GNU Mascot in the background
Something goes wrong if this is considered more open by Novena

RYF (Respect Your Freedom) certification by the Free Software Foundation, although it has good intentions, has recently attracted the fact that it is counterproductive in its goals and hardware construction. more complex without need, and even the Libreboot project manager says his principles are not desirable. We tacitly accept RYF certification as the openness guideline we should strive for, but the Novena Laptop has chosen not to adhere to it and it certainly is better. We have a lot to learn from RYF and it is clear that we need more help.

From here – what do we consider “open”? And who can help us to observe what is “open” – specifically, the kind of openness that leads us to a more utopian but realistic world where our relationship with technology is healthy and affectionate? Some guidelines and principles help us check if we are on the right track – and the world has changed enough that old ideas do not always apply, just as with the cloud-hosted software vacuum that turns out to be difficult to resolve.

But still, a lot more code just opened, and that’s a victory on some fronts. At the same time, we will not get where we want to be if other companies decide to stick to this example and as hackers, we will not achieve many of the groundbreaking things you will see us achieve with open source tools in our hands. And, if we are not careful, we can confuse it with the kind of openness from which we all come here to learn. So it is a mixed bag.

As mentioned, this driver is for the 2000 RTX series and beyond. Older cards are still limited to either the proprietary driver or the Nouveau – which has a history of being blocked by NVIDIA. Example: In recent years, NVIDIA has reintroduced vital features such as clock control in an accessible way only through a signed firmware with a closed API that is hard to reverse and has not worked since – something that hurt Nouveau project without treatment in look. Unlike AMD’s help in overhauling the code for cards that were released before the open driver crashed, this problem remains.

From here, however, the Nouveau will continue to live. In part, it could still be used for older cards that go nowhere, and in part, it looks like it could help replace the aforementioned user space libraries that remain closed source. The official NVIDIA release page says that it is not impossible for Nouveau efforts and NVIDIA open source efforts to merge into one, one victory for all, even one bittersweet.

Due to bugs, you may not have a GPU to run this driver anyway. That said, we will recover from the scarcity and madness caused by mining and prices will fall to the point where our systems will work best – maybe not your MX150 laptop, but certainly many powerful systems we have not yet built. NVIDIA is not where AMD and Intel are yet, but they are there.

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

Leave a Reply

Your email address will not be published.