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

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

phoronix.com

Post reply on HN
Print view View original

211–220 of 425 posts

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

#211

Post by jchw »

ethbr1 wrote: post #203
hjabird wrote: post #167

Earlier quoted context omitted.

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.

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 op…

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.

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

#212

Post by whywhywhywhy »

btown wrote: post #8

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…

> Why would this not be AMD’s top priority among priorities?

Same reason it wasn't when it was obvious Nvidia was taking over this space maybe 8 years ago now when they let OpenCL die then proceeded to do nothing till it's too late.

Speaking to anyone working in general purpose GPU coding back then they all just said the same thing, OpenCL was a nightmare to work with and CUDA was easy and mature compared to it. Writing was on the wall where things were heading the second you saw a photon based renderer running on GPU vs CPU all the way back then, AMD has only themselves to blame because Nvidia basically showed them the potential with CUDA.

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

#213

Post by phero_cnstrcts »

btown wrote: post #8

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…

Because the two CEOs are family? Like literally.

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

#214

Post by trynumber9 »

jandrese wrote: post #25
btown wrote: post #8

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…

AMD's management seems to be only vaguely aware that GPU compute is a thing. All of their efforts in the field feel like afterthoughts. Or maybe they are all just hardware guys who think of software as just a cost center.

That doesn't explain CDNA. They focused on high-throughput FP64 which is not where the market went.

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

#215

Post by whywhywhywhy »

Cu3PO42 wrote: post #122

I'm really rooting for AMD to break the CUDA monopoly. To this end, I genuinely don't know whether a translation layer is a good thing or not. On the upside it makes the hardware much more viable instantly and will boost adoption, on the downside you run the risk that devs will never support ROCm, because you can just use the translation layer. I think this is essentially the same situation as Proton+DXVK for Linux g…

> I'm really rooting for AMD to break the CUDA monopoly

Personally I want Nvidia to break the x86-64 monopoly, with how amazing properly spec'd Nvidia cards are to work with I can only dream of a world where Nvidia is my CPU too.

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

#216

Post by jvanderbot »

hjabird wrote: post #63
btown wrote: post #8

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…

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.

If you replace CUDA -> x86 and NVIDIA -> Intel, you'll see a familiar story which AMD has already proved it can work through.

These were precisely the arguments for 'x86 will entrench Intel for all time', and we've seen AMD succeed at that game just fine.

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

#217

Post by ianlevesque »

jvanderbot wrote: post #216
hjabird wrote: post #63

Earlier quoted context omitted.

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.

If you replace CUDA -> x86 and NVIDIA -> Intel, you'll see a familiar story which AMD has already proved it can work through. These were precisely the arguments for 'x86 will entrench Intel for all time', and we've seen AMD succeed at that game just fine.

And indeed more than succeed, they invented x86_64.

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

#218

Post by kuschkufan »

whywhywhywhy wrote: post #215
Cu3PO42 wrote: post #122

I'm really rooting for AMD to break the CUDA monopoly. To this end, I genuinely don't know whether a translation layer is a good thing or not. On the upside it makes the hardware much more viable instantly and will boost adoption, on the downside you run the risk that devs will never support ROCm, because you can just use the translation layer. I think this is essentially the same situation as Proton+DXVK for Linux g…

> I'm really rooting for AMD to break the CUDA monopoly Personally I want Nvidia to break the x86-64 monopoly, with how amazing properly spec'd Nvidia cards are to work with I can only dream of a world where Nvidia is my CPU too.

apt username

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

#219

Post by katbyte »

bick_nyers wrote: post #209
swozey wrote: post #197

Earlier quoted context omitted.

I just went through this this weekend - If you're running in Windows and want to use deepspeed, you have to still use Cuda 12.1 because deepspeed 13.1 is the latest that works with 12.1. There's no deepspeed for windows that works with 12.3. I tried to get it working this weekend but it was a huge PITA so I switched to putting everything into WSL2 then in arch on there pytorch etc in containers so I could flip versio…

Vent away! Sounds frustrating for sure. As much as I love Microsoft/Windows for the work they have put into WSL, I ended up just putting Kubuntu on my devices and use QEMU with GPU passthrough whenever I need Windows. Gaming perf is good. You need an iGPU or a cheap second GPU for Linux in order to hand off a 4090 etc. to Windows (unless maybe your motherboard happens to support headless boot but if it's a consumer b…

I recently gave this a go as I’d not had a windows desktop for a long time, have a beefy Proxmox server and wanted to play some windows only games - works shockingly well with an a4000 and 35m optical hdmi cables! - however I’m getting random audio crackling and popping and I’ve yet to figure out what’s causing it.

First I thought it was hardware related in a Remote Desktop session leading me to think some weird audio driver thing

have you encountered anything like this at all?

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

#220

Post by zozbot234 »

jchw wrote: post #211
ethbr1 wrote: post #203

Earlier quoted context omitted.

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 op…

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.

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.)

Post reply on HN