←back to thread

AMD funded a drop-in CUDA implementation built on ROCm: It's now open-source

(www.phoronix.com)
1045 points mfiguiere | 4 comments | 12 Feb 24 14:00 UTC | HN request time: 0.001s | source
Show context
btown ◴[12 Feb 24 14:37 UTC] No.39345221[source]▶
Why would this not be AMD’s top priority among priorities? Someone recently likened the situation to an Iron Age where NVIDIA owns all the iron. And this sounds like AMD knowing about a new source of ore and not even being willing to sink a single engineer’s salary into exploration.

My only guess is they have a parallel skunkworks working on the same thing, but in a way that they can keep it closed-source - that this was a hedge they think they no longer need, and they are missing the forest for the trees on the benefits of cross-pollination and open source ethos to their business.

replies(14): >>39345241 #>>39345302 #>>39345393 #>>39345400 #>>39345458 #>>39345853 #>>39345857 #>>39345893 #>>39346210 #>>39346792 #>>39346857 #>>39347433 #>>39347900 #>>39347927 #
hjabird ◴[12 Feb 24 15:26 UTC] No.39345853[source]▶
The problem with effectively supporting CUDA is that encourages CUDA adoption all the more strongly. Meanwhile, AMD will always be playing catch-up, forever having to patch issues, work around Nvidia/AMD differences, and accept the performance penalty that comes from having code optimised for another vendor's hardware. AMD needs to encourage developers to use their own ecosystem or an open standard.
replies(13): >>39345944 #>>39346147 #>>39346166 #>>39346182 #>>39346270 #>>39346295 #>>39346339 #>>39346835 #>>39346941 #>>39346971 #>>39347964 #>>39348398 #>>39351785 #
1. hjabird ◴[12 Feb 24 16:41 UTC] No.39346971[source]▶
There are some great replies to my comment - my original comment was too reductive. However, I still think that entrenching CUDA as the de-facto language for heterogeneous computing is a mistake. We need an open ecosystem for AI and HPC, where vendors compete on producing the best hardware.
replies(1): >>39347760 #
2. ethbr1 ◴[12 Feb 24 17:37 UTC] No.39347760[source]▶
The problem with open standards is that someone has to write them.

And that someone usually isn't a manufacturer, lest the committee be accused of bias.

Consequently, you get (a) outdated features that SotA has already moved beyond, (b) designed in a way that doesn't correspond to actual practice, and (c) that are overly generalized.

There are some notable exceptions (e.g. IETF), but the general rule has been that open specs please no one, slowly.

IMHO, FRAND and liberal cross-licensing produce better results.

replies(1): >>39347872 #
3. jchw ◴[12 Feb 24 17:45 UTC] No.39347872[source]▶
Vulkan already has some standard compute functionality. Not sure if it's low level enough to be able to e.g. recompile and run CUDA kernels, but I think if people were looking for a vendor-neutral standard to build GPGPU compute features on top of, I mean, that seems to be the obvious modern choice.
replies(1): >>39348062 #
4. zozbot234 ◴[12 Feb 24 17:57 UTC] No.39348062{3}[source]▶
There is already a work-in-progress implementation of HIP on top of OpenCL https://github.com/CHIP-SPV/chipStar and the Mesa RustiCL folks are quite interested in getting that to run on top of Vulkan.

(To be clear, HIP is about converting CUDA source code not running CUDA-compiled binaries but the Zluda project discussed in OP heavily relies on it.)