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.
Quoting: slaapliedjeQuoting: emptythevoidNot related to the hackers that demanded nvidia open source their drivers, right?Either that or IBM/Redhat threw oodles of money at them.
I would guess it's neither. My guess is that it's the rising competition from AMD and now Intel, both of which have their drivers upstreamed in the Linux kernel so it's easier to maintain cloud servers running AMD/Intel than nVidia.
slaapliedje May 13, 2022
Quoting: sarmadQuoting: slaapliedjeQuoting: emptythevoidNot related to the hackers that demanded nvidia open source their drivers, right?Either that or IBM/Redhat threw oodles of money at them.
I would guess it's neither. My guess is that it's the rising competition from AMD and now Intel, both of which have their drivers upstreamed in the Linux kernel so it's easier to maintain cloud servers running AMD/Intel than nVidia.
The only reason I suggested what I did is Redhat actually now has integration with RHEL for the CUDA stuff. Which is one area for sure that neither Intel nor AMD can currently touch at the moment. So thought maybe it had something to do with it. But pretty sure we'll never actually know the answer. But hey, who cares, nVidia finally edged toward what we've all wanted.
slaapliedje May 13, 2022
Quoting: STiATFuck. I just lost 50 bucks. I did my bet that Nvidia won't release before 2025 12 years ago.Pay up bitch! Ha, kidding, no clue who you bet.
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 ;-).
rustigsmed May 13, 2022
hopefully a slow opening up, but unlikely..
Quoting: STiATHmh, and Joshua Ashton is already fixing bugs in the driver looking at the merge requests. So Valve seems to want to involve themselves there too.If this is the case, they *may* end up writing an open-source Vulkan driver for it, which would allow us to have OpenGL thanks to Zink. That would be our best hope for now... Provided you've got a compatible GPU
ExpandingMan May 13, 2022
As people interested in linux gaming I think we should all still be rooting for AMD unless and until the situation drastically changes.
I for one am still hoping for the RDNA3 AMD cards to be an "obvious choice" in terms of performance so I don't even have to pay attention to nvidia's shenanigans any more.
Quoting: omer666Quoting: STiATHmh, and Joshua Ashton is already fixing bugs in the driver looking at the merge requests. So Valve seems to want to involve themselves there too.If this is the case, they *may* end up writing an open-source Vulkan driver for it, which would allow us to have OpenGL thanks to Zink. That would be our best hope for now... Provided you've got a compatible GPU
https://github.com/NVIDIA/open-gpu-kernel-modules/pull/61
Currently just minor fixes, but obviously started getting familiar with the code base, and since he is paid by Valve my guess is that that's a sign they are looking into actively contributing. If not helping development but actually being familiar enough to root out bugs and help fixing issues.
I think userspace stuff is more likely to end up in Mesa since RedHat is pushing that direction (reading/listening to Christian F.K. Schaller), and they got some manpower behind that for sure and plan to go forward together with Nvidia. And it would make sense making use of the existing infrastructure in Mesa.
That's a long haul though, and some time in the future for sure. They still need to figure a proper way for Mesa and the binary driver making use of the same kernel modules fitting the Nvidia/computing needs and desktop use complying with standards in the kernel and Mesa and not hampering down the binary userspace drivers by Nvidia. One of the reasons for this is to be able to sign the kernel, so it's likely Nvidia plans to base their proprietary driver on this in the end, but for that it should not impact their performance, so the upstream driver in the kernel if that ever happens needs to be in a state close enough. Which it currently probably is not.
Last edited by STiAT on 13 May 2022 at 7:53 pm UTC
Quoting: tpauIs there still a reason why RADV and AMDVLK co exist and not one of them replaced the othe`?
Supposedly because AMD didn't want to maintain separate code bases for Windows and Linux. And radv currently is dependent on Linux kernel interfaces.
Though Intel has no problem doing it and with AMD situation improving financially, I think they can officially switch to radv on Linux fine.
Last edited by Shmerl on 15 May 2022 at 4:25 pm UTC
Patreon
PayPal
See more from me