Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CUDA 11.0

docs.nvidia.com

Post reply on HN
Print view View original

61–67 of 67 posts

Re: CUDA 11.0

#61

Post by markus92 »

bbatsell wrote: post #13
usmannk wrote: post #3

I noticed CUDA 11.0 was almost ready for release last week when I went to install CUDA and the default download page linked to the 11.0 Release Candidate. The 10.1 and 10.2 links were buried behind a link off to the side labeled "legacy". The thing is, no library you use is going to be supporting the CUDA 11.0 RC, that's ridiculous. For example, Pytorch stable is on 10.2 and Tensorflow only goes up to 10.1. This is g…

I have to use containers with nvidia-docker because NVIDIA so consistently and relentlessly breaks things without so much as a glance at backward compatibility.

We use Singularity as our container provider for the exact same reason. For now it has worked great and driver/CUDA updates haven't broken any containers yet over the past 2 years.

Something good about Singularity (which I bet you could also do with Docker) is that it automatically binds the right NVIDIA stuff into the container. It also works fine unprivileged :)

Re: CUDA 11.0

#62

Post by mpfundstein »

blueblisters wrote: post #50
zelly wrote: post #34

Earlier quoted context omitted.

For something this popular it shouldn't be so hard. I don't think being related to hardware is an excuse. CUDA is not a driver and exists entirely in userspace. This is the kind of thing that happens when you're dealing with a monopoly.

The economic incentive is simple: open-sourcing the driver will allow an open-source API to interact with the hardware, allowing AMD/other competitors to support the same API. So instead of competing at the silicon level, Nvidia chooses to set up unnecessary barriers to entry at massive cost to developers/users. Like Torvalds says [1]: Fuck You, Nvidia. [1]: https://www.youtube.com/watch?v=iYWzMvlj2RQ

unnecessary? not in the eyes of the shareholders. just compare NVIDIAs stock surge with the performance of AMD. they protect their market and they do it pretty well.

the Linus video is awesome though :-) And I totally understand his sentiment

Re: CUDA 11.0

#63

Post by jjoonathan »

pjc50 wrote: post #58
jjoonathan wrote: post #12

Earlier quoted context omitted.

Yeah, and the CUDA 10.0 official Visual Studio demo project build was broken for... looks like a year, at least, because they didn't want to populate the toolkit path. NVidia, you're better than this. https://forums.developer.nvidia.com/t/the-cuda-toolkit-v10-0... > The Conda dependency manager has made this a lot easier Yeah but conda is "Let's do dependency management with a SAT solver, it'll be great!" On a good d…

> "Let's do dependency management with a SAT solver, it'll be great!" Debian managed something like this over 20 years ago in dpkg. But somehow people must keep reinventing the wheel.

I thought the debian SAT solver was a maintainer tool rather than something that ran every time? In any case, conda's implementation is really quite awful by comparison and they would have been well served by copying something that works instead of building something that doesn't.

Re: CUDA 11.0

#65

Post by NullPrefix »

pjc50 wrote: post #58
jjoonathan wrote: post #12

Earlier quoted context omitted.

Yeah, and the CUDA 10.0 official Visual Studio demo project build was broken for... looks like a year, at least, because they didn't want to populate the toolkit path. NVidia, you're better than this. https://forums.developer.nvidia.com/t/the-cuda-toolkit-v10-0... > The Conda dependency manager has made this a lot easier Yeah but conda is "Let's do dependency management with a SAT solver, it'll be great!" On a good d…

> "Let's do dependency management with a SAT solver, it'll be great!" Debian managed something like this over 20 years ago in dpkg. But somehow people must keep reinventing the wheel.

You can't use open source in an enterprise. All you can do is rewrite from scratch or hire external service. Everyone knows that.

Re: CUDA 11.0

#66

Post by desertrider12 »

suyash wrote: post #47
desertrider12 wrote: post #46

Earlier quoted context omitted.

Nope. That's mostly on Apple though, as they discourage all APIs that aren't Metal.

Apple needs to build a completive standard to CUDA.

Apple doesn't directly compete with CUDA, they just want total control of their platforms. Metal does have great performance and tooling. In practice nobody does HPC on macs so there's no demand for linear algebra or graph libraries, which are a big selling point for Nvidia over AMD.

The fact that Apple is trying to kill OpenGL and OpenCL and block Vulkan definitely sucks though for anyone trying to do indie games, or open source ML/HPC.

Re: CUDA 11.0

#67

Post by suyash »

desertrider12 wrote: post #66
suyash wrote: post #47

Earlier quoted context omitted.

Apple needs to build a completive standard to CUDA.

Apple doesn't directly compete with CUDA, they just want total control of their platforms. Metal does have great performance and tooling. In practice nobody does HPC on macs so there's no demand for linear algebra or graph libraries, which are a big selling point for Nvidia over AMD. The fact that Apple is trying to kill OpenGL and OpenCL and block Vulkan definitely sucks though for anyone trying to do indie games, o…

Have you looked at OpenGL api's, they are a strange legacy beast. I think Apple does what's best for it's users, even if it has to create a new standard. How about other companies adapting to modern Metal API's instead?
Post reply on HN