NVIDIA Transitioning To Official, Open-Source Linux GPU Kernel Driver

[maurossi]

Comments on https://us.download.nvidia.com/XFree...rnel_open.html

The open flavor of kernel modules supports Turing, Ampere, and forward. The open kernel modules cannot support GPUs before Turing, because the open kernel modules depend on the GPU System Processor (GSP) first introduced in Turing.

GSP constraint seems strange from technical point of view, because proprietary drivers were working also w/o using GSP at the very beginning

Most features of the Linux GPU driver are supported with the open flavor of kernel modules, including CUDA, Vulkan, OpenGL, OptiX, and X11. However, in the current release, some display and graphics features (notably: G-SYNC, Quadro Sync, SLI, Stereo, rotation in X11, and YUV 4:2:0 on Turing), as well as power management, and NVIDIA virtual GPU (vGPU), are not yet supported. These features will be added in upcoming driver releases
Use of the open kernel modules on GeForce and Workstation GPUs should be considered alpha-quality in this release due to the missing features listed above.

Which means CUDA, Vulkan, OpenGL, OptiX, and X11 may work with GeForce parts, barring the listed features

To enable use of the open kernel modules on GeForce and Workstation GPUs, set the "NVreg_OpenRmEnableUnsupportedGpus" nvidia.ko kernel module parameter to 1. E.g.,
modprobe nvidia NVreg_OpenRmEnableUnsupportedGpus=1

With this parameter setting, will Vulkan, OpenGL work with GeForce parts, as per using user space drivers version 515 with proprietary kernel modules?

[stiiixy]

Well, the comments were fun.

In the meantime (5 weeks, months? Years? until nVidia catch up), I get to continue on with the computing part of life on pure-AMD, because it just works.

[birdie]

In the meantime (5 weeks, months? Years? until nVidia catch up), I get to continue on with the computing part of life on pure-AMD, because it just works.

That's a lie. In terms of Linux integration it might just work. In terms of being bug-free and featureful - that's a bad joke.

[stiiixy]

You qualify your anecdotal situation about nVidia being great, we're effectively fanboys, and I'm just talking shit my shit just work's.

Howya going birdie, been awhile 😘

[skeevy420]

That's a lie. In terms of Linux integration it might just work. In terms of being bug-free and featureful - that's a bad joke.

Seeing as how we don't get bug-free and lots of features with Windows or MacOS I'm happy with great AMD Linux integration and everything just working.

Switching to AMD for my Linux graphics 9 or 10 years ago was the greatest decision I ever made in regards to Linux desktop usage and Linux gaming. That said, I'm eager to see how this plays out and if NVIDIA will become just as integrated as AMD or Intel graphics are with Linux.

[oiaohm]

That's a lie. In terms of Linux integration it might just work. In terms of being bug-free and featureful - that's a bad joke.

Bug free that is basically something no graphics driver is. Nvidia drivers are absolutely not bug free under Linux or Windows.

https://wiki.archlinux.org/title/NVIDIA/Troubleshooting

There are a lot of failures here that result in no output. This is a big problem if you don't have another device at the time to look up how to fix the failure.

https://wiki.archlinux.org/title/AMDGPU#Troubleshooting

Yes they do the same for AMD and Intel you will find the AMD and Intel list are a lot shorter. Nvidia lack of integration results in a horrible problem of a lot more failures options that end in no graphical output.

There are some bugs that are very Nvidia unique like screwing up due to the fact grub had been using the graphical output before the Nvidia driver starts all your open source drivers Intel AMD.... all do a graphic card reset when the init the card from the Linux kernel so avoiding this problem.

Lot of issue come from Nvidia driver getting out of sync with upstream Linux kernel developments as well.

birdie what is the point of more features if you are ending up a non functional machine over and over again. I first saw the difference when had one computer with Intel integrated graphics and the other with Nvidia both running Linux I horrible worked out that I was putting 20 times the about hours into the Nvidia machine over the Intel machine to keep in running.

There are legal reasons why the kernel driver need to be open source and under a GPLv2 compatible license. There is stability reasons why the driver need to be upstream. Yes the up-streaming process is going to see Nvidia need to change things like adding in a card reset when the kernel inits card.

Do note grub causing Nvidia issues is the Linux version the are cases where Windows changes their bootloader and Nvidia dies as well and the failure cause is the same problem Nvidia driver goes off presuming the GPU is in X state but due to firmware/boot loader its in Y state so no output. This also leads to the Nvidia restore from hibernate and things not work.

There is a hand full of minor incorrect design choices(mostly Assume something that is not truly set in stone) in the Nvidia driver causing 99% of the failures to start up or restore with graphical output functional and this does not matter if you are on Windows or Linux. The frequency is different due to Linux kernel changing more stuff internally more often than Windows but the design faults causing the failures is not. Microsoft does a major kernel change about 1 every 2 years Linux distributions do this about 2-4 times a year.

This is part of the problem why arguing for kernel driver ABI stablity does not get you anywhere as well OS with kernel driver ABI stablity as in Windows still has trouble with Nvidia closed source drivers just at a lower frequency so not solution to problem.

Nvidia open source this driver is the step that fixes the legal problem for some parties. S The up-streaming the driver is what will fix a lot of issues as lot of the incorrect assumes Nvidia drivers have will block it from getting upstream into the Linux kernel until those are fixed. Yes all graphics drivers include in the Linux kernel are required not to assume a quite a list of particular things to get merged into the kernel in the first place.

[drakonas777]

Still plenty of reasons to choose AMD GPU:

• Open source user-space components;
• Better price/perf in raster;
• Better efficiency in raster;

Actually, when you think about it, NVIDIA GPUs do not offer anything better for the Linux desktop user aside CUDA perhaps...

[rogerx]

Turing is 2000 series not 3000.

Then don't spew some random speculations...

I have no clue what you're talking about, and one of the main reasons I commonly fail following-up with peoples' hype here. Furthermore, I think what I posted was pretty much right-on the money.

See:

Turing (microarchitecture)
https://en.wikipedia.org/wiki/Turing_(microarchitecture)

The Turing GPU mostly lists these nVidia 2019 and more recent products.
GeForce 16 series (2/2019)

https://en.wikipedia.org/wiki/GeForce_16_series

GeForce 20 series (7/2019)

https://en.wikipedia.org/wiki/GeForce_20_series

There's a few other GPUs that are older, but I really doubt they'll be included, as most manufacturers' generalize their press releases, then release the specific supported models later.

I really doubt most longtime Linux/nVidia users are going to buy into this hype about open source drivers. They've waited too long, and are likely just going to jump ship for Intel's discrete GPU or already have for AMD's open sourced GPUs'.

[birdie]

birdie what is the point of more features if you are ending up a non functional machine over and over again. I first saw the difference when had one computer with Intel integrated graphics and the other with Nvidia both running Linux I horrible worked out that I was putting 20 times the about hours into the Nvidia machine over the Intel machine to keep in running.

Anecdotal evidence is anecdotal. I've been using NVIDIA drivers for Linux for over two decades now and I've spent maybe 5 hours "fixing" them in this time period (most fixes being applying patches for new unsupported kernels which has happened at most a couple of times).

Meanwhile I've had criticial issues with open source Intel and AMD drivers some of which are unresolved to this fucking day.

Do not BS me with open source drivers "quality", "integration" and "seamlessness", PLEASE. This is all pure crap if basic features do not work.

Also, unlike with AMD and Intel, with NVIDIA I can use and switch between a couple of driver releases freely.

With AMD and Intel? You either have the latest kernel and drivers bugs or a not so new kernel which itself is buggy but graphics drivers work. No fucking middle ground.

The fact that drivers are coupled to the kernel is an abomination no other serious commerical OS does. Period. Even RHEL and Android don't feature this brain damaged decision. Drivers are too fucking big and complicated to be inlined. They must be developed separately, they must be a way to shuffle them. The Linux kernel project does not understand this and so we have it. Either a stable kernel with outdated drivers or a bleeding edge kernel with bleeding edge regressions and bugs. F this crap. This is why Linux is not going anywhere aside from its uses where people make it play by the rules: RHEL/Android - the only two reliable kernel distributions, with proper CI/QA/QC.

[billyswong]

On the surface, the inline-ness of Linux driver is bad design. But paradoxically, it is such design that push many drivers in Linux to go open source, which is probably one of the reasons why Linux become the most supported open source OS.