Nvidia's next Linux driver to be… just as open

Big Green's software remains tricky, but Fedora and AMD are finding ways to cope

Nvidia says its forthcoming release 560 driver will be as open as releases 515 and 555 were – and will support more devices.

The latest emission from Big Green boldly states Nvidia Transitions Fully Towards Open-Source GPU Kernel Modules.

What this means is that it's continuing the 2022 move to open source its graphics drivers. As we reported at the time, some observers said this wasn't quite as open as it sounded. (We examine this in the Bootnote at the bottom.) For clarity, we are not saying it wasn't a good move: it was then, as former vulture Matt Asay wrote at the time… and it still is.

What the company is now announcing is that it's continuing the program and widening support. In 2023 Nvidia added support for newer Turing hardware. Now, the company says in a statement:

For cutting-edge platforms such as Nvidia Grace Hopper or Nvidia Blackwell, you must use the open source GPU kernel modules. The proprietary drivers are unsupported on these platforms.

For newer GPUs from the Turing, Ampere, Ada Lovelace, or Hopper architectures, Nvidia recommends switching to the open-source GPU kernel modules.

If you're using older GPUs, or a mixture, you have no choice but to continue using the monolithic proprietary drivers. Even if you have one of the modern cards that are supported, you will still need the firmware BLOBs.

How different distros handle this

This poses a problem for distros that support UEFI Secure Boot, which requires the kernel to be cryptographically signed. Ubuntu includes the drivers and a tool to install them, so it's relatively straightforward and the company documents the process.

Fedora, however, does not include proprietary elements like Nvidia's drivers. They aren't even shown as an option in the GNOME Software app-store. It's a long standing issue, but it may yet go away.

There's a new Change Proposal which will add an option for the user to self-sign the modules. The change is still being discussed, but if it's approved, it may happen as soon as Fedora 41.

Freeing CUDA from Nvidia

Apart from gamers with high-end cards, another use for Nvidia GPUs is for offloading computation to GPU chips – which can crunch lots more numbers in parallel than even a modern CPU. The Jolly Green Giant calls this CUDA, which once upon a time stood for compute unified device architecture. The more generic term is GPGPU computing.

The problem is that if you target your code at CUDA then it can only run on Nvidia chips using Nvidia's drivers. You can't run CUDA code using the all-FOSS Nouveau driver, for instance.

AMD has its own equivalent GPGPU software stack called ROCm, which lets you offload number-crunching to AMD GPUs… but again, if you target your code at ROCm then it won't run on Nvidia. If you want to retain cross-GPU portability, the company has a Hip alternative: the Heterogeneous-computing Interface for Portability. However, not all functionality is supported – for instance, inline PTX assembly language won't work.

Now a new, independent contender has entered the match: the SCALE language, from Spectral Compute. The documentation states:

SCALE is a GPGPU programming toolkit that allows CUDA applications to be natively compiled for AMD GPUs.

SCALE does not require the CUDA program or its build system to be modified.

SCALE does support inline PTX assembly, and the project also offers a comparison with rival technologies, including AMD HIP and the FOSS ZLUDA tools.

There are other offerings for non-vendor-specific GPGPU computing. The OpenCL standard has been around since 2008 and reached version 3.0 in 2020. A new rival called UXL is expected later this year.

None of this has stopped Nvidia getting to an impressive $3 trillion valuation, though. It seems to us that more competition in this area would be a good thing.

Bootnote: How open is "open"?

The hoopla about open source drivers does not mean that the entire Nvidia driver stack is now open source. It isn't. The parts that interact with the rest of the Linux OS are, but Nvidia did this by moving the proprietary parts of the code into a multi-megabyte file of "firmware", which remains closed-source and secret.

Back at the time of the release of the 515 driver, the Asahi Linux project lead Hector Martin took a look at how much of the code was now available to study. On his now-deleted Twitter account, he posted:

So Nvidia "released" their kernel driver as open source.

By which they mean, they moved most of it to firmware and made the open source driver call into it. There are almost 900 functions implemented in the 34MB firmware, give or take, from what I can see.

Broadcom vibes…

For reference, Apple's GPU firmware is ~400kB. Apple's display controller, which is a similarly insane RPC mess, is ~7MB, but most of it is data tables (~1.5MB is code).

Don't get me wrong, less blobs in the kernel is great… but open source their "driver" they did not.

At least their kernel side code is "only" 58MB of source code. AMD still takes the lead, with almost 300MB of autogenerated includes they somehow managed to upstream into the Linux kernel tree…

These large software black boxes are common practice in recent years, as we covered in 2022: Concern over growing reach of proprietary firmware BLOBs. They are so essential that the Debian project changed its 30-year-old policies and with Debian 12 started including proprietary firmware. ®