Nvidia's Open-Source Linux Kernel Driver Performing At Parity To Proprietary Driver

Nvidia's new R555 Linux driver series has significantly improved their open-source GPU kernel driver modules, achieving near parity with their proprietary drivers. Phoronix's Michael Larabel reports: The NVIDIA open-source kernel driver modules shipped by their driver installer and also available via their GitHub repository are in great shape. With the R555 series the support and performance is basically at parity of their open-source kernel modules compared to their proprietary kernel drivers. [...] Across a range of different GPU-accelerated creator workloads, the performance of the open-source NVIDIA kernel modules matched that of the proprietary driver. No loss in performance going the open-source kernel driver route. Across various professional graphics workloads, both the NVIDIA RTX A2000 and A4000 graphics cards were also achieving the same performance whether on the open-source MIT/GPLv2 driver or using NVIDIA's classic proprietary driver.

Across all of the tests I carried out using the NVIDIA 555 stable series Linux driver, the open-source NVIDIA kernel modules were able to achieve the same performance as the classic proprietary driver. Also important is that there was no increased power use or other difference in power management when switching over to the open-source NVIDIA kernel modules.

It's great seeing how far the NVIDIA open-source kernel modules have evolved and that with the upcoming NVIDIA 560 Linux driver series they will be defaulting to them on supported GPUs. And moving forward with Blackwell and beyond, NVIDIA is just enabling the GPU support along their open-source kernel drivers with leaving the proprietary kernel drivers to older hardware. Tests I have done using NVIDIA GeForce RTX 40 graphics cards with Linux gaming workloads between the MIT/GPL and proprietary kernel drivers have yielded similar (boring but good) results: the same performance being achieved with no loss going the open-source route. You can view Phoronix's performance results in charts here, here, and here.

Re:

[chuckugly]

"Tests I have done using NVIDIA GeForce RTX 40 graphics cards with Linux gaming workloads between the MIT/GPL and proprietary kernel drivers have yielded similar (boring but good) results: the same performance being achieved with no loss going the open-source route."

I've never tried to game on Linux but isn't that what this is talking about?

Re:

[shoor]

I'm not a gamer, but I do fool around with blender. My question would be, does it speed up blender renders on linux?

Re:

[markdavis]

>"I'm not a gamer, but I do fool around with blender. My question would be, does it speed up blender renders on linux?"

I am neither a gamer nor a graphics animator :) But I would say "no", the point is that the open source kernel module has parity with the closed source. So they should perform the same. I would expect that, anyway, unless they made some big mistakes. The major lifting of performance is still done at the hardware level and in the closed/binary blob (firmware level), which is exactly t

One step forward

[barryvoeten]

Well I don't want to ruin the party. Of course it is nice when performance gets on par.

But to know if the driver is any good on Linux, the code must me compared to the code of other open source graphics drivers.just the code. It's cooperation. Being part of the movement.

As long as there is that guy with two middle fingers up "fuck NVIDIA", lets wait a second and have that guy come out and lower the fingers. It may take a while. And after that it may take decades for the legions to understand that the hatred

Re: One step forward

[wierd_w]

Given the nature of foss drivers, I am pleased for this release for a number of reasons.

1) There are things to be learned about nvidia gpu architectures that can be of significant value when looking to backport features, or to find areas for optimization/speedup. When nvida was clutching their pearls over their 'secret proprietary designs!', this was not really possible except through laborious trial and error. (Which is how Nouveau was developed)

2) With the groundwork made with Nouveau, combined with these

Re:

[dvice]

> As long as there is that guy with two middle fingers up "fuck NVIDIA",

That happened 2012.

In 2014, "Torvalds gives Nvidia software thumbs up":
https://www.cnet.com/tech/mobi... [cnet.com]

Where is the thumbs up?

[BlueCoder]

Please.

Not fully open source

[tlhIngan]

The driver is yes, open source, but it's basically a thin shim to the GPU. All the proprietary bits were just moved from the kernel into userspace (where they belong). So just using the "open source bits" alone will not do much beyond the basics the kernel needs for a display driver.

Everything else is done through a proprietary interface the driver has so the binary blobs (now in userspace) can talk to the card directly.

Graphics drivers consist of three layers. The upper layer is the interface HAL layer that interfaces the graphics API to the driver. The middle layer is the composition engine that takes those graphics API calls and turns them into GPU instruction lists. The last layer is the interface with hardware where those instruction lists are potentially rewritten by the GPU instruction scheduler, then passed to the GPU through an interface the open source driver exposes to do the work.

The only thing open source here is a thin basic graphics driver to drive an nVidia card. The heavy lifting has been moved to userspace and the two use a proprietary interface to talk to the card directly.

Use the driver alone and you'll get basic unaccellerated graphics. You can't go and play any 3D games or use CUDA appliations without the proprietary blobs which were moved to userspace.

Re: Not fully open source

[wierd_w]

Yuck.

On the plus side though, the binary driver shouldnt taint the kernel now.

Re:

[LordNimon]

> All the proprietary bits were just moved from the kernel into userspace

No, the bits were moved into firmware that runs on the GSP processor in the GPU.

Phoronix forums, hive of scum and villainy.

[derplord]

Reading that Phoronix forum makes my head hurt.

Some guy claims that he never had to install "any proprietary firmware for his AMD card to work", yeah you didn't but that doesn't mean it's not there. Perhaps he should look at /lib/firmware/amdgpu/ or /usr/lib/firmware/amdgpu/

Better than feature parity, it's ahead now!

[Anonymous Cward]

Phoronix notes it has heterogenous memory support with the very latest drivers, which (in simple terms) means the drivers themselves can supplement VRAM with system RAM when under load. Very recently, CUDA on Windows (with 535 and above drivers) became superior to Linux for LLM use because of this capability, as it allowed you to offload some larger models to VRAM with larger token limits which otherwise wouldn't have completely fit (with only a minor performance sacrifice).

As soon as NVIDIA fully fixes [on Linux] their broken CUDA processing support which always forces P1 without available overrides, their lack of proper NVENC/NVDEC support in mainstream apps (e.g. Web Browsers, Instant Messaging apps) and sorts out 10bit colour (or just proper dithering support) so that we don't see banding on things which look smooth/clear on other systems... then we might be able to consider this at parity with their Windows drivers.

Its not really "open source"

[jonwil]

All NVIDIA did was to move a bunch of code from the kernel driver into a massive opaque firmware blob that gets run on the card itself (which is why the "open source" driver only runs on newer cards since those are the ones with the hardware that can handle the firmware blob)

Re:

[drinkypoo]

The bulk of the driver is a closed source binary that runs in user space. The open source part is just a shim between the user space driver and the kernel. The firmware no doubt does continue to grow, but the cards continue to do more things so that's expected.

Well good. And bad.

[Plumpaquatsch]

If we should have learned anything from CrowdStrike it's not to put stuff that constantly gets updated into Kernel space.

How good is it for CUDA?

[allo]

Do CUDA users still need to proprietary one?

Re: How good is it for CUDA?

[guruevi]

No. This is talking about nVIDIA making the kernel interface to the binary blob open source. The driver bits and by extension CUDA remains closed.

The benefit of having the kernel interface open source is that it makes it very easy to ship and debug by the kernel devs rather than nVIDIA.

Re:

[allo]

But does the open driver interface work with CUDA? That isn't all that clear, given how complicated some Nvidia/CUDA setups are sometimes.

Re:

[guruevi]

Yes, the driver interface to CUDA remains the same. This is only talking about the shim between the kernel and the driver (DKMS).