NVIDIA Doesn't Expect To Have Linux 5.9 Driver Support For Another Month

[Bladeforce]

I havent been able to install the new Nvidia drivers with anything newer than kernel 5.8

[btwcr]

Do you know if anything changed on that front? It's end of November but it looks like 5.9 is still incompatible with Cuda

[_ONH_]

The Problem seems to lie in the cuda / opencl part.

[Alliancemd]

I am using `Nvidia 455.28` with `Linux 5.9.1`, works fine

[BesiegedAce]

The amount of unhinged yelling in this thread is a great reminder of how elements of the foss community are the absolute worst thing to happen to it. Looking at financial stuff, I'm sure nVidia won't miss all 33 crazies who weren't going to buy an nVidia card in the first place.

[stiiixy]

"per se"

[oiaohm]

And lastly, a thing which people choose not to discuss here: with NVIDIA I can choose which drivers to use. With AMD your drivers are part of your kernel and Mesa. You cannot easily shuffle these packages around when regressions occur: in fact most people have no idea how to downgrade the Mesa package or roll back the kernel.

Need to roll back kernel when issue happen turns out to be equal risk with AMD and Nvidia drivers. I have run both Nvidia and AMD over the years. Nvidia you do strike the case where the new kernel will not take the Nvidia third party module quite a bit so need to roll back the kernel or worse cases with Nvidia install a different kernel completely so the Nvidia driver will install(there are kernel built options distrubitions can use that will break nvidia drivers). AMD you don't have this problem where the driver will not go into kernel but the same set of steps to roll back kernel version or install new kernel you use with Nvidia you use with AMD the same way only difference is AMD case is to change driver where Nvidia is so you can install driver.

The kernel bit like it or not AMD/Nvidia are very the same. Skills of build a kernel from source and roll back kernel to get around graphical issues are required with Linux be you using Nvidia or AMD if you run into trouble. The big difference is security. AMD to fix a graphical issue you will be normally moving to a newer kernel. Nvidia to fix a graphical issue you will find your self stuck on older kernel versions so older drivers install.,

Also AMD drivers being provided with kernel and mesa in the distribution is not the only option with AMD either.

https://www.amd.com/en/support/kb/release-notes/rn-amdgpu-unified-linux-20-30

There are the unified Linux drivers as well. So as a AMD user I can choose to use kernel provided AMD driver and distribution provided Mesa or go unified driver. So I have more driver choice than you do due to the kernel driver in fact working.

Downgrading/upgrading mesa is normally not done by AMD users on Linux those cases are were we fall back to the unified.

Basically people don't raise the point you just did here because its not a real difference that disadvantages AMD. Really all you have shown is that you have not used AMD solution for GPU long enough with Linux to know that area is not a major difference. Worse in most cases it advantage in the AMD direction once you take security risks into account.

[oiaohm]

Its actually hilarious because if Linux had a Hybrid/Micro Kernel design this wouldn't even be a discussion. The NVidia blob would be sitting in userspace (or Ring 0 environment) like any other program and would communicate with the kernel via some interface.

You forget X11 as x.org or Xfree86 had a thing called User Mode Setting. That was drivers fulling in user space for graphics. Linux can like a microkernel have drivers in userspace.

https://en.wikipedia.org/wiki/Hybris_(software)

Android also has had userspace graphics drivers on a Linux kernel. Now there is a performance overhead having drivers in userspace. So Nvidia blob could be sitting fully in userspace if Nvidia was happy with the overhead today with Linux.

They absolutely Nvidia want to be ring 0 if they were happy in userspace they could have been using like user mode setting under Linux.

This issue has less to do with GPL than people think, its more to do with Linux sticking with an arguably archaic technical design for their kernel (every other kernel out there that has significant usage is either micro or hybrid kernel).

There is a interest point Mach kernel that is called a Microkernel today started as a monolithic Yes the base of OS X and what on iphones is hybrid between Mach Microkernel and BSD monolithic kernel. Common usage you don't find pure microkernels that often

Linux kernel and Freebsd kernel are called monolithic kernel a lot but when you look closer they are not a neat fit.

https://www.kernel.org/doc/html/latest/driver-api/uio-howto.html

Generic PCI UIO driver

The generic driver is a kernel module named uio_pci_generic. It can work with any device compliant to PCI 2.3 (circa 2002) and any compliant PCI Express device. Using this, you only need to write the userspace driver, removing the need to write a hardware-specific kernel module.

Windows the NT design is a hybrid between micro kernel and monolithic ideas. OS X you could say is another form of Hybrid. Horrible reality with Fuse, UIO and other things Linux is another implementation of hybrid between micro kernel and monolithic.

[oiaohm]

Wayland is still a toy, incomplete and doesn't offer benefits for most users out there while still having rough edges. I don't understand why NVIDIA has to support or "comply" with it. What if you created a brand new yet another graphics server tomorrow? Should NVIDIA also support it?

This is because you have not read the Wayland requirements.

https://linux.die.net/man/4/modesetting

Wayland compositors are after KMS support. Interesting enough we are fairly much to the point that all X11 graphics drivers par Nvidia support KMS. So in reality Nvidia does not support x.org X11 server properly. This is getting more important as distributions are installing x.org X11 server without root privileges so cannot fall back to the old VESA driver.

The hard reality here is Nvidia not supporting Wayland is also Nvidia not properly supporting x.org X11 server to come as secure as possible. Moving from user mode setting to kernel mode setting is a security change. This is also to move memory managed by kernel and memory managed by GPU into alignment to reduced privilege exploits.

Reality Nvidia needs to get their driver working correctly in KMS mode. The eglstreams is Nvidia attempt to avoid KMS but the result of eglstreams why no one else is going that route is creating memory managed by GPU under 1 system and memory managed by cpu under another allowing privilege errors.

Yes I would like Nvidia to have future graphics server support. But the reality is nvidia does not support current x.org X11 and Linux framebuffer properly. Yes wayland support from Nvidia that is proper would be just icing on the cake fixing up the x.org X11 and linux framebuffer issues correctly. Yes this requires Nvidia to accept that the way forwards is KMS.

[omer666]

Wow, downgrading a package, such a feat!

No, really, you do the same thing you are blaming others for. You are such an Nvidia fanatic that you compare GPUs that aren't even the same generation (cf RX 570 vs GTX 1650). You're clever enough to note that I ignored AMD's failures on purpose, but not enough to realise I was just mimicking your behavior.

And I am sorry to say this, but RX 200, 300 and 400 series were quite good in fact, they had a higher power draw, but not by much compared to Nvidia's offerings at that time. For around the same power draw and price as a GTX 960, you could have an RX 470 which outperformed it nicely, for example.