Satan feels a chill in the breeze: Nvidia publishes open source linux GPU drivers

[Arika]

1 hour ago, leadeater said:

Nvidia yum repos

I will never get over the fact that there is a legitimate command in the Linux terminal called "yum"

[leadeater]

37 minutes ago, Arika S said:

I will never get over the fact that there is a legitimate command in the Linux terminal called "yum"

 

yum install food-common food-bread food-butter

 

[Giganthrax]

Great news.

 

Hopefully, in a couple of years we'll have a reliable open source driver for regular desktop use. Combined with further advancements in Proton, Linux gaming may become easier than ever. One can hope. 

[aaradorn]

Can someone explain what this means for gaming on Linux? (I'm not that familiar with Linux but I would love to switch away from the privacy hell-hole that is windows)

[porina]

2 hours ago, igormp said:

Relevant tweet from marcan:

How do AMD do it? From phoronix article they say AMD are open source driver and userland, close sourced firmware, and Intel are expected to do similar to AMD. 

[Lightwreather]

2 minutes ago, aaradorn said:

Can someone explain what this means for gaming on Linux? (I'm not that familiar with Linux but I would love to switch away from the privacy hell-hole that is windows)

As yet, nothing really. This isn't really for userland.

[aaradorn]

9 minutes ago, J-from-Nucleon said:

As yet, nothing really. This isn't really for userland.

Ah okay. I will wait for what comes out in the future.

[WolframaticAlpha]

Still, moves in the right direction. It's better than the absolute shim that broadcom gave out, but still, room to improve.

 

[WolframaticAlpha]

2 hours ago, igormp said:

Relevant tweet from marcan:

 

oops, didn't look thru the entire thread

[Paul Thexton]

2 hours ago, Arika S said:

I will never get over the fact that there is a legitimate command in the Linux terminal called "yum"

This literally just reminded me of this golden oldie: http://www.pcuf.fi/~pjt/pink/pc-unix.html

[Orcblood]

@LAwLzDude, I want to fist-bump you. Well said. I was thinking the same.

 

If we want to conspires for fun though, I think this likely has to do with Intel. Nvidia has never seen AMD as much of a threat to them, and do not really respect them as an equal competitor. Now with Intel coming into the d-GPU market with Open Source drivers and APIs like AMD, I think Nvidia has seen it's time to open up if they want to stay more relevant to users and developers alike in the graphics market. 

[Giganthrax]

51 minutes ago, aaradorn said:

Can someone explain what this means for gaming on Linux? (I'm not that familiar with Linux but I would love to switch away from the privacy hell-hole that is windows)

If all goes well, in a few years we'll have fully open source drivers for nvidia GPUs, which should offer better performance for gaming on Linux desktops while also alleviating many of the problems users have with the proprietary drivers.

[gjsman]

It is possible Hector Marcan / @Marcan42 was too hasty with his judgement in the Twitter thread about it being 30MB in size, as he was unaware in replies that it supported multiple (IIRC 4) GPU generations which means the per-GPU code is actually much smaller...

[Kisai]

5 hours ago, leadeater said:

Holy crap this is amazing, going to make CUDA compute on Linux that little bit more easier and streamlined I hope. Yes!

Yeah.

5 hours ago, leadeater said:

Um I don't think you really know what you are talking about here or have practical experience with it.

Please shove your "I don't think you know.." BS. This is practical experience I have had on Windows already. You need the -exact- driver-CUDA-Python-Pytorch/Tensorflow something was developed on, not something newer, not something older, and newer cards don't support older versions point blank. If something was developed on Pascal, good luck getting it to work on Ampere. Just upgrading from a 1080 to a 3070Ti required changing things. Likewise the Tensorflow used by two projects do not work on Ampere or Turing because they were written for CUDA 10.1 and require the exact cuDNN. Half this stuff doesn't install in parallel. 

 

For what it's worth DeepSpeech is kind of annoying to install anyway and Mozilla has stopped development on it, it does not work on newer Tensorflow versions, or at least is obnoxiously difficult on windows.

 

 

5 hours ago, leadeater said:

We're running current branch Nvidia GPU drivers and CUDA on RHEL8 right now with A40's and A100. Installation is a non-issue other than the drivers being proprietary and not provided by Red Hat through their managed repos and controls.

 

https://developer.nvidia.com/blog/streamlining-nvidia-driver-deployment-on-rhel-8-with-modularity-streams/

 

The problem is the process is unnecessarily annoying and you end up adding additional Nvidia yum repos, not that you are limited by anything you were talking about.

 

sudo dnf module install nvidia-driver:4.18

However I don't know why you would have to specifically limit yourself to an older version, 10.1 CUDA applications work with newer drivers and CUDA.

See above. Usually the "DRIVER" will work but the usermode libraries like cuDNN will not work on a newer installed CUDA runtime unless you move the order it's accessed.

https://punndeeplearningblog.com/development/tensorflow-cuda-cudnn-compatibility/

Then you end up with a situation where program A wants CUDA 10.1 and program B wants CUDA 11.x and only one of those will work with CUDA 11.

 

nVidia may depreciate an older CUDA version at any time.

https://docs.nvidia.com/deploy/cuda-compatibility/index.html

 

As for the driver issue:

 

At anyrate I'm not dismissing your experience with the datacenter GPU's, I'm saying it's literately a pain in the ass to have applications written to use 10.1 not work if 11 is installed at all.

 

[Chunchunmaru_]

Really interested to see how the nouveau development will continue, anyway, we are talking about the 515.43.04 sources, which already has deprecated older cards, so don't know if there will be any bright future to them.

Own a GK106M chipset on my work rig, nouveau runs like crap even on Wayland, but at least is able to run two monitors.

Tried to insmod, NOPE! No older cards support in this driver. Hope they'll release the older ones, they will benefit a lot.


Can't really wait till it gets integrated to mainline!!!
No more drivers install!

Well, actually, will be more painful to update to the latest version...

[Master Disaster]

7 hours ago, igormp said:

Relevant tweet from marcan:

 

Yeah its not ideal but its still better than what we have currently. At least now Nouveau can call the functions from the firmware instead of the devs trying to guess how things work.

 

These days its pretty hard to have a fully untainted kernel anyway (unless you go full neckbeard mode and run Gentoo that is), at least it will be a module.

 

Interestingly though, this is gonna make linux-firmware a hard dependency of Nouveau.

[Master Disaster]

1 hour ago, Chunchunmaru_ said:

Really interested to see how the nouveau development will continue, anyway, we are talking about the 515.43.04 sources, which already has deprecated older cards, so don't know if there will be any bright future to them.

Own a GK106M chipset on my work rig, nouveau runs like crap even on Wayland, but at least is able to run two monitors.

Tried to insmod, NOPE! No older cards support in this driver. Hope they'll release the older ones, they will benefit a lot.


Can't really wait till it gets integrated to mainline!!!
No more drivers install!

Well, actually, will be more painful to update to the latest version...

What distro do you run? I recently installed Arch on my mess around system and its got a really old GTX580 in it. Nouveau runs OK but I get the best performance out of the 470.XX drivers.

[leadeater]

4 hours ago, Kisai said:

See above. Usually the "DRIVER" will work but the usermode libraries like cuDNN will not work on a newer installed CUDA runtime unless you move the order it's accessed.

https://punndeeplearningblog.com/development/tensorflow-cuda-cudnn-compatibility/

Then you end up with a situation where program A wants CUDA 10.1 and program B wants CUDA 11.x and only one of those will work with CUDA 11.

Is this just a Windows-ism? Nobody has ever come back to me that I've provided a GPU enabled RHEL8 or Ubuntu VM and asked to have the drivers downgraded.

 

Sounds like it's been not a problem because we have datacenter GPUs from your post, and Linux handling binaries better.

 

4 hours ago, Kisai said:

At anyrate I'm not dismissing your experience with the datacenter GPU's, I'm saying it's literately a pain in the ass to have applications written to use 10.1 not work if 11 is installed at all.

You'll have to forgive calling hard doubt when I actually support hundreds of researchers and their hardware requirements and not once ever run in to problems you mention. All doing tons of different stuff. But yea datacenter GPUs, bit crap they limit this to those and "select others" 

[Sauron]

23 hours ago, BachChain said:

NVIDIA's user-space libraries and OpenGL / Vulkan / OpenCL / CUDA drivers remain closed-source

oh, I thought for once we were getting something nice from nvidia. guess not.

[igormp]

7 hours ago, porina said:

How do AMD do it? From phoronix article they say AMD are open source driver and userland, close sourced firmware, and Intel are expected to do similar to AMD. 

AMD has firmware for each GPU, amdgpu as the kernel module, and mesa for the open, userland drivers. There's more info here.

 

5 hours ago, gjsman said:

It is possible Hector Marcan / @Marcan42 was too hasty with his judgement in the Twitter thread about it being 30MB in size, as he was unaware in replies that it supported multiple (IIRC 4) GPU generations which means the per-GPU code is actually much smaller...

I'd consider it to be still quite fat, since the entirety of AMDGPU's firmware stack is just under 20MB with tons of firmware files

 

 

4 hours ago, Kisai said:

You need the -exact- driver-CUDA-Python-Pytorch/Tensorflow something was developed on, not something newer, not something older, and newer cards don't support older versions point blank. If something was developed on Pascal, good luck getting it to work on Ampere. Just upgrading from a 1080 to a 3070Ti required changing things. Likewise the Tensorflow used by two projects do not work on Ampere or Turing because they were written for CUDA 10.1 and require the exact cuDNN. Half this stuff doesn't install in parallel. 

Stuff is usually forwards compatible, and I'm also talking from experience as someone who regularly switches between a V100/A100/3060. 

An older CUDA version won't work with a newer GPU, but usually an older GPU will work just fine with a newer CUDA toolkit, so all you need to do is upgrade everything at once.

 

Your problem seems more related to older TF versions (pre 2.2), which are deprecated, so good luck porting those projects to newer versions (I've done that a lot and I'm already used to it, but it was not easy in the beginning).

 

And you can install those in parallel, either with docker (easy way), or by having a symlink to your CUDA paths and changing the actual symlink depending on the version.

 

4 hours ago, Kisai said:

or at least is obnoxiously difficult on windows.

Yep, that's your problem.

 

5 hours ago, Kisai said:

At anyrate I'm not dismissing your experience with the datacenter GPU's, I'm saying it's literately a pain in the ass to have applications written to use 10.1 not work if 11 is installed at all.

That's indeed annoying, but it's a 5 minutes fix on linux to switch versions. I have no idea how one would do it on windows, nor want to know (just a fyi, running cuda on windows is 20~30% slower than on linux).

 

3 hours ago, Chunchunmaru_ said:

Tried to insmod, NOPE! No older cards support in this driver. Hope they'll release the older ones, they will benefit a lot.

Those drivers require Nvidia's GSP, which are only available on turing and newer GPUs.

3 hours ago, Chunchunmaru_ said:

No more drivers install!

You'll still need to download the userspace drivers.

 

15 minutes ago, leadeater said:

Sounds like it's been not a problem because we have datacenter GPUs from your post, and Linux handling binaries better.

It's also a problem on linux with older projects, but I believe most devs who work with that kind of thing are already used to fixing it/porting stuff.

 

I'm always amazed by people that try to do cuda stuff on windows lol

 

 

[Kisai]

19 minutes ago, leadeater said:

Is this just a Windows-ism? Nobody has ever come back to me that I've provided a GPU enabled RHEL8 or Ubuntu VM and asked to have the drivers downgraded.

Probably. Just believe me when I say CUDA on Windows for ML is a pain in the ass, and Microsoft's desire to run Linux on Windows has more to do with this kind of activity and not much to do with running general Linux software.

 

19 minutes ago, leadeater said:

Sounds like it's been not a problem because we have datacenter GPUs from your post, and Linux handling binaries better.

Maybe. I have not had access to a DC GPU.

 

19 minutes ago, leadeater said:

You'll have to forgive calling hard doubt when I actually support hundreds of researchers and their hardware requirements and not once ever run in to problems you mention. All doing tons of different stuff. But yea datacenter GPUs, bit crap they limit this to those and "select others" 

Everyone has a different project they want to support, and you absolutely can not support "all of them" with one install unless you're willing to port everything every time PyTorch/Tensorflow changes something.

 

 

 

2 minutes ago, igormp said:

Stuff is usually forwards compatible, and I'm also talking from experience as someone who regularly switches between a V100/A100/3060. 

An older CUDA version won't work with a newer GPU, but usually an older GPU will work just fine with a newer CUDA toolkit, so all you need to do is upgrade everything at once.

Assuming the older GPU supports it, which fortunately is not the problem I'm expressing here.

2 minutes ago, igormp said:

Your problem seems more related to older TF versions (pre 2.2), which are deprecated, so good luck porting those projects to newer versions (I've done that a lot and I'm already used to it, but it was not easy in the beginning).

Yep, and both projects I first started using were based on TF not pytorch, and both were exact-version-only projects.

2 minutes ago, igormp said:

And you can install those in parallel, either with docker (easy way), or by having a symlink to your CUDA paths and changing the actual symlink depending on the version.

On Linux you can do the symlink. On Windows you have to futz around with the paths so the version of CUDA, cuDNN, etc come before any installed version. I wound up just pulling all the DLL files each project wants in their directories thus making it dependant only on the drivers, but even that's a bit of a crapshoot.

 

 

2 minutes ago, igormp said:

Yep, that's your problem.

Believe me if I had a machine to spare when I started the projects 2 years ago (remember, chip shortage) I would have just bought such hardware to do so. That wound up not being an option. The plan right now is to get another desktop when the 40-series GPU's come out, and turn this computer into the Linux machine rather than rely on the laptops which I'm not willing to install Linux on.

 

 

2 minutes ago, igormp said:

That's indeed annoying, but it's a 5 minutes fix on linux to switch versions. I have no idea how one would do it on windows, nor want to know (just a fyi, running cuda on windows is 20~30% slower than on linux).

 

TF is for sure because Google second-fiddles Windows. Pytorch I haven't had much of an issue with, but usually updating python, pytorch, numpy breaks it or everything it depends on, but the GPU "exact" configuration is a bit less of an issue. None the less, having both TensorFlow and Pytorch on the same install creates the same problem Ultimately I gave up on trying to maintain the 10.1 install the TF program needed and upgraded the other program which was still being maintained until December of last year.

 

[Guest]

13 hours ago, leadeater said:

 

yum install food-common food-bread food-butter

 

this is why fedora is better than any other linux distro, 100%

[Chunchunmaru_]

9 hours ago, igormp said:

You'll still need to download the userspace drivers.

Totally forgot about it.

Well, my dreams into the trash bin, including a possibility to them being ported to the mesa stack