NVIDIA Transitioning To Official, Open-Source Linux GPU Kernel Driver | #linux | #linuxsecurity

The day has finally come: NVIDIA IS PUBLISHING THEIR LINUX GPU KERNEL MODULES AS OPEN-SOURCE! To much excitement and a sign of the times, the embargo has just expired on this super-exciting milestone that many of us have been hoping to see for many years. Over the past two decades NVIDIA has offered great Linux driver support with their proprietary driver stack, but with the success of AMD’s open-source driver effort going on for more than a decade, many have been calling for NVIDIA to open up their drivers. Their user-space software is remaining closed-source but as of today they have formally opened up their Linux GPU kernel modules and will be maintaining it moving forward. Here’s the scoop on this landmark open-source decision at NVIDIA.

Many have been wondering in recent years what sort of NVIDIA open-source play the company has been working on… Going back to the end of 2019 have been signals of some sort of open-source driver effort and various rumblings have continued since that point. Last month I also pointed out a new open-source kernel driver appearing as part of the NVIDIA Tegra sources. Well, now the embargo has just expired and the lid can be lifted – NVIDIA is providing a fully open-source kernel driver solution for their graphics offerings. This isn’t limited to just Tegra or so but spans not only their desktop graphics but is already production-ready for data center GPU usage.

I’ve been super excited since being informed of NVIDIA’s open-source kernel driver plans. For covering all of the important aspects, below I’ve laid out all of the key bits for easily getting to the most exciting details of this NVIDIA open-source kernel driver effort.

What’s covered by this NVIDIA open-source initiative – NVIDIA’s open kernel modules is already considered “production ready, opt-in” for data center GPUs. For GeForce and workstation GPUs, the open kernel module code is considered “alpha quality” but will be ramped up moving forward with future releases. NVIDIA has already deprecated the monolithic kernel module approach for their data center GPU support to focus on this open kernel driver solution (and their existing proprietary kernel module using the GSP). Only Turing and newer GPUs will be supported by this open-source kernel driver. Pre-Turing GPUs are left to using the existing proprietary kernel drivers or the Nouveau DRM driver for that matter. Turing and newer is a hard requirement due to being dependent upon the GPU System Processor (GSP).

The GPU System Processor and this driver architecture that’s come about in recent times is for offloading some GPU initialization/management tasks to the GPU rather than executing on the CPU. The GSP is binary-only firmware loaded at run-time. The open-source kernel driver explicitly depends upon the GSP-supported graphics processors. The GSP is a RISC-V based block that succeeded their earlier Falcon micro-controller on earlier NVIDIA GPUs.

The kernel module components consist of the NVIDIA kernel driver, the NVIDIA-DRM integration, the NVIDIA-Modeset driver for display/mode-setting, NVIDIA-UVM for Unified Video Memory.

It’s genuine open-source kernel code – MIT/GPL dual licensed! NVIDIA has indicated that Canonical / Ubuntu, Red Hat, and SUSE are all preparing to package and use the open kernel modules. Beginning with the new R515 branch of the NVIDIA Linux driver, the driver installer will have the option for users whether they want to use the existing proprietary kernel modules or switch to the open driver code. The open kernel driver code will be available as well on GitHub. NVIDIA will also accept community contributions to the code where there is merit or bugs being addressed, but does require a CLA for signing off on the code to NVIDIA. NVIDIA’s user-space libraries and OpenGL / Vulkan / OpenCL / CUDA drivers remain closed-source — today’s announcement is just about all the excitement in kernel space.

Mainline ambitions for NVIDIA’s Linux kernel driver – It won’t go upstream though near-term / in its current form. At this point the API/ABI is not stabilized and the open kernel driver code will be tied to particular driver releases. NVIDIA is ultimately working to stabilize its API/ABI as well as the GSP firmware interface. Once they work through all these technicalities, the driver (or whatever form of it in the future) may then look at being upstreamed into the kernel. Per Linux kernel upstreaming practices, there would also need to be open-source user-space support making use of this kernel driver.

This open-source kernel code is currently split into OS-agnostic and kernel interface layer components. This stems from NVIDIA’s proprietary driver on Linux largely being shared code across Windows / Linux / FreeBSD / Solaris. For it to be upstreamed in the Linux kernel it would likely need to be more re-factored to cater to Linux, just as AMD’s DAL/DC originally had tough time upstreaming due to its numerous abstractions.

Nouveau (open-source community) prospects around this new kernel driver – Eventually, yes, Nouveau may make use of this code being opened today. Asking about it to NVIDIA, they say that hopefully Nouveau will be able to utilize the GSP firmware / open kernel modules but first will likely take time for the GSP firmware interface to be stabilized and other factors. Thus in the future when this kernel driver is in better shape, Nouveau’s Mesa code may end up interfacing with this kernel driver as an alternative to the Nouveau DRM kernel driver that is in rather rough shape for hardware newer than the GTX 600/700 Kepler series. Plus for this kernel code to be upstreamed, it would need an open user-space — i.e. Nouveau Mesa code short of NVIDIA deciding later to open up their user-space libraries.

NVIDIA’s motivation to finally be more open-source – This appears to be an effort to improve their Linux integration and support. NVIDIA’s announcement going out today says “This release is a big step in improving the experience of using NVIDIA GPUs in Linux, enabling tighter integration with the OS as well as empowering developers to debug, integrate, and contribute back.” It also looks like enterprise / data center use played a role in this strategy with also talking up confidential computing and how the data center GPU support is already considered “production” quality ahead of workstation and consumer GeForce GPU support. NVIDIA’s announcement today also will talk up the developer benefits to open-source kernel drivers with better tracing/debugging and better integration around customized versions of the Linux kernel.

Feature differences with this new kernel driver – Being an open-source kernel driver will eventually lead to some benefits — right now this open driver already has DMA-BUF support unlike their proprietary driver. But until this code is mature, there may be performance differences and other areas for improvement with the consumer / workstation hardware of “alpha” quality support. But ultimately NVIDIA says they are going to have feature and performance parity with the proprietary kernel code.

Right now this is a Linux-only change – At least as of the R515 branch, NVIDIA is only providing the open-source kernel driver support for Linux systems. I asked about FreeBSD support given NVIDIA’s long-present BSD support with their proprietary driver and whether this open-sourced code was portable enough to work on any of the BSDs. I was simply told that for R515, it’s Linux-only. We’ll see if NVIDIA later decides to open up their FreeBSD kernel GPU driver, which could also help the NVIDIA stack run on some of the other BSDs. Even still, NVIDIA’s proprietary FreeBSD driver offers the best graphics option today for FreeBSD users. The Intel and Radeon open-source graphics drivers continue to be ported over from the Linux kernel without the official backing/support of Intel or AMD and generally is always a number of releases behind the latest upstream Linux kernel state.

That’s the synopsis of what is going on with NVIDIA’s open-source kernel driver efforts. Stay tuned for NVIDIA R515 Linux driver testing and looking at the current experience and performance from using this open kernel driver with their closed-source OpenGL/Vulkan user-space drivers, etc. NVIDIA did comment to me though that “These out-of-tree open kernel modules are just one step towards better support on Linux.”

NVIDIA going back many years has provided good Linux GPU driver support, albeit closed-source (unless counting the former, minimally useful xf86-video-nv DDX)… Now they are finally venturing into an open-source kernel driver.

Congratulations to NVIDIA for finally moving forward with an open-source kernel driver solution for their range of graphics products. It’s arguably long overdue and unfortunate that they are not open-sourcing their user-space driver components, but this is a terrific move and better than the status quo. This open kernel driver is still very much a work-in-progress especially for GeForce Linux gamers but is a great start and should help in allowing better kernel integration / improved setup experience and better managing NVIDIA proprietary driver installations across distributions — once having a stable API/ABI for the driver and especially if/when the threshold is crossed of being able to upstream the kernel driver. It will also be great once the open-source Nouveau project is able to leverage GSP or this driver directly so they can just focus on their open-source Mesa driver support. Nouveau is still just limited to Gallium3D/OpenGL today and some OpenCL support but hopefully with time they will be able to provide a suitable open-source NVIDIA Vulkan driver for Mesa and all-around improving the open-source NVIDIA experience on Linux.

At least in the near-term AMD’s Radeon Linux graphics driver leads with its open-source stack for discrete graphics — both the user and kernel-space driver components being open-source and just limited to the closed-source microcode/firmware. Forthcoming Intel Arc Graphics take a similar route to AMD with fully open kernel and user space components and the proprietary GuC/HuC firmware/microcode. We’ll see how this shifts the reception among Linux gamers with just having an open kernel driver, but long-term at least should provide more suitable integration / ease of use if all goes according to their open driver development plans. Free software purists will still consider NVIDIA off-limits for lack of open-source user-space support — at least until Nouveau is adapted to use this driver and have a open Vulkan driver, etc.

Yes, the Linux gaming marketshare is small and NVIDIA likely didn’t pursue this effort just to excite open-source enthusiasts. The real play here is likely on ensuring the continued attractiveness of NVIDIA on Linux in the data center. An open kernel driver will address some concerns by organizations over security matters with a binary driver tainting the kernel and the NVIDIA module often being the only closed-source kernel driver on many Linux systems. An open NVIDIA kernel driver will also allow for better integration with new Linux features around confidential/secure computing and other areas. The big HPC customers and data center users are often much less concerned about closed-source user-space software (and often running closed-source user applications anyhow) and more concerned with quality and functionality — to which NVIDIA has a stellar reputation for CUDA and all their mature yet leading-edge user-space software for GPU compute. AMD meanwhile has the still-maturing open-source ROCm compute stack and for Intel HPC graphics everything is still coming together there with the various oneAPI efforts, so while the other vendors may have fully open-source software stacks, their compute offerings aren’t as well versed as NVIDIA’s that can now leverage an open kernel driver.

I’ve been closely following NVIDIA’s Linux driver support for nearly two decades and this is the best open-source effort they have made in this time.

As an open kernel driver, it will now be able to utilize GPL-only kernel symbols/functionality. Already this driver has DMA-BUF support that will be of interest to some enterprise / data center use. Other areas this could help out is better integration too with the HWMON subsystem, for example, to provide better integration there and using the same interfaces as used by the other open-source DRM/KMS kernel display/graphics drivers rather than right now relying on various NVIDIA-specific tools and interfaces for monitoring.

It will also be interesting to see if this NVIDIA Open GPU Kernel Modules deprecates the Nouveau DRM kernel driver… Well, it wouldn’t entirely since let’s not forget this new kernel driver only works with Turing GPUs and newer. Meanwhile the older sweet spot currently for the Nouveau kernel driver is GTX 600/700 Kepler series (and GTX 750 Maxwell1) but the newer GPUs is where it lacks proper power management firmware / re-clocking and thus the performance is in bad shape. Nouveau on recent generations of NVIDIA GPUs is basically only good enough for driving a display as due to the ability to re-clock to the peak performance state its 3D graphics performance is frankly junk. So the NVIDIA Open Kernel Driver is certainly superior for GeForce RTX 20/30 series while GTX 900 / GTX 10 graphics cards will likely be left in an awkward state outside of the proprietary driver stack.

We’ll see with time how the community contributes or not to this open-source NVIDIA kernel driver code as there’s also the CLA that may turn off some contributors. But hopefully Nouveu will embrace using this kernel driver so they can focus their efforts on open-source NVIDIA support within Mesa for improving their Gallium3D driver for OpenCL and OpenGL and hopefully moving on to making a capable Vulkan driver.

Go forth and clone from GitHub to enjoy the open-source NVIDIA kernel driver sources. The R515 Linux beta driver can be downloaded on NVIDIA.com.

If you enjoyed this article consider joining Phoronix Premium to view this site ad-free, multi-page articles on a single page, and other benefits. PayPal tips are also graciously accepted. Thanks for your support.

Original Source link

Leave a Reply

Your email address will not be published.

− three = 6