Sadly, it's also not the actual GPU driver, just the kernel part; you still need their massive closed blob in userspace. Almost had me excited there for a moment.
It is far more important to have open sources for all programs that are executed in privileged mode than to have the source for the programs that are executed in user mode.
The kernel can control what a user-mode program does and limit its access to any hardware resources or CPU time, but it cannot do anything against kernel modules that are executed in privileged mode.
So having the source for all the kernel modules is the main priority. With this new open-source kernel module from NVIDIA, the only closed-source kernel module used by a large number of Linux users is no longer so.
Now the main problems remain the BIOS/UEFI of the computers, which is free to override what the operating system does, due to the exceedingly stupid System Management Mode invented by Intel, and the firmware for the auxiliary CPUs that may be used for unauthorized remote management in most Intel- and AMD-based computers.
You're right that this isn't about nVidia suddenly deciding to open source anything, but it's still good for compatibility reasons.
What is this effort?
Mesa refers to https://docs.mesa3d.org/systems.html and Vulkan refers to https://en.m.wikipedia.org/wiki/Vulkan
To quote the linked blog post:
> This blog post will be a tutorial of sorts (we won't have a functioning Vulkan driver in the end, sorry)
> First off, every driver needs a name. We're not actually writing one here but it'll make the examples easier if we pretend we are. Just for the sake of example, I'm going to pick on NVIDIA because... Why not? Such a driver is clearly missing and really should happen soon. (Hint! Hint!) We're going to call this hypothetical new Vulkan driver NVK.
That said… NVIDIA did release a Vulkan driver in January 2022 which supports Vulkan 1.3 so… this blog post is slightly outdated. But it certainly does not include or reference work on an actual NVIDIA driver.
Take a look into the kernel-firmware repo, and you will see a tremendous amount of binary firmware blobs. For example the Intel micro-code blobs are protected by ~7 layers deep of encryption, wifi drivers may have government regulatory issues with sharing firmwares in anything but binary form. So let's please drop the evil binary blob nonesense...
The kernel does in fact accept small or large binary blobs, and some of them even come with source code...So I guess the key takeaway is to look at what separate the Nvidia driver/firmware from all those other binary firmware loading drivers.
Hint, it has more to do with hiding the program interface, and using abstractions within abstractions.
GP is likely referring to the userspace component of nvidia's driver, not the actual blob that gets loaded onto the gpu. If it is indeed true that you need to run proprietary userland code, then this open-source release is nothing but a way to circumvent the GPL issues that lead to nvidia's driver partially breaking in Linux 5.??.
While not ideal, I like many don't have a hard stance against loading proprietary hardware firmware blobs. I, however, absolutely take issue with running opaque user-space programs.
With a security-strengthened operating system, or with a VM/container/sandbox, it is possible to ensure that any opaque user-space program is no security risk.
I prefer very much open-source user-space programs for 2 reasons:
1. I am only seldom content with a program conceived by someone else, because usually I want to do something else than they had in mind and their program is suboptimal for my use case. When the program is open-source, that does not matter. I can modify it and combine it with other programs, to do whatever I like.
2. Whenever there are problems due to bugs, incomplete documentation or misconfigurations, if the program is open source any problem can be solved sooner or later, usually sooner. With proprietary programs, typically one gets only some incomprehensible error messages and it may happen that entire departments of IT professionals try for weeks to solve the problem, without any progress. (I had such a case last year; after upgrading an old company laptop with a new one, MS Teams stopped working; 4 or 5 IT support people distributed over 3 continents attempted to discover the cause over 2 weeks, but they all failed).
These 2 reasons make the open source programs much more desirable, but if you have to also use some opaque user-space programs for specific tasks, e.g. a Synopsys Verilog/VHDL synthesis program for designing with a FPGA, that is no big deal.
On the other hand, using an opaque kernel module which may contain either an intentional back-door or just an unintentional bug which may cause your computer to freeze exactly before saving some large piece of work, or which may corrupt you file buffers before being saved, this is much worse than the use of any opaque user-mode program.
This is absolutely not true.
It is possible to restrict an opaque user-space program to the minimal set of permissions it requires.
In this particular case, the program needs to manipulate system hardware in undocumented ways, via vendor code which is extending the kernel.
In theory this may be true. But the particular opaque user-space program is talking to a driver authored by the same team. That driver is talking to hardware that has access to all of the memory in your computer.
The odds are high that a userspace program talking to this kind of driver could make your computer do something you don't want it to do in a way that is very difficult to suss out just by reviewing the driver source code.
(I agree that an open driver is a great improvement over a closed one. But I don't think you can make any strong guarantees about the safety of the closed userspace portions of this one, yet.)
You can use IOMMU to restrict the access to the appropriate memory sections.
I believe it *does* help if, say your desktop's integrated video works natively and you have a second card you want to pass through to a gaming VM. Or if you have a server with no card shared between users and a one-card-per-user scenario.
But I would prefer if the code I run in userspace or kernelspace is FOSS.
Bingo!
Nobody cares about firmware, that's not the issue, never was... but somehow that became the narrative repeated by people who don't know what they are talking about.
Many firmware loading drivers have caused drama over the years. I'm not sure if anybody remembers when Pottering and Sievers re-worked udev to change the ordering of how firmware was loaded from user-space, trying to improve how computers booted, by graphing firmware loads, determining the loading ordering, etc... which sometimes need to happen before it's kernel driver loads, or sometimes the driver itself is able to load the firmware, or the driver begin lazy, expects udev to load the firmware after the kmod is loaded... As a result, the kernel loads firmwares itself.
I'd say the whole firmware thing needs to be put under review, with concrete rules how they are loaded, and what their interfaces has to look like, and what hardware abstraction rules actually apply.
Personally I would try to decide on blob size and scope. With nvidias driver I suspect that require massive firmware and userspace blobs, and the kernel driver is probably just a pass-through API. I would argue that this doesn't really move the community forward.
However if the blobs are small and simple, and have specific scope and a reason, like legislation or security, maybe even calibration data blobs, are useful independent of the OS itself, then I would give them a pass, since it allows the community to build upon.
If trust is the issue, you would have to open source the hardware/the silicon as well.
If trust isn't the issue, but being able to do your own things with the hardware you own, this is sth. different.
Talking about strawman arguments... that's a doozie!
Instead of ignoring your strawman, staying focused on the topic...I'm going to address this nonesense...
Firstly Nvidia is not in violation of the GPL. Secondly, nobody cares about GPL violations, most certainly not the mainline kernel community. They do not pursue blatant GPL violations, because litigation is not productive in terms of improving the kernel, but keep in mind Nvidia is not violating the GPL. Thirdly, user space libraries that interface with a kernel API are not violating the GPL. Folks are allowed to run proprietary software on Linux. Do I like that, no... I certainly don't love it. However, Nvidia running user space graphics libraries is not much different than Radeon drivers using Mesa in userspace, it's how graphics architectures work in 2022.
So it's kidna ironic you're arguing about something separate (straw-man), and even then that argument fails...
Now then, putting your tangent aside... The whole point here is to start with the kernel, and get the kernel wrapper driver that interfaces with the hardware's firmware binary interface open sourced. The whole point is to get the driver into mainline, someday... Once we have that, we can untangle the the spaghetti of graphics API libraries, perhaps even port them to Mesa. Nvidia most certainly uses an intermediary low-level graphics representation for their graphics cards, so they can support all the various graphics APi's, or what not... it's a very common pattern for graphics cards... one Radeon even fell into not long ago. So it's just a matter of time before we decode this stuff.
But you're not wrong in terms of Nvidia's overall stack being proprietary, at least for now. But that's not important, what's important is Nvidia users wont' have so much drama when their distro kernel upgrades, and they screen goes blank thanks to Nvidia's driver not being compatible with the changed kernel ABI, and the AKMOD not being able to handle it.
Easily changed likely means there's a physical knob somewhere that you could accidentially poke as a layperson.
Not that you get a three year CS education, figure out how your distribution packages dependencies, install the correct embedded toolchain (good luck), find out exactly which chip is in your device, fetch the proper firmware source code in the right version, build the thing, figure out how to flash the result onto the chip / read the Linux kernel sources to figure out the filename inside /lib/firmware. That's not easy.
Even if this entire process was packaged (it is--see <https://packages.debian.org/sid/firmware-linux-free>), it probably still doesn't count (or at least shouldn't count) as "easily" changed.
More libre fw:
https://jxself.org/git/?p=linux-libre-firmware.git;a=tree
People stop talking out of his ass.
Is it licensed, or simply too too complicated to pick apart?
Graphics is a complicated field, but the techniques could still be patented - surely their market status isn’t dependent on trade secrets?
[1] https://www.tomshardware.com/news/nvidia-gpu-system-processo...
For instance, AMD is known to sell the same actually-8-core chip as a 6-core if the transistor yield was poorer.
I believe this is a standard in the industry, right? You can theoretically unlock these cores yourself, but there's a decent chance it will break or cause other significant problems.
That's also why they split it out into two products now
"Nvidia Broadcast" is their "you bought an RTX GPU so here's a shiny toy"
And "RTX Voice" for people with GPU's dating back to the Geforce 400 series that only does it via CUDA
This does not follow. While GPU drivers are a huge development effort, they are also very specific to the hardware. This is even more true with modern APIs that are closer to how the hardware works.
AMD and Intel both have open source GPU drivers and they are still in business. Are you claiming that their business would be much bigger if not for those open source drivers?
AMD and Intel are underdogs, and benefit from open standards. Nvidia has an outright majority, and as a result their incompatible "standards" benefit them, because it forces everyone to choose between supporting Nvidia (and therefore the majority of their userbase), or "open standards" (a minority).
That will allow avoiding Nvidia blob except for the firmware.
Hopefully the GPU driver is next in their open-source roadmap.
In normal times that might be a fair way to get people to upgrade but in the last few years (when crypto bros and scalpers have gotten all the cards) it's been outright cruel.
But that aside, Turing is their first generation that a GPU System Processor (GSP) that runs the heavy binary blob that comes with the open source driver.