This year, we’ve already seen the huge leak of NVIDIA source code and the release of the open-source driver For NVIDIA Tegra. It seems that NVIDIA has decided to improve this and has released the open source GPU kernel module for Linux. The name of the GitHub link open-gpu-kernel-modules People are excited, and we’re already testing the code, creating memes, and speculating about the future. This driver is currently claimed to be experimental, only “product-ready” for datacenter cards – but you can try it already!
Of course, there is nuance. This is new code, and unrelated to the well-known proprietary driver. It will only work on cards starting with the RTX 2000 and the Quadro RTX series (aka Touring and later). The good news is that the performance is comparable to that of a closed-source driver, even at this time! A special feature of this project – a good part of the features that AMD and Intel drivers apply to the Linux kernel, instead, Provided by a binary blob from inside the GPU. This blob runs on GSP, a RISC-V core that is only available for Touring GPUs and younger – hence the limitations of the series. Now, each GPU loads a portion of the firmware, but This one is heavy!
Other than that, this driver already provides a more consistent integration into the Linux kernel, with huge benefits that will only extend to the front. Not everything is open yet – NVIDIA’s Userspace Library and OpenGL, Vulkan, OpenCL and CUDA drivers are currently closed. The same goes for older NVIDIA-owned drivers, I guess, that will be left to rot – fitting, since the “left to rot” driver is what the previous generation did for older but fully usable cards.
Upstreaming this driver will definitely be a huge effort, but it will definitely be a goal, and the benefits will be huge. Even so, owning one is still beyond the reach of the average person. Unlike a British policeman, the Linux kernel checks the licenses of every kernel module it loads and restricts APIs that it can use if not GPL-licensed – which was not the previous NVIDIA driver, as its open parts were originally. A thin layer between the kernel and the binary driver, and thus not GPL-licensed. Since this driver is MIT / GPL licensed, they now have a larger set of interfaces in their hands, and can better integrate it into the Linux ecosystem without a set of proprietary tools.
Debugging capabilities, security, and overall integration prospects should be improved. In addition, many new possibilities have opened up. To get started, it must open the door to port the driver to other OS like FreeBSD and OpenBSD and Even free computing can help. NVIDIA GPU support in ARM will become easier in the future, and we will see even greater efforts to take advantage of what GPUs help us with, from exciting video games to powerful machine learning with an ARM SBC. The Red Hat Release says that much more needs to be done to properly integrate NVIDIA products into the Linux ecosystem, no stone unturned.
You will usually see that everyone is appreciating it, for good reason. The tradition is that we celebrate such radical moves, even if imperfect, from big companies – and rightly so, because of the benefits and future prospects I just listed. As we see more such moves from the big players, we will have a lot to enjoy and there will be countless problems in the past. However, when it comes to openness when we evaluate it, the situation becomes weird and difficult to deal with.
Openness helps us to add the features we need, solve the problems we encounter, learn new things from the work of others, and explore boundaries, as we interact with technology that further defines our lives. If we believe all the exciting sci-fi that we kids read, then, in fact, we want to work with technology. This driver is not, in many ways, an openness that helps our hardware, but it does check the many boxes that we perceive as “open”. How do we get here?
It is well known that every single piece of code is not what the big companies do – you have to hide DRM bits and patent infringement somewhere. Here, much of the code in proprietary drivers now runs on a different CPU instead and is as opaque as ever. No driver relies so much on binary blob code as this, and yet only semi-ironically, it’s not so far away Can technically get RYF-certified. It is true that offensive binary blobs are now “firmware” instead of “software”.
The RYF (Respect Your Freedom) certification from the Free Software Foundation, though well-intentioned, has been working against its goals and hardware development lately. More complex than necessary, And even the leader of the Libreboot project says its policies are left as desired. We have vaguely adopted RYF certification as an open guide, but Novena laptops have chosen not to comply with it and of course Relatively consistent. We have a lot to learn from RYF and it is clear that we need more help.
From here – what do we take as “open”? And who can help us keep track of what is “open” – in particular, the kind of openness that leads us to a more utopian, yet realistic world where our relationship with technology is healthy and loving? Some guidelines and policies help us check if we’re on the right track – and the world has changed enough that old ideas don’t always apply, just like the cloud-hosted software Loofhole that proves Hard to solve.
But still, many more codes have been opened, and this is a win on some fronts. At the same time, if other companies decide to stick to this example, we will not be able to get to where we want to be, and as hackers, we will not be able to achieve much that you would see us do with open-source tools. In our hands. And, if we are not careful, we can confuse it with this kind of openness that we are all here to learn. So this is a mixed bag.
As mentioned, this driver is 2000 RTX series and beyond. Older cards are still restricted to proprietary drivers or nuvets – who have a history of being hamstrung by NVIDIA. Fact: In recent years, NVIDIA has reintroduced key features such as clock control that are only accessible via a signed firmware seam with a closed API that is hard to reverse engineer, and has been uncooperative ever since – which hit the Nou project visually. Unlike AMD helping with the overhaul code for released cards before dropping their open driver, this should be a problem.
From here, Nuva will continue, however. In part, it will still be usable for older cards that are nowhere to be found, and in part, it seems to help replace the aforementioned userspace libraries that remain off-source. NVIDIA’s official release page says it’s not impossible that Nouveau’s efforts and the NVIDIA Open Driver’s efforts can be combined, a victory for all, even if a little bitter.
Due to the lack of it, you may not get a GPU to run this driver anyway. That said, we will recover from the deficit and excavation-induced insanity, and prices will drop to a point where our systems will work better – probably not your MX150-equipped laptop, but certainly not the most powerful system we have yet. Construction NVIDIA is not yet where AMD and Intel stand, but they are going.
[Tux penguin image © Larry Ewing, coincidentally remixed using GIMP.]