Future Tech

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

Tan KW
Publish date: Fri, 19 Jul 2024, 05:05 AM
Tan KW
0 456,596
Future Tech

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:

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 GPU. 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 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:

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. ®

 

https://www.theregister.com//2024/07/18/nvidia_drivers_remain_as_foss/

Discussions
Be the first to like this. Showing 0 of 0 comments

Post a Comment