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.
While this is not as good as an open-source GPU driver, it is nonetheless a significant progress, which cannot be dismissed as useless.
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.
Plus, I assume that this would make it possible for distributions to provide signed modules, making it much easier to use secure boot on systems with NVIDIA drivers (before you had to sign the drivers yourself after building them).
I came here to say that. This isn't an NVIDIA commitment to open source; it is a slap in the face. Rather than open sourcing the drivers, they are patching the kernel to fit the needs of their proprietary driver. Note that I'm not against proprietary software, however, title of this post was super misleading and NVIDIA needs to grow up and work on an open-source driver. The world will NOT change for them.
> 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.
That's a bit of a tired and somewhat misleading argument.
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.
This small tirade of yours is arguing against a strawman.
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.
All closed-source kernel modules and a part of the firmware blobs (those that are for devices which have communication interfaces, especially wireless interfaces, and which may access directly the memory space without being blocked by a MMU under the control of the OS kernel) are major security risks, because they might be controlled by an attacker, with no means of detection by the user.
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.
> 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.
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.
> 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.
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.)
I'm not sure why you were downvoted; this is 100% correct. Open source makes adding backdoors much more difficult, but I imagine GPU driver code is so complex that there are likely security flaws that even the entire open source community wouldn't catch. Yes, an open source driver is an improvement in many ways, but it certainly doesn't solve these problems because the attack surface is so gigantic.
I don't think, for accelerating a desktop graphics card used across your entire desktop environment, IOMMU changes my argument at all.
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.
My view is that nvidia's hardware can work however they want it to. FOSS firmware would be cool in the same way that FOSS hardware would be cool, but it's not something I expect. I also don't care that much whether the proprietary firmware is stored on on-board flash and programmed from the factory or if it's uploaded by my OS when the driver is loaded.
But I would prefer if the code I run in userspace or kernelspace is FOSS.
> I also don't care that much whether the proprietary firmware is stored on on-board flash and programmed from the factory or if it's uploaded by my OS when the driver is loaded.
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.
I think this firmwareblob vs. kernelblob vs. userspace blob needs to be decided on a case by case basis, and no strict line that shall not be crossed can be drawn anywhere. The important factor is, does their contribution help the community or not, will it allow the community to fix bugs and port stuff to a new innovative kernel, without it needing to re-implement everything from Linux?
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.
> this open-source release is nothing but a way to circumvent the GPL issues
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.
The carl firmware at https://github.com/chunkeey/carl9170fw should put that argument to rest. That is Wifi firmware source code for the Wifi I currently use.
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.
Please note that the Debian firmware-linux-free package does not build carl9170fw from source. There is proper packaging (source package called carl9170fw, binary package will be firmware-carl9170) being worked on but it isn't completed yet:
My guess - tangled code mess without clear control over ownership and bean counters not approving the work of untangling all that to open things up - it's not an easy process for huge legacy codebase.
There have been reports earlier [1] that processing power of some GPUs is suppressed by software rather than the hardware capability itself. It is frequently easier to mass produce similar chips than to have different chips for different priced devices. I had come across comments in other online forums where the users alleged that some software flags restrict the capability. I hope someone else will link those webpages if they come across them
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.
They can move those restrictions into firmware otherwise someone is going to develop a tool that unlocks the driver like people did for the Intel compiler.
Yes. Drivers represent enormous amounts of work and large parts of the overall development/IP effort in a GPU. Asking why nVidia don't open source it is like asking why they don't just open source the entire GPU. Answer: because then they'd have a much smaller and less valuable business, if they even had a business at all.
> because then they'd have a much smaller and less valuable business, if they even had a business at all.
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 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).
... and like any new software from NVIDIA it only supports the most recent generation of cards.
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.
Turing is not the most recent generation of cards.
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.
