In a nice big win for open source, NVIDIA has today officially revealed that they've released open source Linux GPU kernel modules. Additionally, driver version 515.43.04 is out. This is a huge step and hopefully the sign of more to come from NVIDIA.
This release is a significant step toward improving the experience of using NVIDIA GPUs in Linux, for tighter integration with the OS and for developers to debug, integrate, and contribute back. For Linux distribution providers, the open-source modules increase ease of use. They also improve the out-of-the-box user experience to sign and distribute the NVIDIA GPU driver. Canonical and SUSE are able to immediately package the open kernel modules with Ubuntu and SUSE Linux Enterprise Distributions.
NVIDIA
NVIDIA say that with each new driver release, they will be publishing the sources mentioned on GitHub, and they will be accepting contributions from the community and other developers.
For now, data center GPUs are "production ready" but normal GeForce and Workstation GPUs (what we all use) are at an "alpha quality" for Turing and Ampere but NVIDIA plans to continue improving on it and "fully featured GeForce and Workstation support will follow in subsequent releases and the NVIDIA Open Kernel Modules will eventually supplant the closed-source driver". NVIDIA has also been working with the likes of Canonical, Red Hat, and SUSE for better packaging and deployment of it all.
There's still quite a long road ahead, as NVIDIA say it currently doesn't conform to the upstream Linux kernel design and so can't go upstream yet but they have plans to work on "an upstream approach" with help again from Canonical, Red Hat, and SUSE. For now, NVIDIA say it can serve as a way to also "help improve the Nouveau driver" since it will be able to use the same firmware as the main proprietary NVIDIA driver.
As for the driver release version 515.43.04, here's the main changes:
- Added support for the VK_EXT_external_memory_dma_buf and VK_EXT_image_drm_format_modifier Vulkan extensions. To use this functionality, the nvidia-drm kernel module must be loaded with DRM KMS mode setting enabled. See the DRM KMS section of the README for guidance on enabling mode setting.
- Changed nvidia-suspend.service, nvidia-resume.service, and nvidia-hibernate.service to use WantedBy= rather than RequiredBy=dependencies for systemd-suspend.service and systemd-hibernate.service.This avoids a problem where suspend or hibernate fails if the NVIDIA driver is uninstalled without disabling these services first.
See https://github.com/systemd/systemd/issues/21991
If these services were manually enabled, it may be necessary to update their dependencies by running sudo systemctl reenable nvidia-suspend.service nvidia-resume.service nvidia-hibernate.service- Interlaced modes are now disabled when active stereo is enabled.
- NVIDIA X Server Settings will now display the quit confirmation dialog automatically if only there are pending changes that need to be manually saved. The corresponding configuration option to control the appearance of the quit dialog was thus also removed.
- Removed the warning message about mismatches between the compiler used to build the Linux kernel and the compiler used to build the NVIDIA kernel modules from nvidia-installer. Modern compilers are less likely to cause problems when this type of mismatch occurs, and it has become common in many distributions to build the Linux kernel with a different compiler than the default system compiler.
- Updated nvidia-installer to skip test-loading the kernel modules on systems where no supported NVIDIA GPUs are detected.
- Updated nvidia-installer to avoid a race condition which could cause the kernel module test load to fail due to udev automatically loading kernel modules left over from an existing NVIDIA driver installation. This failure resulted in an installation error message "Kernel module load error: File exists".
- Updated the RTD3 Video Memory Utilization Threshold (NVreg_DynamicPowerManagementVideoMemoryThreshold) maximum value from 200 MB to 1024 MB.
With those changes, it means the start of support for Gamescope on NVIDIA drivers too!
Source code up on GitHub, driver release here.
Also, you can read the take from Red Hat's Christian F.K. Schaller on it here.
Update: oh, and remember how NVIDIA wanted to get NVIDIA Image Scaling into Proton? Well, a Pull Request is now up for Gamescope support, where it might be more likely to be accepted since it makes a bit more sense there perhaps.
Article taken from GamingOnLinux.com.
Some you may have missed, popular articles from the last month:
The comments on this article are closed.
All posts need to follow our rules. For users logged in: please hit the Report Flag icon on any post that breaks the rules or contains illegal / harmful content. Guest readers can email us for any issues.
Hell has officially froze over.. Glorious day though and looking forward to being on the same graphics stack as AMD and Intel MESA :) Even though atm its still using Nvidias OpenGL/Vulkan stack but I foresee eventually it will be like amdgpu being able to either use mesa or Nvidias closed source stack..
Taking a look at their blog post they reference Nouveau being able to use parts of this driver now its open source so mostly likely if you want mesa Nouveau will be the way to go and if you want Nvidias OpenGL/Vulkan you just use their driver.. either way this would work the same as the amdgpu driver basically giving us choice.. personally once Nouveau intergrates into this new code I will be swapping to that :)
Last edited by tohur on 11 May 2022 at 11:44 pm UTC
Taking a look at their blog post they reference Nouveau being able to use parts of this driver now its open source so mostly likely if you want mesa Nouveau will be the way to go and if you want Nvidias OpenGL/Vulkan you just use their driver.. either way this would work the same as the amdgpu driver basically giving us choice.. personally once Nouveau intergrates into this new code I will be swapping to that :)
Last edited by tohur on 11 May 2022 at 11:44 pm UTC
0 Likes
ExpandingMan May 12, 2022
I can't help but approach this with extreme skepticism but so far it's sounding like this is not bullshit.
Mind totally blown.
Mind totally blown.
1 Likes, Who?
slaapliedje May 12, 2022
Not related to the hackers that demanded nvidia open source their drivers, right?Either that or IBM/Redhat threw oodles of money at them.
1 Likes, Who?
Fuck. I just lost 50 bucks. I did my bet that Nvidia won't release before 2025 12 years ago.
Happy it's finally happening though. Worth the 50 bucks for loosing the bet.
Since the mention Canonocal, Red Hat and Suse, it's likely that's going to be a pretty fast transition to be kernel compliant. Fast being let's say 12-18 month.
No,I do not accept bets this time ;-).
Last edited by STiAT on 12 May 2022 at 5:20 am UTC
Happy it's finally happening though. Worth the 50 bucks for loosing the bet.
Since the mention Canonocal, Red Hat and Suse, it's likely that's going to be a pretty fast transition to be kernel compliant. Fast being let's say 12-18 month.
No,I do not accept bets this time ;-).
Last edited by STiAT on 12 May 2022 at 5:20 am UTC
5 Likes, Who?
This is not the full driver stack - just the kernel module - and
compares to R600G/AMDGPU for AMD, right?
So this won't be accepted in the kernel if *only* a proprietary user space drivers is available.
Mind that AMD only got their kernel driver mainlined as it provides a proprietary AND open-source
user space driver using the same API.
(Small) step in the right direction but not remotely as amazing (to me) as it sounded in the first place.
Wouldn't be Nvidia if there wasn't a catch.
compares to R600G/AMDGPU for AMD, right?
So this won't be accepted in the kernel if *only* a proprietary user space drivers is available.
Mind that AMD only got their kernel driver mainlined as it provides a proprietary AND open-source
user space driver using the same API.
(Small) step in the right direction but not remotely as amazing (to me) as it sounded in the first place.
Wouldn't be Nvidia if there wasn't a catch.
6 Likes, Who?
Ah, if only they'd realised 10 years earlier open sourcing their drivers was the right move! 
I'll still watch safely from the distance with my full AMD setup. Perhaps in 10 more years after this gets accepted and they've ironed out all the bugs and I can consider buying their hardware again.
I'm sure there's nothing fishy going on here:
!https://i.imgflip.com/6funv2.jpg
Last edited by setzer22 on 12 May 2022 at 7:59 am UTC
I'll still watch safely from the distance with my full AMD setup. Perhaps in 10 more years after this gets accepted and they've ironed out all the bugs and I can consider buying their hardware again.I'm sure there's nothing fishy going on here:
!https://i.imgflip.com/6funv2.jpg
Last edited by setzer22 on 12 May 2022 at 7:59 am UTC
4 Likes, Who?
So this won't be accepted in the kernel if *only* a proprietary user space drivers is available.
Mind that AMD only got their kernel driver mainlined as it provides a proprietary AND open-source
user space driver using the same API.
That's not true, drivers don't get rejected for that reason. The only reason it can't be streamlined is that the code doesn't follow Linux coding conventions. The driver as it is can be used by other software, not only the Nvidia propietary drivers. I guess it could be even used by Mesa. We'll see.
0 Likes
So this won't be accepted in the kernel if *only* a proprietary user space drivers is available.
Mind that AMD only got their kernel driver mainlined as it provides a proprietary AND open-source
user space driver using the same API.
That's not true, drivers don't get rejected for that reason. The only reason it can't be streamlined is that the code doesn't follow Linux coding conventions. The driver as it is can be used by other software, not only the Nvidia propietary drivers. I guess it could be even used by Mesa. We'll see.
It's not a matter of *can*. If such a user-space component does not exist, or is just a cheeky unmaintained mess, the kernel module will certainly not be mainlined.
Last edited by sub on 12 May 2022 at 8:28 am UTC
1 Likes, Who?
Wow, that's a big deal. Nouveau will get reclocking, after forever being stuck without it!The Firmware for post Turing cards is not there yet to enable that.
The stuff they released is not complete yet and still out of tree.
Will take time to become useful.
0 Likes
The article should have explained what is open-source and what is not. I assume the driver itself is still not open source
0 Likes
Be very careful with your enthusiasm people, remember who you're dealing with here. One step towards a good move does not absolve Nvidia from decades of anti-competitive strategies and shady business dealings.
I do not forget and I do not forgive.
This is positive news, yes... but make sure you read the fine print like has been pointed out a couple of times already in these comments. Not the time to be celebrating just yet. If we're talking about hell freezing over, this is more like the first snowflake appearing in the burning skies with hopefully many more joining soon.
And I'm sure the hack had nothing to do with this at all...
I do not forget and I do not forgive.
This is positive news, yes... but make sure you read the fine print like has been pointed out a couple of times already in these comments. Not the time to be celebrating just yet. If we're talking about hell freezing over, this is more like the first snowflake appearing in the burning skies with hopefully many more joining soon.
And I'm sure the hack had nothing to do with this at all...
6 Likes, Who?
Oh wow, I totally missed this story yesterday. I have been sticking with AMD because of their open source drivers and how well it all just works. With this announcement I'm not totally opposed to getting a Nvidia GPU for my next upgrade.
0 Likes
The article should have explained what is open-source and what is not. I assume the driver itself is still not open source
The kernel driver/modeset driver etc. are open source.
The userspace ones (OpenGL, Vulkan etc.) are not.
It's about hardware support. We will have to look to Mesa /nouveau for a userspace driver implementation. Which will be a lot easier with a DRM driver available, but still will take time, and just getting the kernel driver mainlined / compliant will take time. Until that it will live out of tree, but can be provided by distros and used instead of the current nouveau drm kernel driver, to be used by the nouveau implementation in Mesa.
I think :-)
Last edited by STiAT on 12 May 2022 at 1:36 pm UTC
2 Likes, Who?
iWeaker4You May 12, 2022
The article should have explained what is open-source and what is not. I assume the driver itself is still not open source
NVIDIA releases open source Linux GPU KERNEL MODULES
2 Likes, Who?
iWeaker4You May 12, 2022
NVIDIA Kernel modules + Nouveau
could be the future
could be the future
0 Likes
ssj17vegeta May 12, 2022
Hold on people, if I get it correctly, they didn't open-source their whole drivers, just the DKMS.
Of course, it's still very good news and definitely a step on the right path !
Of course, it's still very good news and definitely a step on the right path !
1 Likes, Who?
Dribbleondo May 12, 2022
Has...hell frozen over?
0 Likes
Hold on people, if I get it correctly, they didn't open-source their whole drivers, just the DKMS.
Of course, it's still very good news and definitely a step on the right path !
Hold on people, if I get it correctly, they didn't open-source their whole drivers, just the DKMS.
Of course, it's still very good news and definitely a step on the right path !
It still helps a lot. My preferred version would probably be the kernel drivers properly maintained with the kernel, and the userspace actually with support from Nvidia and others becoming Mesa/nouveau.
I don't see the need to make userspace libs open source. AMD does not either, they help (or rather basically develop mostly on their own) the open source Mesa version too.
I could see Nvidia going the same path, keeping their userspace closed source but lending a helping hand to Mesa/nouveau. I'd like that actually, so we in the end have one library for userspace drivers - Mesa.
We'll see what happens, but actually hopefully the kernel upgrade not breaking akms / compiling of the nvidia module would be very welcome indeed. It does not happen often, but happend to me once since the beginning of the year in Fedora. Though, Fedora went on while they knew this would break it for Nvidia users since it's out-of-tree, within this open source change this could become a kernel module in-tree for Fedora too. Which I'd like.
0 Likes
I don't see the need to make userspace libs open source. AMD does not either, they help (or rather basically develop mostly on their own) the open source Mesa version too.
AMD supports both radeonsi (open source OpenGL for AMD in Mesa) and amdvlk (open source Vulkan for AMD, but not part of Mesa). So their full stack is open source. Mesa has radv for it.
So for Nvidia to be on par, someone has to implement open source Vulkan for them. Open source OpenGL in Mesa for it already exists (though not supported by Nvidia).
Last edited by Shmerl on 12 May 2022 at 6:08 pm UTC
3 Likes, Who?
TheRiddick May 12, 2022
It's only a driplet of FOSS support. We will have to see where this leads over the next 12 months.
0 Likes
Patreon
PayPal
See more from me