It’s a bit of a Linux news day today – it happens – but this one is good news we can all be happy about. After earning a bad reputation for mishandling its Linux graphics drivers for years, almost decades, NVIDIA has been turning the ship around these past two years, and today they made a major announcement: from here on out, the open source NVIDIA kernel modules will be the default for all recent NVIDIA cards.
We’re now at a point where transitioning fully to the open-source GPU kernel modules is the right move, and we’re making that change in the upcoming R560 driver release.
↫ Rob Armstrong, Kevin Mittman and Fred Oh
There are some caveats regarding which generations, exactly, should be using the open source modules for optimal performance. For NVIDIA’s most cutting edge generations, Grace Hopper and Blackwell, you actually must use the open source modules, since the proprietary ones are not even supported. For GPUs from the Turing, Ampere, Ada Lovelace, or Hopper architectures, NVIDIA recommends the open source modules, but the proprietary ones are compatible as well. Anything older than that is restricted to the proprietary modules, as they’re not supported by the open source modules.
This is a huge milestone, and NVIDIA becoming a better team player in the Linux world is a big deal for those of us with NVIDIA GPUs – it’s already paying dividend in vastly improved Wayland support, which up until very recently was a huge problem. Do note, though, that this only covers the kernel module; the userspace parts of the NVIDIA driver are still closed-source, and there’s no indication that’s going to change.
Things are not as they seem, because instead of having closed driver and simple firmware on the GPU, they have a GIGANTIC firmware that runs all the closed stuff inside the GPU.
So instead of the kernel driver tainting the system, the GPU itself does.
I haven’t rechecked this recently, but assuming nvidia is continuing what they said they were going to do, then this is indeed smoke and mirrors. The GPU drivers are not open source. Last time I looked up the source, I was sorely disappointed with what was there. What they did was create a kernel shim and open sourced the shim only. The actual GPU drivers are closed source and interface to the now-stable shim in the kernel.
Previously linux kernel instability could cause nvidia drivers to break after kernel updates. Well, this shim fixes this by creating a stable ABI for nvidia’s proprietary drivers to connect to. The stability is good in and of itself, but for anyone who was hoping for the actual GPU drivers to be open sourced, you’ll find that nvidia still are not providing open source drivers for their GPUs. Ordinary users aren’t going to understand this distinction and I imagine nvidia are quite happy that the media aren’t reporting the details so ambiguously.
Edit: Ordinary users aren’t going to understand this distinction. I imagine nvidia are quite happy that the media are reporting “nvidia open source GPU drivers” so loosely. For FOSS development, a kernel shim falls far short.
The headline was indeed clickbait, my initial read was joy, I was even thinking improved support for Legacy hardware (Assuming there would be some benefit), but alas it’s not what it seems and little is likely to change.
Does this tell us something about the Nvidia mindset, are they really invested in supporting hardware on Linux, or is this just keeping a toe in the water just in case?
cpcf,
I don’t know. I imagine that a lot of AI is being done on linux, who knows. I like being able to use cuda on linux. Of course it is disappointing that the drivers are proprietary, but putting that aside, nvidia + X + KDE has been working very well for me. One complaint is that nvidia lacks support for reporting hotspot & memory temperatures on linux.
https://forums.developer.nvidia.com/t/request-gpu-memory-junction-temperature-via-nvidia-smi-or-nvml-api/168346
This is extremely shortsighted given how critical these temperatures are for the target demographic running heavy cuda loads. Kind of inexcusable really, but going by their official responses, they don’t seem to care about their linux devs.
Based on previous discussions. In a way you should be happy, as you got “stable ABI” in GNU/Linux kernel and most importantly the right to redistribute the blob. This is like the best you, as the end user, would get from Fuchsia, obviously minus the right to redistribute the blob, that likely would be out of the question. Yes i get it, you will nitpick, but still, this is it from practical point of view, you got your wish. Personally i am not satisfied yet, over time we should achieve more, less blob more source. But it’s a start, it’s still better then the full blob and some practical benefits will for sure be the result of it. And once you are so deeply embedded in GNU/Linux, likely yourself start to recognize the benefits of doing it more and more in GNU/Linux way.
Geck,
Before the driver was a proprietary blob, and now the driver is still a proprietary blob. I don’t like proprietary blobs, but we are no worse off than before in this respect and the stable ABI does make the drivers more reliable after kernel updates. At least that’s progress.
You’re speaking to the choir right now, you don’t need to preach to me the benefits of FOSS, I’ve always advocated for more source code. But as a pragmatist I also have to deal with reality. If FOSS is available, fantastic, I’ll take it! But when FOSS is not available, wishful thinking doesn’t fix anything. Absolute inflexibility and digging heals into ideological extremes can harm FOSS more than you realize.
Still, this is reality then, isn’t it, being pragmatic, you get the blob. Surely you don’t believe you would get anything more out of Fuchsia or Android with “stable ABI”? As we have discussed. This would be it, maximum possible. In the end achieved with GNU/Linux, on where there is still so much improvement possible, this only the beginning, bar minimum. Anyway, lets hope for things like the market, AI demand, for the experience to be as seamless as possible in the future, and regulators, granting access to CUDA due to monopoly position it has. For such things to speed thing up, when it comes to source code. Something that i guess we both desire and ultimately won’t settle for less. As in the end blob only gets you so far.
Geck,
These are two concepts are not mutually exclusive. A stable ABI doesn’t imply that FOSS drivers stop being FOSS or that proprietary drivers stop being proprietary.
Everyone can agree that proprietary drivers are a disappointment, but we already have those today and it’s been a problem for decades. We need to recognize that it’s unlikely for this situation to change. This is why I call for pragmatic solutions over ideological extremism.
Meh, you are just avoiding reality, IMHO. And how many open source device drivers are out there, for Windows? So sure, in practice, this two concepts are actually mutually exclusive. Although, said that, Fuchsia is interested in leveraging from the GNU/Linux device drivers situation, still that device drivers were never written for Fuchsia. Anyway, i will take you opinion in regards to Nvidia device driver, as your real opinion, on what you actually want to achieve in life. Contrary to the theoretical discussions we had, on where supposedly you would settle for this. “Stable ABI” plus blob. As it turns out you would never settle with this shit!
Geck,
That’s not a fair accusation, I’m the one factoring in reality. You want ideologically driven solutions that disregard it, but unfortunately that doesn’t work.
You keep trying to push a false narrative, I am not in favor of blobs and never was. You need to recognize the fact that we’ve been stuck with them for decades and there’s no sign of this changing.
Geck,
If you disagree with the outcome here, then I’d like to explicitly ask what your preferred outcome would have been and what likelihood you’d attach to that outcome.
It’s one thing to want nvidia to open source their blobs but it’s another matter altogether for it to happen in the real world. If your preferred solution doesn’t factor in the real world, then it isn’t pragmatic and it doesn’t help users.
I am just saying this is what you are basically advocating for, all along. And now when you got your wish, you instantly rejected it as inappropriate, even claiming you are against it. This is exactly on what you would get with micro kernel with a “stable ABI”. Micro kernels don’t threat device drivers as first class citizens, like GNU/Linux does. And there is absolutely no reason to believe companies would all of the sudden start open sourcing their device drivers. But if that would to ever happen, great, as we can still upstream such device drivers to GNU/Linux after. Good technological merits not much related with ideological ones. As GNU/Linux works with blobs just fine too, vendors have access to source code and as such can maintain their lines of GNU/Linux devices with binary device drivers indefinitely. If they chose so. So GNU/Linux has is covered.
Geck,
I do not advocate for blobs and I never have. I merely acknowledge that we have blobs, because that’s the reality.
Regarding the stable ABI, yes I think we’re better off for it. Even if the drivers are open source a stable ABI is STILL beneficial. It allows users to update different components independently without causing things to break. It results in more flexibility and less chaotic kernel development.
That’s exactly my point. I advocate for FOSS, but I do not advocate for the ideological extremes that would have us perpetually blocking pragmatic solutions. We need to be flexible enough to make progress where we can. Otherwise we become the villain of our own FOSS movement impeding progress. Like it or not, unstable ABI bares some of the responsibility for consumers not being able to update kernels. We have to own our role in the ewaste and planned obsolescent problems. It’s a travesty. and is why I draw the line at ideological extremism. By refusing to solve the problems (regardless of ideological rationale), we are complicit. You are complicit.
You can say it taints your system, but even Richard Stallman doesn’t seem to mind firmware. At least that’s how it used to be, he might have changed his mind obviously.
Which is interesting because I think because of the software of a printer he started this whole thing…
Anyway, as discussed, I think for Nvidia this is just a practical decision to have a stable API in the Linux kernel. This was the minimum part that Linus wanted and we now have it. Nothing else has changed.
If this is the case, wouldn’t this be good news for alternative operating systems wanting to make use of GPUs (most of the code has been offloaded to the firmware, so the other OSes only need to adapt/implement the kernel module)?
bbarker,
That’s a good point. I’m not sure how portable nvidia’s userspace tooling is. This could make things easier and more robust in operating systems like freebsd, which incidentally has some degree of linux compatibility.
https://docs.freebsd.org/en/books/handbook/linuxemu/
https://forums.freebsd.org/threads/can-cuda-be-installed-on-freebsd-now.85879/
It is an intriguing prospect and I agree this open source kernel module should help other operating systems implement nvidia’s ABI.
The question nobody’s asking, is how do they enforce hardware obsolescence with an open source driver? If you wanted to use a really old nvidia card with a new kernel today, you’re out of luck. At least as far as the official drivers are concerned. I guess you can use Nouveau. But the performance of Nouveau is not good. But then again if you are using a really old card, then you clearly don’t care about performance anyway.
Some machines are stuck with old Nvidia chips that literally cannot be upgraded, like some Imacs, or (of course) notebooks.