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

Alternative(s) to run CUDA on non-Nvidia hardware

hpcwire.com

Post reply on HN
Print view View original

31–40 of 82 posts

Re: Alternative(s) to run CUDA on non-Nvidia hardware

#31

Post by DiabloD3 »

pjmlp wrote: post #27
mschuetz wrote: post #20

Earlier quoted context omitted.

A couple of years ago I evaluated both Vulkan and Cuda as a choice for future projects. I couldnt get anything done after a week in Vulkan, but had the test prototype project working after just a day in Cuda. Needless to say, I'd never ever pick Vulkan for any project after that experience. It's just way to needlessly overengineered and bloated.

I used to be big into Khronos API camp, even did my project thesis in OpenGL, up to the famous Long Peaks fail. Vulkan ended up being the same extension spaghetti as its predecessor, and Khronos was only able to come up with something thanks to AMD offering Mantle, C++ bindings and a GLSL successor only came to be thanks to NVidia (Vulkan-hpp and Slang started at NVidia). The "we build the specification", and then "t…

I love how people say things like "extension spaghetti", as if all other non-standard APIs have the same problem: hardware gets new features that people want to use from that API, API gains extension to use that hardware feature.

CUDA is no different, in fact, often worse. Nvidia is bad at documenting which hardware does what things, and CUDA users often have to use third party tables to figure out what hardware can't do what and disappoint customers who unwisely invested into it.

Re: Alternative(s) to run CUDA on non-Nvidia hardware

#33

Post by account42 »

pjmlp wrote: post #15
zorked wrote: post #9

Earlier quoted context omitted.

This post has some serious peanut-gallery vibes.

Peanut-gallery is happily using CUDA, and needs actual sound reasons to move.

Then the peanut gallery has nothing to complain when Nvidia jacks up prices.

Re: Alternative(s) to run CUDA on non-Nvidia hardware

#34

Post by DiabloD3 »

sollycb wrote: post #25
DiabloD3 wrote: post #7

Its easier to just get rid of your legacy code entirely and use Vulkan for compute, or have your compiler emit SPIR-V directly. No reason to tie yourself to Nvidia's moat.

Ports are very often incredibly difficult and very time consuming. One of the biggest complaints we hear from the industry is "we tried to port to X and we could never complete it". An established codebase can have years of refinement. It will take time to achieve the same with the port. And with our compiler, just using cuda is no longer putting urself inside the moat :)

Ironically, this is what people claim AI can do with a snap of the fingers.

Should be real simple if the HN AI echochamber is right, right?

Re: Alternative(s) to run CUDA on non-Nvidia hardware

#35

Post by u1hcw9nx »

Alternatives exist, but little demand outside hyperscalers and special uses.

Neocloud customers just want plug-and-play CUDA. It works, it's tested, it adapts faster, and has known performance. Alternatives give no significant benefits.

Things can change, but they are not changing now.

Re: Alternative(s) to run CUDA on non-Nvidia hardware

#37

Post by mschuetz »

DiabloD3 wrote: post #29
mschuetz wrote: post #20

Earlier quoted context omitted.

A couple of years ago I evaluated both Vulkan and Cuda as a choice for future projects. I couldnt get anything done after a week in Vulkan, but had the test prototype project working after just a day in Cuda. Needless to say, I'd never ever pick Vulkan for any project after that experience. It's just way to needlessly overengineered and bloated.

Weird, most people have the exact opposite experience. Having to deal with closed source opaque poorly documented stacks sucks.

They really don't, no. Vulkan: 50 lines to allocate device memory. Cuda: One single line. What kind of extensive documentation stack do you want for functionality that is trivial in Cuda? And that exact issue continues through every little step of the way to your first usable application. I know there is VMA, it is a very poor solution to a problem that shouldn't even exist, and it only poorly addresses one of 100 parts of the API where Cuda is vastly simpler than Vulkan. Cuda also doesnt force you to use queue families but you can optionally use streams. No ridiculous descriptor management and binding in cuda, just passing pointers and handles via launch arguments. No overengineered explicit syncing mechanis in cuda, everything is nicely implicitly synced until you explicitly opt in to parallel streams. etc.

Re: Alternative(s) to run CUDA on non-Nvidia hardware

#38

Post by lumrn »

puschkinfr wrote: post #16

In this context AdaptiveCpp should also be mentioned. Started as a SYCL implementation, but recently-ish added a compiler for compiling a CUDA dialect to GPUs and CPUs from basically all vendors

SYCL is probably the most up-to-date CUDA alternative for all intents and purposes, at least if one likes modern C++ style (and lambdas inside lambdas). Expose it as C and get bindings to any other language for relatively little effort as well since it’s just C++. With AdaptiveCpp you can also compile SYCL to CUDA so both ways work with the CUDA dialect (PCUDA).

SYCL, as well as AdaptiveCpp, is a relatively active project though and has been for several years, feeding into the C++ standards committee work and is supported by several large organisations, including US national labs and several European universities. I suppose it’s worth keeping track of for people in related fields.

I suppose it’s just really hard to beat the head start and ecosystem integration NVIDIA has with CUDA.

Re: Alternative(s) to run CUDA on non-Nvidia hardware

#40

Post by pjmlp »

DiabloD3 wrote: post #31
pjmlp wrote: post #27

Earlier quoted context omitted.

I used to be big into Khronos API camp, even did my project thesis in OpenGL, up to the famous Long Peaks fail. Vulkan ended up being the same extension spaghetti as its predecessor, and Khronos was only able to come up with something thanks to AMD offering Mantle, C++ bindings and a GLSL successor only came to be thanks to NVidia (Vulkan-hpp and Slang started at NVidia). The "we build the specification", and then "t…

I love how people say things like "extension spaghetti", as if all other non-standard APIs have the same problem: hardware gets new features that people want to use from that API, API gains extension to use that hardware feature. CUDA is no different, in fact, often worse. Nvidia is bad at documenting which hardware does what things, and CUDA users often have to use third party tables to figure out what hardware can'…

The other platforms have better ways to deal with progress instead of "here find entries on dynamic libraries by yourself", and good luck.

Profiles and API versions are much better approaches.

It is no accident than the ongoing efforts to make Vulkan more friendly are moving away from extension spaghetti into profiles.

Post reply on HN