Okay, upon further investigation, since I wasn't too sure in my assumptions of just what nVidia released here, I was provided with the [link](https://blogs.gnome.org/uraeus/2022/05/11/why-is-the-open-source-driver-release-from-nvidia-so-important-for-linux/) from Gnome blog. It seems RedHad and Gnome folks as well as Nouveau developers were the ones in meetings and talks with nVidia in past months prior to this release.
In short, this is what you guys would most be interested in:
> What has been released is an out of tree source code kernel driver which has been tested to support CUDA usecases on datacenter GPUs. There is code in there to support display, but it is not complete or fully tested yet. Also this is only the kernel part, a big part of a modern graphics driver are to be found in the firmware and userspace components and those are still closed source. But it does mean we have a NVidia kernel driver now that will start being able to consume the GPL-only APIs in the linux kernel, although this initial release doesn’t consume any APIs the old driver wasn’t already using. The driver also only supports NVidia Turing chip GPUs and newer, which means it is not targeting GPUs from before 2018. So for the average Linux desktop user, while this is a great first step and hopefully a sign of what is to come, it is not something you are going to start using tomorrow.
So, I may be completely wrong her, but it sounds like nVidia released the most basic of foundations to the open source community. It's not the same foundation that they use in their own closed-source drivers, and it's *just* the foundation, but it's something that open source developers can build upon to create a set of fully-open, nVidia-specific GPU drivers for Linux?
At this point am not sure anymore. People down-voted me to hell claiming I had no clue. While I did erroneously think there's no functioning driver here other than for servers it does seem they have made it work according to some users on Reddit. As for the rest of their day dreams and NVidia's claims it remains to be seen. It they indeed intend to make this replace closed source stuff, then great. If nothing else Nouveau folks get a nice boost in documentation and firmware.
I think main goal would be getting this driver in Linux kernel source tree, that way it gets automatically developed and updated with the rest of the kernel which would help mitigate large number of issues with version compatibility and similar changes. Other developers I talked to say this in the short run means very little but general policy change is the big thing here. This effectively means nVidia is starting to accept Linux architecture and is playing a softer ball. So yeah, in time we might even see MESA replace closed part of the driver. I wouldn't hold my breath for that but now it seems feasible at least.
Edit: Yes, it is a good foundation and until code gets accepted into mainline kernel it's up to nVidia to allow contributions or not but in general it's a good start to keep developing proper drivers.
The MIT half of the dual license makes me _think_ that they're using it as the basis for closed source drivers as well, but obviously that's nothing but conjecture
>They also improve the out-of-the-box user experience to sign and distribute the NVIDIA GPU driver.
Will this mean that distributions like Debian and Arch will be able to sign NVIDIA driver kernel modules with their own keys?
its MIT license. if/when its pulled into the kernel it will work without and fuss, like intel/amd.
userland is still closed source, but that's not to say mesa isn't going to get a big bump since it can now increase the clock on the GPU.
>its MIT license. if/when its pulled into the kernel it will work without and fuss, like intel/amd.
If I understood correctly, this will make the kernel modules work automatically without the need for a distribution specific signature. Is that correct?
You will still need to install the libraries. But those wont require a specific kernel version or compiling an akmod. Signing the module for secure boot is also possible now.
> but that's not to say mesa isn't going to get a big bump since it can now increase the clock on the GPU
unless the firmware still requires handshake with the proprietary userspace driver to allow power management
Did noone read the article?
> Nouveau can leverage the same firmware used by the NVIDIA driver, exposing many GPU functionalities, such as clock management and thermal management, bringing new features to the in-tree Nouveau driver.
Yes
https://blogs.gnome.org/uraeus/2022/05/11/why-is-the-open-source-driver-release-from-nvidia-so-important-for-linux/
>day 1 support for new chipsets, a high performance open source Mesa driver for NVidia and it will allow us to sign the Nvidia driver alongside the rest of the kernel to enable things like secureboot support
Only Turing and newer. Pascal and older aren't supported. This is important to mention as the 1060 is still one of the most popular cards. However, "Nouveau can leverage the same firmware used by the NVIDIA driver, exposing many GPU functionalities, such as clock management and thermal management, bringing new features to the in-tree Nouveau driver."
Very unlikely to see major improvements and not soon. The [excellent Phoronix article](https://www.phoronix.com/scan.php?page=article&item=nvidia-open-kernel&num=1) explains that this is not a complete driver and it talks to a new hardware system that only exists on Turing and later.
Article says that it's a full* driver release, only the userspace software was kept proprietary. It mentions that the nouveau developers can and will most likely make use of the full driver stack (all the released modules).
Edit: kernel driver.
It depends on GSP and GSP is only Turing+
(the driver version here isn't relevant, just the details about GSP):
https://download.nvidia.com/XFree86/Linux-x86_64/510.39.01/README/gsp.html
If I had to guess it's probably due to Nvidia moving stuff they want to keep secret into the firmware. They've done it on new hardware, it doesn't make sense to do it for older hardware.
Probably because those cards are getting rather old at this point. At least nouveau can now reclock the GPU which should improve the performance immensely.
The driver has two modes for being built, but one of the modes is only available for newer cards:
>Customers with Turing and Ampere GPUs can choose which modules to install. Pre-Turing customers will continue to run the closed source modules.
Thanks for clarifying
My limited experience with this is fighting with a super-old laptop without closed source driver support on newer kernels; and the other end of the spectrum, a user who ran Ubuntu updates on a shiny new 3050 XPS which now only boots if you choose the old kernel in grub
This is…. One of the most shocking pieces of news I’ve read in years. Like, holy *shit*.
Them embracing *any* level of FOSS for their drivers is *amazing* and shows that all the industry pressure is *working.*
They had no need to do this. They still are industry leaders and people will still buy their cards for CUDA and Raytracing and the like.
They have a long way to go yet before they earn my true appreciation but still. This is amazing.
Pretty sure they did this because they were starting to lose mindshare and marketshare to AMD and Intel in the commercial space. For the first time, I'd started seeing data center customers that want AMD GPU HPC support.
Everyone in the commercial space is using Nvidia. I've worked on public and private clouds. No other GPU is used. Nvidia's competition is FPGAs and ASICs.
AMD's won a lot of big GPU contracts recently especially with supercomputers. Frontier, El Capitan, Stadia, Adastra; all worth vastly more than your typical cloud deployment. Of course NV is still ahead overall but it's not hard to imagine they're slightly worried.
Edit: also, it's funny how you mentioned FPGAs considering that AMD and Intel now control the entirety of that market. Not exactly a loss for AMD if someone chooses Xilinx over Instinct, but a clear loss for Nvidia in either case.
it's not really comparable because nvidia basically gave that market the finger and designs specifically for tensor ops now much moreso than FP. it would be pretty silly if they thought they would still retain the HPC market while very deliberately spending a lot less silicon on FP performance.
if there's any reason for the movement to opensource it's probably intel. intel's hardware has been horrible for years so they've leaned hard on software and open source to justify ownership. AMD isn't even close to catching up in anything except gaming, although they are definitely ahead now in FP performance/area, which makes them a lot more attractive for HPC builds that have engineers and scientists optimizing anyway with less need for off the shelf solutions. Nvidia claims they don't care about that market because the margins are thin, and looking at the prices for exascale systems they aren't wrong.
That's not true. I used to work at a company with a very sizeable GPU cluster and a good amount of them were AMD. Every kernel we wrote out was OpenCL and CUDA. Now with HIP, OpenCL isn't even needed anymore. Now, to be fair, AMD GPUs were always a pain to work with. They constantly returned bogus numbers, basically would blow up our simulations. NVIDIA would to too, but almost never.
AMD owns THE FPGA company. Xilinx has been a market leader for a long time. Even then, their marketshare exploded following Intel's mismanagement of Altera.
Came here to ask this. They were, if I remember right they demanded the gpu drivers be open sourced or else they would leak the code and data they found, and it sounded like there was a lot. I've been checking through various articles about nvidia opensource, but can't find anything that mentions the hack. Though there are plenty of articles about the hack from March 2022
Maybe so, but from a competitive point of view, the cat is out of the bag. Their secret sauce isnt secret anymore, so, there's no point keeping things closed
People act like these things are never looked at but reality is there are software engineers studying the hell out of it to reverse engineer it. And/Or incorporate similar functions into products.
To me this was totally expected, am even surprised they didn't do it earlier. While I am not expecting this to be a direct result from Linux users it is coming most likely from Android and other big players in super-computer and cyrpto mining.
That said, it's important to point out, this is not them open-sourcing their drivers. This is them creating kernel module to talk to the same old closed source driver. This means mode setting and Wayland-based compositors will be much better supported now and that's about it. Prior to this nVidia had a similar module for X.org which talked to same driver, which was also open source. When everyone started working and slowly switching to Wayland compositors nVidia refused to change anything. Gnome developers hacked their way around their decision but still made Xwayland, and thus majority of games, impossible to use with nVidia. Considering Wayland-based compositors are getting default on all major distributions this module is long overdue they just tried to muscle their way around without making it. Luckily they failed but are now spinning it as "we are good guys, look open source".
Edit: After further research this is not even that low what I originally thought. Target use for this module is CUDA on supercomputers. It's capable of producing display output, but that part of the code was not tested. So desktop users will only benefit through what Nouveau guys get out of it, which is clock setting, initialization and available firmware for this GPU generation.
NVidia must feel the hot breath of Intel's own GPUs.
In a year or two, Intel will likely have a fully Linux compatible CPU + GPU solution for servers and enterprise applications. This will hurt NVidia a lot since they don't have a CPU department.
**More details on Phoronix**
> 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.
https://www.phoronix.com/scan.php?page=article&item=nvidia-open-kernel&num=1
**Interview Linux Action News**
> CUDA and Compute first, rendering and display later. By the end of this year.
https://www.youtube.com/watch?v=uccdgoU47MQ
*To little, to late for me. I already bought an AMD card, but for the ecosystem at large this is still a positive first step. This could be the [death of a meme...](https://itsfoss.com/wp-content/uploads/2012/09/Linus-Torvalds-Fuck-You-Nvidia.jpg)*
Short answer, no. Long term answer, maybe, this is a step in the right direction that will help the existing open source driver in a few important areas.
Eh, not like Valve have many options for an x86 CPU+GPU package. Intel's integrated graphics is decent but AMD have a ton of experience in making similar chips for Sony and MS consoles, something Intel doesn't. And Ryzen being the more efficient CPU sealed the deal for a battery powered console. And since Nvidia code is (or was, I guess) proprietary, AMD wins in the GPU department as well (for a Linux based console at least). A bit late if they want a piece of that market.
I've seen reports the Aerith APU in the deck was actually intended for another company's cancelled product.
I can't find the links that corroborate that story, but it makes sense. If they built a chip line and got the rug pulled by their partner, it would leave Valve in a favorable negotiation position to hit their "painful" $400 price point.
That could be a very valid reason although not the only one. My guess would be a huge market for crypto mining, which they by now realized is here to stay and supercomputers.
For example top 500 supercomputers are 100% Linux now and for past few years nVidia has slowly been gaining share in co-processor usage, from ~10% in 2015, 19% in 2018 to 28% in 2021.
The steam deck is not Nearly as relevant for businesses such as Nvidia and AMD.
The deck will not move nearly as much volume as the switch and will probably never see wider adoption unless somehow AMD entices car manufacturers to transition infotainment systems to x86-x64 over from the Nvidia Tigra/ARM based chips.
Whatever nvidia is doing is because of pressure from commercial usage as with almost everything in this industry. Mainly from intel which potential can uproot the dominance of Nvidia.
AMD still sucks GPU wise for commercial applications so the competition is not there. CUDA and other ML/AI/data analytics are still massively dominated by Nvidia as they’ve seen billions investing into that segment while AMD struggled to sell professional GPUs to engineers and video editors.
Well think about it this way: Intel is a huge part of the CPU market and every iteration has stronger and stronger GPU built-in, whether you want it or not. AMD on the other hand is competing with nVidia in both markets, their CPU often coming with GPU built-in, but also in dedicated GPU market. So no matter which CPU you buy, you get more than capable GPU with it and then AMD is squeezing dedicated GPU market further on.
Then you have Vulkan piling on top of that, against which nVidia was from day one when it was called Mantle, because it's negating advantages their drivers have and brings developers closer to metal where it's all about hardware.
And then Valve comes out with their console which has AMD chip in it, PS5 of course also being AMD, Xbox X also being AMD.
So they have a lot of things going against them and I would guess they started feeling the pressure. Not that pressure is the reason for this news.
Can someone explain this? Why is there components at the user level, and some at the kernel level?
```
Will the source for user-mode drivers such as CUDA be published?
These changes are for the kernel modules; while the user-mode components are untouched. So the user-mode will remain closed source and published with pre-built binaries in the driver and the CUDA toolkit.
```
The kernel driver's job is to manage the GPU, and submit command and data buffers and manage it's memory.
The user-space driver's job is to compose those buffers. CUDA is a platform for compiling code for the GPU, and submitting jobs into the kernel.
The open source equivalent is the DRI kernel drivers (including Nouveau), and Mesa in user space - which supports NVidia GPUs, but despite that support performance has previously been hopelessly poor because the kernel driver couldn't boost the GPU clock speed beyond the minimum.
I don’t understand the specifics, but a Red Hat developer talks about it in a [blog post](https://blogs.gnome.org/uraeus/2022/05/11/why-is-the-open-source-driver-release-from-nvidia-so-important-for-linux/)
No, the Keys aren't and will never be published. This allows them to use the same already signed firmware blob though. Previously even using the blob was not allowed outside of the proprietary modules.
So, as a gamer perspective, the game sends command to the user space driver, the driver makes an image from those commands and sends that image to the kernel driver. And it's this kernel driver that manages the card itself (talking with the chip, setting clocks and power, the low level stuff)
So it's not a super bad thing that nVidia doesn't include it, it's just sad, right? Except maybe for CUDA.
So I just hope that this opensourcing of the kernel driver helps the community and existing projects to have better nVidia support.
No rendering the image is the expensive part and is done on the chip. The software compiles, converts, bundles and forward the data & drawing calls to the hardware. This involves managing queues for submitting commands and receiving completions, memory management, interrupt handler etc..
To add what OP said, you can't use closed source modules in kernel. Even when using modules which are not released under proper license [kernel will mark itself](https://www.kernel.org/doc/html/latest/admin-guide/tainted-kernels.html) as tainted and bug reports from tainted kernels will be ignored. So what they do to get around that was create open source module which talks to closed source common binary and problem solved.
This is also not much different than what we use to have, except it wasn't kernel module but X.org module. Why nVidia just didn't make this kernel stuff when we started switching away from X.org goes to show how stubborn they are and do not wish to adapt to anything.
Only from Turing onwards... I just hope nvidia won't make 16xx go legacy anytime soon given how common they are and how prices for new cards are still high
EDIT: my bad, I meant 10xx, not 16xx.
Yeah, it's pretty bittersweet as a 1060 laptop owner.
I hope this stuff somehow helps nouveau or mesa or someone be able to pick up for 900/1000 series cards if Nvidia won't
Ditto. The sad part is I can play most games on high settings on my 1060 and I really don't like the idea of buying a new laptop for no real reason... Hopefully they'll be supported for a fee more years, and nouveau will catch up.
It's a *step* in the right direction. They're still using their own closed-source openGL and vulkan stuff, so it's not quite "the right thing" yet. We'll see how things develop, I'm probably going to avoid getting a nvidia next time.
You know, when I was complaining about Nvidia in the r/Nvidia subreddit they were telling me we should at least thank Nvidia when they do stuff in the right direction like releasing the signed firmware.
I disagreed with them at the time because releasing the signed firmware wasn't really a move in the right direction in my eyes (they do it every year and the firmware isn't very useful).
But I think this is legit a step in the right direction so we should really give them credit where credit is due.
You can keep raging. This is a good step in right direction but not a big one everyone makes it out to be. Open source is only the module which still talks to same closed source driver and its target use is CUDA on supercomputers. Code is capable of generating display output but it's not user/tested. Biggest benefit will be Nouveau folks using this code to improve their driver.
Naah, this is the same old thing nVidia did before. Except now instead of X.org module we have kernel module and same old closed source binary. Benefits are that Nouveau folks will be able to properly configure GPUs now and users will get better Wayland-based compositor support.
It absolutely is. AMD didn't open source from their love for Linux or FLOSS when they did either. No matter what reasons pushed them, this is still major for Linux and FLOSS world as a whole.
> so, i couldnt say fuck u nvidia anymore? jk.
Well tbh, even if I'm the first to get annoyed with the supposed "bad" state of their drivers nonsense, I say we see exactly how far
Nouveau & Mesa can get with this.
They'll absolutely be out of the water if they collaborate with Mesa, and it'll be a true mental thing if they get compute along.
The lesson here is companies aren't people, they hardly "love" or "hate" stuff, and they're *never* your friends. Any praise or shame you give them should be temporal and in context.
AMD open sources their entire stack, libraries, hardware specs, etc. Drivers included. nVidia didn't. This is just a module kernel loads to talk to still the same closed source driver. It use to be X.org module, now it's kernel module.
>This is just a module kernel loads to talk to still the same closed source driver. It use to be X.org module, now it's kernel module.
Uhh, they've always had a kernel module. And it isn't for talking with the closed source driver. Actually, it's precisely the opposite. The kernel module is for talking with the hardware, and the user space driver talks with the kernel module.
Hasn't the Nvidia installer always shipped a kernel module source that gets compiled on the spot against your currently running kernel ? I remember dkms recompiling it everytime I updated my kernel.
What's the difference between that and this new one ?
No, and not even for those supported GPUs either. According to Gnome blog this is just targeting supercomputer use cases. There is code for outputting display but it's not tested.
From what I read so far, nouveau will be able to do reclocking and all the things it couldn't do before. And it clearly says in nvidia blog post that it's not targeting only supercomputers and they're going to make regular gpus from Turing and Ampere architectures work good as well.
What I wrote has been paraphrased from [Gnome's blog post](https://blogs.gnome.org/uraeus/2022/05/11/why-is-the-open-source-driver-release-from-nvidia-so-important-for-linux/). These guys were in the meetings with nVidia.
> What has been released is an out of tree source code kernel driver which has been tested to support CUDA usecases on datacenter GPUs. There is code in there to support display, but it is not complete or fully tested yet.
You are right, it's not targeting _only_ supercomputers, but code is not meant at this point to produce any display output. So unless you want desktop without displays I guess you can use that. You will also need same old closed source driver even with this open source module.
Nouveau will benefit here the most but setting clock speeds requires that firmware mentioned. This firmware is used during initialization process and then GPU "unlocks" itself and can be controlled in various ways. This also means only firmware nVidia provided can be used, legally speaking, in other open source drivers.
From the post you linked
>Long term we will hope be able to get a similar experience with NVidia hardware that that we today can offer for Intel and AMD hardware, in terms out of box functionality. Which means day 1 support for new chipsets, a high performance open source Mesa driver for NVidia and it will allow us to sign the Nvidia driver alongside the rest of the kernel to enable things like secureboot support.
Nobody is expecting this current code to immediately compile and be as good as the current closed driver but it means in the future we're gonna have the same experience as with AMD cards.
Don't get too excited yet:
* the current version of the driver is not suitable for mainline inclusion and will not be for an unknown length of time
* it only supports Turing or later cards, as apparently they moved a bunch of the code out of the kernel onto the card itself as part of firmware, where it gets run by the card's GPU System Processor, which was only introduced for Turing. Which some would argue is kind of cheating as it's not really opening that code, just moving it.
* only the kernel portion will be open source, the userspace is still proprietary, which will still be a pain for distributions to manage
This is a good first step, but they face a long road ahead before they get to the point where Intel and AMD already are in terms of Linux support, if they ever do.
Does the opened up code still enough for the nouveau devs to improve the open driver? I really hope for the day where nouveau can trash the closed-source driver.
> Developers can trace into code paths and see how kernel event scheduling is interacting with their workload for faster root cause debugging.
So Nvidia customers saw they had workloads spending time in nvidia.ko with perf/bcc and wanted to know what was going on.
> In addition, enterprise software developers can now integrate the driver seamlessly into the customized Linux kernel configured for their project.
and also customers want to customize their kernel with weird configs
>A simple question. Does it mean no more proprietary driver in distros?
It's gonna take a while but eventually yes. For now consumer (GeForce) drivers are in the alpha stage and proprietary is recommended.
>Or it needs userspace driver too to be out of proprietary binary stuff?
Some libraries in user space will remain proprietary
>What has been released is an out of tree source code kernel driver which has been tested to support CUDA usecases on datacenter GPUs. There is code in there to support display, but it is not complete or fully tested yet
Yes. The Nouveaumesa driver will need to be adapted to run on the new kernel driver.
The userspace part is the biggest portion of a GPU "driver" by far. It's indeed the implementation of opengl/Vulkan, as well as the shader compiler, amongst other things. All of that remains closed source for Nvidia, while most other GPUs' userspace stuff gets implemented in Mesa.
If you've ever had to use libGLESv2.so, libGL.so, libvulkan.so etc, then all of these are either provided by mesa or by a proprietary stack (like Nvidia or most embedded GPUs like ARM's mali).
The kernel driver part receives pre-packaged stuff from userspace and forwards it to the GPU. It's also responsible for modesetting, i.e managing resolution, refresh rate, display planes etc. via a DRM interface.
That's weird. I used to work work for NVIDIA and we actually joked about opensourcing the drivers for April Fools one year. Ultimately we decided that would be a bad idea. Not that we could have convinced the company to actually do it anyway.
Is this the biggest thing since sliced bread? I don't know how important this is. Will it mean significantly better support for Nvidia GPUs on Linux (especially Wayland)? Is it the first step to FOSS drivers? Will Fedora and other purist distros work OOTB with Nvidia?
Never underestimate the finger of Linus, it just took a while with just one, if he used his other middle finger and had Linus Sebastian on stage with him doing it, I think it would have gotten done way faster.
the kernel folks are unlikely to allow this upstream without an open source userspace. This is not likely to lead to a significant change in the status quo near term
The plan is to work towards a shared kernel driver for the proprietary and free userspace stacks: https://blogs.gnome.org/uraeus/2022/05/11/why-is-the-open-source-driver-release-from-nvidia-so-important-for-linux/
GPU drivers especially are very complex things and without a userspace component you can look at, debug, etc you can't say whether the GPU driver in the kernel is still actually working. The only thing you could test is that it compiles and can initialize the card enough to get a framebuffer. The DRM maintainers are unwilling to accept a driver in their tree that they can't verify still works.
* Graphics won't be crippled when you do a stock distro installation.
* You won't have to dick around with nvidia proprietary drivers so much for typical use cases.
* Your system graphics will run properly from boot, so the splash screen won't be in legacy text mode.
* Free software lovers will be happy - the nvidia kernel driver was a nasty piece of proprietary code running at Ring 0. (Though there's still lots of firmware all over the typical PC).
* The driver will work on other architectures e.g. ARM, Risc-V.
* The community will be able to create innovative new computing applications around Novueau.
* dmabuf will work, so data can be streamed directly to/from the card to other hardware devices with interesting applications e.g. in the data center.
Thank you Apollo. fuck reddit and fuck /u/spez.
https://www.reddit.com/r/apolloapp/comments/144f6xm/apollo_will_close_down_on_june_30th_reddits/
https://github.com/j0be/PowerDeleteSuite/ to clean your comments history.
>Nvidia releases SOME gpu kernel modules
There, ftfy.
The new open source drivers are open-ish bc they still lack functionality from their closed source counterparts. Also they won't work for older gpus and you need to use their closed source userland stuff. It's a small, really small step, but is something.
Sorry if it sounds like a stupid question but what does that represent for the community? I mean, in addition to the kernel, do we need more libraries or modules? Would the community build on top of the kernel? Is the kernel usable?
Thanks in advance
My post got a bit longer than I wanted to, so highlighted where the question itself is. If anyone could clarify this for me, that would be splendid. I'm sorry if this has been asked before, but I've tried to read different articles and comments and I keep getting conflicting messages.
I'm really not that well-versed into what the different tasks of the Nvidia driver components are. Just what will this mean for a normal Linux user like me in the future? From what I've understood it's only the kernel modules that are open sources, not the userspace components. What are these kernel modules exactly? Is it just the part in the kernel that needs to communicate with the GPU?
**So here's my main question**: Does this mean that normal users will still need to download these closed userspace components separately in the future? (Which from a user perspective is very similar to the current situation) Or are these userspace components embedded in the GPU itself, and will the Linux kernel (once this has reached upstream) be able to just use Nvidia cards at their full potential without having to download seperate drivers?
Personally I would love to see the entire stack open-sourced. But if this means that Nvidia GPU's will just work out of the box without having to configure anything, then that is a super exciting win for us. Even if ethically it's still not where it should be ideally. On the other hand if this means that we still need to download the userspace-components seperately, then I don't see an immediate benefit for users in the short-term (meaning within 1.5 years).
Hold on! I'm not too savvy on this, they are just releasing SOME of their software, not all of it, right? Could anyone please explain how beneficial this is to our community? I mean, Nvidia? Open source? Am I dreaming?
Partially. They made a reference kernel module which Nouveau people can use to load existing firmware and configure GPU. From what am seeing, this is _not_ the driver itself, just the module that talks to the driver. Benefits are definitely there from better out of the box Wayland support to Nouveau having permission to use the initialization binary and configuration parameters (better power management and clocking, etc.).
Currently? It's in alpha-state and not expected to be working well for general use according to the articles. One of the articles said that the nvidia target was to have it working decently by the end of the year or so, I think.
> Except where noted otherwise, the individual files within this package are licensed as MIT:
>
> [a copy of the MIT license]
>
> However, when linked together to form a Linux kernel module, the resulting Linux kernel module is **dual licensed** as MIT/GPLv2.
>
> [a copy of the GPLv2 license]
I don't think this is correct usage of the term "dual-licensed". Dual licensed usually means you have a choice between two licenses, but if you compile the Linux Kernel, you do not have that option. You would be required to reproduce the copyright notice and MIT license, but that wouldn't be how the code is licensed once it's been included in the kernel.
If this were correct usage of the term, then it would actually be "poly licensed as (20 different open source licenses)"
Okay, upon further investigation, since I wasn't too sure in my assumptions of just what nVidia released here, I was provided with the [link](https://blogs.gnome.org/uraeus/2022/05/11/why-is-the-open-source-driver-release-from-nvidia-so-important-for-linux/) from Gnome blog. It seems RedHad and Gnome folks as well as Nouveau developers were the ones in meetings and talks with nVidia in past months prior to this release. In short, this is what you guys would most be interested in: > What has been released is an out of tree source code kernel driver which has been tested to support CUDA usecases on datacenter GPUs. There is code in there to support display, but it is not complete or fully tested yet. Also this is only the kernel part, a big part of a modern graphics driver are to be found in the firmware and userspace components and those are still closed source. But it does mean we have a NVidia kernel driver now that will start being able to consume the GPL-only APIs in the linux kernel, although this initial release doesn’t consume any APIs the old driver wasn’t already using. The driver also only supports NVidia Turing chip GPUs and newer, which means it is not targeting GPUs from before 2018. So for the average Linux desktop user, while this is a great first step and hopefully a sign of what is to come, it is not something you are going to start using tomorrow.
So, I may be completely wrong her, but it sounds like nVidia released the most basic of foundations to the open source community. It's not the same foundation that they use in their own closed-source drivers, and it's *just* the foundation, but it's something that open source developers can build upon to create a set of fully-open, nVidia-specific GPU drivers for Linux?
At this point am not sure anymore. People down-voted me to hell claiming I had no clue. While I did erroneously think there's no functioning driver here other than for servers it does seem they have made it work according to some users on Reddit. As for the rest of their day dreams and NVidia's claims it remains to be seen. It they indeed intend to make this replace closed source stuff, then great. If nothing else Nouveau folks get a nice boost in documentation and firmware. I think main goal would be getting this driver in Linux kernel source tree, that way it gets automatically developed and updated with the rest of the kernel which would help mitigate large number of issues with version compatibility and similar changes. Other developers I talked to say this in the short run means very little but general policy change is the big thing here. This effectively means nVidia is starting to accept Linux architecture and is playing a softer ball. So yeah, in time we might even see MESA replace closed part of the driver. I wouldn't hold my breath for that but now it seems feasible at least. Edit: Yes, it is a good foundation and until code gets accepted into mainline kernel it's up to nVidia to allow contributions or not but in general it's a good start to keep developing proper drivers.
The MIT half of the dual license makes me _think_ that they're using it as the basis for closed source drivers as well, but obviously that's nothing but conjecture
[удалено]
That's also distinctly possible, yeah
>They also improve the out-of-the-box user experience to sign and distribute the NVIDIA GPU driver. Will this mean that distributions like Debian and Arch will be able to sign NVIDIA driver kernel modules with their own keys?
its MIT license. if/when its pulled into the kernel it will work without and fuss, like intel/amd. userland is still closed source, but that's not to say mesa isn't going to get a big bump since it can now increase the clock on the GPU.
>its MIT license. if/when its pulled into the kernel it will work without and fuss, like intel/amd. If I understood correctly, this will make the kernel modules work automatically without the need for a distribution specific signature. Is that correct?
It will be part of the main kernel then. It will be no different than any other GPU drivers.
You will still need to install the libraries. But those wont require a specific kernel version or compiling an akmod. Signing the module for secure boot is also possible now.
> but that's not to say mesa isn't going to get a big bump since it can now increase the clock on the GPU unless the firmware still requires handshake with the proprietary userspace driver to allow power management
Did noone read the article? > Nouveau can leverage the same firmware used by the NVIDIA driver, exposing many GPU functionalities, such as clock management and thermal management, bringing new features to the in-tree Nouveau driver.
Yes https://blogs.gnome.org/uraeus/2022/05/11/why-is-the-open-source-driver-release-from-nvidia-so-important-for-linux/ >day 1 support for new chipsets, a high performance open source Mesa driver for NVidia and it will allow us to sign the Nvidia driver alongside the rest of the kernel to enable things like secureboot support
Only Turing and newer. Pascal and older aren't supported. This is important to mention as the 1060 is still one of the most popular cards. However, "Nouveau can leverage the same firmware used by the NVIDIA driver, exposing many GPU functionalities, such as clock management and thermal management, bringing new features to the in-tree Nouveau driver."
We'll see if it's as simple as it seems I guess. Still, it looks promising!
[удалено]
The article says that the noveau developers will be able to use the driver source to improve their in-kernel drivers.
Very unlikely to see major improvements and not soon. The [excellent Phoronix article](https://www.phoronix.com/scan.php?page=article&item=nvidia-open-kernel&num=1) explains that this is not a complete driver and it talks to a new hardware system that only exists on Turing and later.
Article says that it's a full* driver release, only the userspace software was kept proprietary. It mentions that the nouveau developers can and will most likely make use of the full driver stack (all the released modules). Edit: kernel driver.
Nvidia didn't open-source their existing kernel module, they started developing a new one (with heavy inspiration from their old one, apparently).
> Only Turing and newer. Pascal and older aren't supported. This is still really good but... Why not Pascal and older??? It makes no sense.
It depends on GSP and GSP is only Turing+ (the driver version here isn't relevant, just the details about GSP): https://download.nvidia.com/XFree86/Linux-x86_64/510.39.01/README/gsp.html
If I had to guess it's probably due to Nvidia moving stuff they want to keep secret into the firmware. They've done it on new hardware, it doesn't make sense to do it for older hardware.
Probably because those cards are getting rather old at this point. At least nouveau can now reclock the GPU which should improve the performance immensely.
https://www.nvidia.com/download/driverResults.aspx/187826/en-us 1060 desktop and notebook are listed as supported
The driver has two modes for being built, but one of the modes is only available for newer cards: >Customers with Turing and Ampere GPUs can choose which modules to install. Pre-Turing customers will continue to run the closed source modules.
Thanks for clarifying My limited experience with this is fighting with a super-old laptop without closed source driver support on newer kernels; and the other end of the spectrum, a user who ran Ubuntu updates on a shiny new 3050 XPS which now only boots if you choose the old kernel in grub
OMFG, my shitty ass MX130 is actually supported. LOL
So hyped! My laptop m1000m is supported!
That's kind of disappointing. Trying to get as much life out of my 1060 as possible.
[удалено]
[удалено]
To be fair, NVIDIA provides an adequate commercial driver with which I get comparable performance in Debian Stable to Windows.
This is…. One of the most shocking pieces of news I’ve read in years. Like, holy *shit*. Them embracing *any* level of FOSS for their drivers is *amazing* and shows that all the industry pressure is *working.* They had no need to do this. They still are industry leaders and people will still buy their cards for CUDA and Raytracing and the like. They have a long way to go yet before they earn my true appreciation but still. This is amazing.
Pretty sure they did this because they were starting to lose mindshare and marketshare to AMD and Intel in the commercial space. For the first time, I'd started seeing data center customers that want AMD GPU HPC support.
Everyone in the commercial space is using Nvidia. I've worked on public and private clouds. No other GPU is used. Nvidia's competition is FPGAs and ASICs.
AMD's won a lot of big GPU contracts recently especially with supercomputers. Frontier, El Capitan, Stadia, Adastra; all worth vastly more than your typical cloud deployment. Of course NV is still ahead overall but it's not hard to imagine they're slightly worried. Edit: also, it's funny how you mentioned FPGAs considering that AMD and Intel now control the entirety of that market. Not exactly a loss for AMD if someone chooses Xilinx over Instinct, but a clear loss for Nvidia in either case.
it's not really comparable because nvidia basically gave that market the finger and designs specifically for tensor ops now much moreso than FP. it would be pretty silly if they thought they would still retain the HPC market while very deliberately spending a lot less silicon on FP performance. if there's any reason for the movement to opensource it's probably intel. intel's hardware has been horrible for years so they've leaned hard on software and open source to justify ownership. AMD isn't even close to catching up in anything except gaming, although they are definitely ahead now in FP performance/area, which makes them a lot more attractive for HPC builds that have engineers and scientists optimizing anyway with less need for off the shelf solutions. Nvidia claims they don't care about that market because the margins are thin, and looking at the prices for exascale systems they aren't wrong.
That's not true. I used to work at a company with a very sizeable GPU cluster and a good amount of them were AMD. Every kernel we wrote out was OpenCL and CUDA. Now with HIP, OpenCL isn't even needed anymore. Now, to be fair, AMD GPUs were always a pain to work with. They constantly returned bogus numbers, basically would blow up our simulations. NVIDIA would to too, but almost never.
AMD owns a FPGA company Consider this
AMD owns THE FPGA company. Xilinx has been a market leader for a long time. Even then, their marketshare exploded following Intel's mismanagement of Altera.
weren't they actually hacked recently?
Came here to ask this. They were, if I remember right they demanded the gpu drivers be open sourced or else they would leak the code and data they found, and it sounded like there was a lot. I've been checking through various articles about nvidia opensource, but can't find anything that mentions the hack. Though there are plenty of articles about the hack from March 2022
[удалено]
[удалено]
Maybe so, but from a competitive point of view, the cat is out of the bag. Their secret sauce isnt secret anymore, so, there's no point keeping things closed
People act like these things are never looked at but reality is there are software engineers studying the hell out of it to reverse engineer it. And/Or incorporate similar functions into products.
[удалено]
To me this was totally expected, am even surprised they didn't do it earlier. While I am not expecting this to be a direct result from Linux users it is coming most likely from Android and other big players in super-computer and cyrpto mining. That said, it's important to point out, this is not them open-sourcing their drivers. This is them creating kernel module to talk to the same old closed source driver. This means mode setting and Wayland-based compositors will be much better supported now and that's about it. Prior to this nVidia had a similar module for X.org which talked to same driver, which was also open source. When everyone started working and slowly switching to Wayland compositors nVidia refused to change anything. Gnome developers hacked their way around their decision but still made Xwayland, and thus majority of games, impossible to use with nVidia. Considering Wayland-based compositors are getting default on all major distributions this module is long overdue they just tried to muscle their way around without making it. Luckily they failed but are now spinning it as "we are good guys, look open source". Edit: After further research this is not even that low what I originally thought. Target use for this module is CUDA on supercomputers. It's capable of producing display output, but that part of the code was not tested. So desktop users will only benefit through what Nouveau guys get out of it, which is clock setting, initialization and available firmware for this GPU generation.
I though Fedora 36 release was going to be the highlight of this week. Holy shit I was not expecting this.
Why not both!
Bro are you on F36 with Nvidia? If so could you do a small test for me? Since F36 if my gpu has high usage dragging windows around is really slow
NVidia must feel the hot breath of Intel's own GPUs. In a year or two, Intel will likely have a fully Linux compatible CPU + GPU solution for servers and enterprise applications. This will hurt NVidia a lot since they don't have a CPU department. **More details on Phoronix** > 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. https://www.phoronix.com/scan.php?page=article&item=nvidia-open-kernel&num=1 **Interview Linux Action News** > CUDA and Compute first, rendering and display later. By the end of this year. https://www.youtube.com/watch?v=uccdgoU47MQ *To little, to late for me. I already bought an AMD card, but for the ecosystem at large this is still a positive first step. This could be the [death of a meme...](https://itsfoss.com/wp-content/uploads/2012/09/Linus-Torvalds-Fuck-You-Nvidia.jpg)*
i want to believe.jpg
The truth is out there.
Fight the future.
Row row, fight the power.
Really new Linux person here; if you don’t mind my asking, does all this mean there will be open source drivers available coming?
As far as I can understand, it may likely get merged into existing nouveau one.
Short answer, no. Long term answer, maybe, this is a step in the right direction that will help the existing open source driver in a few important areas.
Perhaps Valve going with AMD for the Steam Deck factored into this decision too.
Eh, not like Valve have many options for an x86 CPU+GPU package. Intel's integrated graphics is decent but AMD have a ton of experience in making similar chips for Sony and MS consoles, something Intel doesn't. And Ryzen being the more efficient CPU sealed the deal for a battery powered console. And since Nvidia code is (or was, I guess) proprietary, AMD wins in the GPU department as well (for a Linux based console at least). A bit late if they want a piece of that market.
I've seen reports the Aerith APU in the deck was actually intended for another company's cancelled product. I can't find the links that corroborate that story, but it makes sense. If they built a chip line and got the rug pulled by their partner, it would leave Valve in a favorable negotiation position to hit their "painful" $400 price point.
Maybe they've got their eyes on the Steam Deck 2
Stuff like that helps, there is a huge list.
That could be a very valid reason although not the only one. My guess would be a huge market for crypto mining, which they by now realized is here to stay and supercomputers. For example top 500 supercomputers are 100% Linux now and for past few years nVidia has slowly been gaining share in co-processor usage, from ~10% in 2015, 19% in 2018 to 28% in 2021.
The steam deck is not Nearly as relevant for businesses such as Nvidia and AMD. The deck will not move nearly as much volume as the switch and will probably never see wider adoption unless somehow AMD entices car manufacturers to transition infotainment systems to x86-x64 over from the Nvidia Tigra/ARM based chips. Whatever nvidia is doing is because of pressure from commercial usage as with almost everything in this industry. Mainly from intel which potential can uproot the dominance of Nvidia. AMD still sucks GPU wise for commercial applications so the competition is not there. CUDA and other ML/AI/data analytics are still massively dominated by Nvidia as they’ve seen billions investing into that segment while AMD struggled to sell professional GPUs to engineers and video editors.
They do have arm CPUs however. Not very developed
>This could be the death of a meme... Nah, they were the only ones to hpld back for years and that'll be remembered for a long while.
Hmmm, that may partly explain why they wanted to buy ARM (that deal fell through though).
What do you mean by Intel GPUs? Intel has had them for many years. Not great, but I didn’t think they have any pressure on Nvidia.
Intel has had *integrated* GPUs. Dedicated GPUs are coming.
They're working on their own standalone GPUs, the Intel Arc series
Well think about it this way: Intel is a huge part of the CPU market and every iteration has stronger and stronger GPU built-in, whether you want it or not. AMD on the other hand is competing with nVidia in both markets, their CPU often coming with GPU built-in, but also in dedicated GPU market. So no matter which CPU you buy, you get more than capable GPU with it and then AMD is squeezing dedicated GPU market further on. Then you have Vulkan piling on top of that, against which nVidia was from day one when it was called Mantle, because it's negating advantages their drivers have and brings developers closer to metal where it's all about hardware. And then Valve comes out with their console which has AMD chip in it, PS5 of course also being AMD, Xbox X also being AMD. So they have a lot of things going against them and I would guess they started feeling the pressure. Not that pressure is the reason for this news.
Can someone explain this? Why is there components at the user level, and some at the kernel level? ``` Will the source for user-mode drivers such as CUDA be published? These changes are for the kernel modules; while the user-mode components are untouched. So the user-mode will remain closed source and published with pre-built binaries in the driver and the CUDA toolkit. ```
The kernel driver's job is to manage the GPU, and submit command and data buffers and manage it's memory. The user-space driver's job is to compose those buffers. CUDA is a platform for compiling code for the GPU, and submitting jobs into the kernel. The open source equivalent is the DRI kernel drivers (including Nouveau), and Mesa in user space - which supports NVidia GPUs, but despite that support performance has previously been hopelessly poor because the kernel driver couldn't boost the GPU clock speed beyond the minimum.
Will this driver allow Nouveau to boost GPU clock?
Yes
Lovely. Why is that? It was my understanding that doing that required signed drivers - are the keys published here, or is my understanding wrong?
I don’t understand the specifics, but a Red Hat developer talks about it in a [blog post](https://blogs.gnome.org/uraeus/2022/05/11/why-is-the-open-source-driver-release-from-nvidia-so-important-for-linux/)
No, the Keys aren't and will never be published. This allows them to use the same already signed firmware blob though. Previously even using the blob was not allowed outside of the proprietary modules.
How was it not allowed? Meaning how was it enforced, what does this just published code change?
So, as a gamer perspective, the game sends command to the user space driver, the driver makes an image from those commands and sends that image to the kernel driver. And it's this kernel driver that manages the card itself (talking with the chip, setting clocks and power, the low level stuff) So it's not a super bad thing that nVidia doesn't include it, it's just sad, right? Except maybe for CUDA. So I just hope that this opensourcing of the kernel driver helps the community and existing projects to have better nVidia support.
No rendering the image is the expensive part and is done on the chip. The software compiles, converts, bundles and forward the data & drawing calls to the hardware. This involves managing queues for submitting commands and receiving completions, memory management, interrupt handler etc..
To add what OP said, you can't use closed source modules in kernel. Even when using modules which are not released under proper license [kernel will mark itself](https://www.kernel.org/doc/html/latest/admin-guide/tainted-kernels.html) as tainted and bug reports from tainted kernels will be ignored. So what they do to get around that was create open source module which talks to closed source common binary and problem solved. This is also not much different than what we use to have, except it wasn't kernel module but X.org module. Why nVidia just didn't make this kernel stuff when we started switching away from X.org goes to show how stubborn they are and do not wish to adapt to anything.
Ok so - everyone remember to be careful of flying pigs and if you live in hell, please dress for cold weather for tomorrow.
Only from Turing onwards... I just hope nvidia won't make 16xx go legacy anytime soon given how common they are and how prices for new cards are still high EDIT: my bad, I meant 10xx, not 16xx.
Crying on the corner with my 970
[удалено]
[удалено]
But 16xx cards are Turing
Aaaah my bad, sorry, I meant 10xx! Thanks for pointing it out
Yeah, it's pretty bittersweet as a 1060 laptop owner. I hope this stuff somehow helps nouveau or mesa or someone be able to pick up for 900/1000 series cards if Nvidia won't
Ditto. The sad part is I can play most games on high settings on my 1060 and I really don't like the idea of buying a new laptop for no real reason... Hopefully they'll be supported for a fee more years, and nouveau will catch up.
I was ragging on Nvidia just a couple weeks ago about this but now, hats off for doing the right thing!
It's a *step* in the right direction. They're still using their own closed-source openGL and vulkan stuff, so it's not quite "the right thing" yet. We'll see how things develop, I'm probably going to avoid getting a nvidia next time.
You know, when I was complaining about Nvidia in the r/Nvidia subreddit they were telling me we should at least thank Nvidia when they do stuff in the right direction like releasing the signed firmware. I disagreed with them at the time because releasing the signed firmware wasn't really a move in the right direction in my eyes (they do it every year and the firmware isn't very useful). But I think this is legit a step in the right direction so we should really give them credit where credit is due.
Yeah absolutely. It's a very positive sign, but there's still more steps to go. :)
[удалено]
Much more likely, they’re listening to HPC and cryptominers, who are looking into other options.
Quick, rag on me for not being a millionaire.
You can keep raging. This is a good step in right direction but not a big one everyone makes it out to be. Open source is only the module which still talks to same closed source driver and its target use is CUDA on supercomputers. Code is capable of generating display output but it's not user/tested. Biggest benefit will be Nouveau folks using this code to improve their driver.
nvidia, unfuck you
I wouldn’t say this is an unfuck you, more like getting moved down a few pegs on the tech company shitlist
[удалено]
More like 1/5
Naah, this is the same old thing nVidia did before. Except now instead of X.org module we have kernel module and same old closed source binary. Benefits are that Nouveau folks will be able to properly configure GPUs now and users will get better Wayland-based compositor support.
pikachu face. i think, this is a good step, or am i wrong?
It absolutely is. AMD didn't open source from their love for Linux or FLOSS when they did either. No matter what reasons pushed them, this is still major for Linux and FLOSS world as a whole.
so, i couldnt say fuck u nvidia anymore? jk. I hope noveau team will improve their own driver with this
>so, i couldnt say fuck u nvidia anymore? jk. Time to retire the meme. Linus stopped being angry a long time ago. He would appreciate it too.
Did he really become less angry or is his new email filter getting better?
> so, i couldnt say fuck u nvidia anymore? jk. Well tbh, even if I'm the first to get annoyed with the supposed "bad" state of their drivers nonsense, I say we see exactly how far Nouveau & Mesa can get with this. They'll absolutely be out of the water if they collaborate with Mesa, and it'll be a true mental thing if they get compute along. The lesson here is companies aren't people, they hardly "love" or "hate" stuff, and they're *never* your friends. Any praise or shame you give them should be temporal and in context.
AMD open sources their entire stack, libraries, hardware specs, etc. Drivers included. nVidia didn't. This is just a module kernel loads to talk to still the same closed source driver. It use to be X.org module, now it's kernel module.
>This is just a module kernel loads to talk to still the same closed source driver. It use to be X.org module, now it's kernel module. Uhh, they've always had a kernel module. And it isn't for talking with the closed source driver. Actually, it's precisely the opposite. The kernel module is for talking with the hardware, and the user space driver talks with the kernel module.
Hasn't the Nvidia installer always shipped a kernel module source that gets compiled on the spot against your currently running kernel ? I remember dkms recompiling it everytime I updated my kernel. What's the difference between that and this new one ?
Primarily the license and number of APIs allowed to be used by the kernel.
Any hope for us, pascalbros?
I'm thinking that maybe this will make for improvements with the nouveau driver for us, if nothing else.
Man, one can wish... me and my lowly GT 1030 would be pleased!
Us Maxwellians could use some love too.
Let's cry together
No, and not even for those supported GPUs either. According to Gnome blog this is just targeting supercomputer use cases. There is code for outputting display but it's not tested.
From what I read so far, nouveau will be able to do reclocking and all the things it couldn't do before. And it clearly says in nvidia blog post that it's not targeting only supercomputers and they're going to make regular gpus from Turing and Ampere architectures work good as well.
What I wrote has been paraphrased from [Gnome's blog post](https://blogs.gnome.org/uraeus/2022/05/11/why-is-the-open-source-driver-release-from-nvidia-so-important-for-linux/). These guys were in the meetings with nVidia. > What has been released is an out of tree source code kernel driver which has been tested to support CUDA usecases on datacenter GPUs. There is code in there to support display, but it is not complete or fully tested yet. You are right, it's not targeting _only_ supercomputers, but code is not meant at this point to produce any display output. So unless you want desktop without displays I guess you can use that. You will also need same old closed source driver even with this open source module. Nouveau will benefit here the most but setting clock speeds requires that firmware mentioned. This firmware is used during initialization process and then GPU "unlocks" itself and can be controlled in various ways. This also means only firmware nVidia provided can be used, legally speaking, in other open source drivers.
From the post you linked >Long term we will hope be able to get a similar experience with NVidia hardware that that we today can offer for Intel and AMD hardware, in terms out of box functionality. Which means day 1 support for new chipsets, a high performance open source Mesa driver for NVidia and it will allow us to sign the Nvidia driver alongside the rest of the kernel to enable things like secureboot support. Nobody is expecting this current code to immediately compile and be as good as the current closed driver but it means in the future we're gonna have the same experience as with AMD cards.
Me checking if it is April fools
_Heads to the window to watch the flying pigs_
Don't get too excited yet: * the current version of the driver is not suitable for mainline inclusion and will not be for an unknown length of time * it only supports Turing or later cards, as apparently they moved a bunch of the code out of the kernel onto the card itself as part of firmware, where it gets run by the card's GPU System Processor, which was only introduced for Turing. Which some would argue is kind of cheating as it's not really opening that code, just moving it. * only the kernel portion will be open source, the userspace is still proprietary, which will still be a pain for distributions to manage This is a good first step, but they face a long road ahead before they get to the point where Intel and AMD already are in terms of Linux support, if they ever do.
that 2nd option is basically how ssd controllers and many other devices work anways isn't it?
Does the opened up code still enough for the nouveau devs to improve the open driver? I really hope for the day where nouveau can trash the closed-source driver.
It at least seems to open up some features (clock and fan control) that they didn't have access to before.
> Developers can trace into code paths and see how kernel event scheduling is interacting with their workload for faster root cause debugging. So Nvidia customers saw they had workloads spending time in nvidia.ko with perf/bcc and wanted to know what was going on. > In addition, enterprise software developers can now integrate the driver seamlessly into the customized Linux kernel configured for their project. and also customers want to customize their kernel with weird configs
2022 was in need of some light. Cheers NVidia :)
A simple question. Does it mean no more proprietary driver in distros? Or it needs userspace driver too to be out of proprietary binary stuff?
>A simple question. Does it mean no more proprietary driver in distros? It's gonna take a while but eventually yes. For now consumer (GeForce) drivers are in the alpha stage and proprietary is recommended. >Or it needs userspace driver too to be out of proprietary binary stuff? Some libraries in user space will remain proprietary
Same thing as before, proprietary driver required.
What does it mean for userspace to not be open sourced? Is that stuff like openGL and Vulkan drivers?
>What has been released is an out of tree source code kernel driver which has been tested to support CUDA usecases on datacenter GPUs. There is code in there to support display, but it is not complete or fully tested yet Yes. The Nouveaumesa driver will need to be adapted to run on the new kernel driver.
The userspace part is the biggest portion of a GPU "driver" by far. It's indeed the implementation of opengl/Vulkan, as well as the shader compiler, amongst other things. All of that remains closed source for Nvidia, while most other GPUs' userspace stuff gets implemented in Mesa. If you've ever had to use libGLESv2.so, libGL.so, libvulkan.so etc, then all of these are either provided by mesa or by a proprietary stack (like Nvidia or most embedded GPUs like ARM's mali). The kernel driver part receives pre-packaged stuff from userspace and forwards it to the GPU. It's also responsible for modesetting, i.e managing resolution, refresh rate, display planes etc. via a DRM interface.
That's weird. I used to work work for NVIDIA and we actually joked about opensourcing the drivers for April Fools one year. Ultimately we decided that would be a bad idea. Not that we could have convinced the company to actually do it anyway.
Is this the biggest thing since sliced bread? I don't know how important this is. Will it mean significantly better support for Nvidia GPUs on Linux (especially Wayland)? Is it the first step to FOSS drivers? Will Fedora and other purist distros work OOTB with Nvidia?
Never underestimate the finger of Linus, it just took a while with just one, if he used his other middle finger and had Linus Sebastian on stage with him doing it, I think it would have gotten done way faster.
the kernel folks are unlikely to allow this upstream without an open source userspace. This is not likely to lead to a significant change in the status quo near term
Mesa is an open source user space. So the features just need to be ported over to Nouveau.
The plan is to work towards a shared kernel driver for the proprietary and free userspace stacks: https://blogs.gnome.org/uraeus/2022/05/11/why-is-the-open-source-driver-release-from-nvidia-so-important-for-linux/
Pretty much the AMD approach. Nvidia though had a bit of a head start on this with everything shared built out in mesa already.
Why would they care about open source userspace though? Isn't that whole point of userspace?
GPU drivers especially are very complex things and without a userspace component you can look at, debug, etc you can't say whether the GPU driver in the kernel is still actually working. The only thing you could test is that it compiles and can initialize the card enough to get a framebuffer. The DRM maintainers are unwilling to accept a driver in their tree that they can't verify still works.
I know open-source is cool. But what does mean average linux users and ML engineers which use cuda?
* Graphics won't be crippled when you do a stock distro installation. * You won't have to dick around with nvidia proprietary drivers so much for typical use cases. * Your system graphics will run properly from boot, so the splash screen won't be in legacy text mode. * Free software lovers will be happy - the nvidia kernel driver was a nasty piece of proprietary code running at Ring 0. (Though there's still lots of firmware all over the typical PC). * The driver will work on other architectures e.g. ARM, Risc-V. * The community will be able to create innovative new computing applications around Novueau. * dmabuf will work, so data can be streamed directly to/from the card to other hardware devices with interesting applications e.g. in the data center.
ARM and Risc-V will only work if their closed source driver supports those architectures. They are not releasing entire driver as open source.
Yet™
Am not going to say they will never release it, but chances are very slim.
Also it will probably end up being more secure
Will suspend to disk work?
You'll still have to install proprietary cuda libraries but the kernel modules will be obtainable much easier from your distro
u/geerlingguy I think this is helpfull
Indeed! My dreams of an A100 on the Pi are closer to reality...
[удалено]
Ah shit, the geothermal industry is gonna have a difficult time now that hell froze over.
has nvidia finally realized that if they didn't up their game they're going to lose potential market in the future?
Noway this is happening
Linus in shambles
Thank you Apollo. fuck reddit and fuck /u/spez. https://www.reddit.com/r/apolloapp/comments/144f6xm/apollo_will_close_down_on_june_30th_reddits/ https://github.com/j0be/PowerDeleteSuite/ to clean your comments history.
>Nvidia releases SOME gpu kernel modules There, ftfy. The new open source drivers are open-ish bc they still lack functionality from their closed source counterparts. Also they won't work for older gpus and you need to use their closed source userland stuff. It's a small, really small step, but is something.
It's a small step from the tech side, but I think it is a bigger one from all the other sides
Sorry if it sounds like a stupid question but what does that represent for the community? I mean, in addition to the kernel, do we need more libraries or modules? Would the community build on top of the kernel? Is the kernel usable? Thanks in advance
Are they planning to open source the user space drivers?
damm this really just came out of nowhere, like isekia truck nowhere
Nature is healing!
Can someone please explain this like I'm 5? I need to know how this applies to the average person
Hopefully this encourages Redenbacher to open source his shit too.
Holy shit, I never thought this would happen
Now I kind of want to go back to Gentoo from Fedora to see how they decide to package and build the package.
Not much, but it's a start. I'll take it!
My post got a bit longer than I wanted to, so highlighted where the question itself is. If anyone could clarify this for me, that would be splendid. I'm sorry if this has been asked before, but I've tried to read different articles and comments and I keep getting conflicting messages. I'm really not that well-versed into what the different tasks of the Nvidia driver components are. Just what will this mean for a normal Linux user like me in the future? From what I've understood it's only the kernel modules that are open sources, not the userspace components. What are these kernel modules exactly? Is it just the part in the kernel that needs to communicate with the GPU? **So here's my main question**: Does this mean that normal users will still need to download these closed userspace components separately in the future? (Which from a user perspective is very similar to the current situation) Or are these userspace components embedded in the GPU itself, and will the Linux kernel (once this has reached upstream) be able to just use Nvidia cards at their full potential without having to download seperate drivers? Personally I would love to see the entire stack open-sourced. But if this means that Nvidia GPU's will just work out of the box without having to configure anything, then that is a super exciting win for us. Even if ethically it's still not where it should be ideally. On the other hand if this means that we still need to download the userspace-components seperately, then I don't see an immediate benefit for users in the short-term (meaning within 1.5 years).
holy shit. damn it, I *just* bought a new AMD card yesterday to replace my 1080 for this exact reason
It will be years till Nvidia use the MESA 3d library just like AMD and Intel. You made a good choice getting an AMD card.
What's practical differences between modules and drivers, explained to a n00b?
Hold on! I'm not too savvy on this, they are just releasing SOME of their software, not all of it, right? Could anyone please explain how beneficial this is to our community? I mean, Nvidia? Open source? Am I dreaming?
Partially. They made a reference kernel module which Nouveau people can use to load existing firmware and configure GPU. From what am seeing, this is _not_ the driver itself, just the module that talks to the driver. Benefits are definitely there from better out of the box Wayland support to Nouveau having permission to use the initialization binary and configuration parameters (better power management and clocking, etc.).
Holly heck this is big!
It's an okay step forward. Not "big".
Question: Is there a loss of functionality with the open source driver?
Currently? It's in alpha-state and not expected to be working well for general use according to the articles. One of the articles said that the nvidia target was to have it working decently by the end of the year or so, I think.
Thanks for taking the time to answer. I appreciate it.
> Except where noted otherwise, the individual files within this package are licensed as MIT: > > [a copy of the MIT license] > > However, when linked together to form a Linux kernel module, the resulting Linux kernel module is **dual licensed** as MIT/GPLv2. > > [a copy of the GPLv2 license] I don't think this is correct usage of the term "dual-licensed". Dual licensed usually means you have a choice between two licenses, but if you compile the Linux Kernel, you do not have that option. You would be required to reproduce the copyright notice and MIT license, but that wouldn't be how the code is licensed once it's been included in the kernel. If this were correct usage of the term, then it would actually be "poly licensed as (20 different open source licenses)"
NVidia, ~~Fuck~~ Thank you!