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

231–240 of 425 posts

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

#231

Post by outside415 »

RamRodification wrote: post #94
lambdaone wrote: post #75

It seems to me that AMD are crazy to stop funding this. CUDA-on-ROCm breaks NVIDIA's moat, and would also act as a disincentive for NVIDIA to make breaking changes to CUDA; what more could AMD want? When you're #1, you can go all-in on your own proprietary stack, knowing that network effects will drive your market share higher and higher for you for free. When you're #2, you need to follow de-facto standards and work…

> and would also act as a disincentive for NVIDIA to make breaking changes to CUDA I don't know about that. You could kinda argue the opposite. "We improved CUDA. Oh it stopped working for you on AMD hardware? Too bad. Buy Nvidia next time"

NVIDIA is about ecosystem plays, they have no interest in sabotage or anti competition plays. Leave that to apple and google and their dumb app stores and mobile OSs.

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

#232

Post by zozbot234 »

cogman10 wrote: post #207
teucris wrote: post #192

Earlier quoted context omitted.

There haven’t been any as successful, but there have been competitors. OpenCL, DirectX come to mind.

SYCL is the latest attempt that I'm aware of. It's still pretty active and may just work as it doesn't rely on video card manufactures to work out.

SYCL is the quasi-successor to OpenCL, built on the same flavor of SPIR-V. Various efforts are trying to run it on top of Vulkan Compute (which tends to be broadly support by modern GPU's) but it's non-trivial because the technologies are independently developed and there are some incompatibilities.

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

#233

Post by mindcrime »

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.

Yep. This is very similar to the "catch-22" that IBM wound up in with OS/2 and the Windows API. On the one hand, by supporting Windows software on OS/2, they gave OS/2 customers access to a ready base of available, popular software. But in doing so, they also reduced the incentive for ISV's to produce OS/2 native software that could take advantage of unique features of OS/2.

It's a classic "between a rock and a hard place" scenario. Quite a conundrum.

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

#234

Post by sangnoir »

ianlevesque wrote: post #217
jvanderbot wrote: post #216

Earlier quoted context omitted.

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.

x86_64's win was helped by Intel's Itanium misstep. AMD can't bank on Nvidia making a mistake, and Nvidia seems content with incremental changes to CUDA, contrasted with Intel's 32-bit to 64-bit transition. It is highly unlikely that AMD can find and exploit a similar chink in the amor against CUDA.

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

#235

Post by clhodapp »

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.

If that's the model, it sounds like the path would be to burn money to stay right behind NVIDIA and wait for them to become complacent and stumble technically, creating the opportunity to leapfrog them. Keeping up could be very expensive if they don't force something like the mutual licensing requirements around x86.

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

#236

Post by kevin_thibedeau »

kllrnohj wrote: post #154
kgeist wrote: post #98

Earlier quoted context omitted.

Intel embraced Amd64 ditching Itanium. Wasn't it a good decision that worked out well? Is it comparable?

Intel & AMD have a cross-license agreement covering everything x86 (and x86_64) thanks to lots and lots of lawsuits over their many years of competition. So while Intel had to bow to AMD's success and give up Itanium, they weren't then limited by that and could proceed to iterate on top of it. Meanwhile it'll be a cold day in hell before Nvidia licenses anything about CUDA to AMD, much less allows AMD to iterate on t…

The original cross licensing was government imposed because a second source was needed for the military.

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

#237

Post by ianlevesque »

mindcrime wrote: post #233
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.

Yep. This is very similar to the "catch-22" that IBM wound up in with OS/2 and the Windows API. On the one hand, by supporting Windows software on OS/2, they gave OS/2 customers access to a ready base of available, popular software. But in doing so, they also reduced the incentive for ISV's to produce OS/2 native software that could take advantage of unique features of OS/2. It's a classic "between a rock and a hard…

Thinking about the highly adjacent graphics APIs history, did anyone really 'win' the Direct3D, OpenGL, Metal, Vulkan war? Are we benefiting from the fragmentation?

If the players in the space have naturally coalesced around one over the last decade, can we skip the thrashing and just go with it this time?

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

#239

Post by atq2119 »

kevin_thibedeau wrote: post #236
kllrnohj wrote: post #154

Earlier quoted context omitted.

Intel & AMD have a cross-license agreement covering everything x86 (and x86_64) thanks to lots and lots of lawsuits over their many years of competition. So while Intel had to bow to AMD's success and give up Itanium, they weren't then limited by that and could proceed to iterate on top of it. Meanwhile it'll be a cold day in hell before Nvidia licenses anything about CUDA to AMD, much less allows AMD to iterate on t…

The original cross licensing was government imposed because a second source was needed for the military.

Makes you wonder why DoE labs and similar facilities don't mandate open licensing of CUDA.

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

#240

Post by swozey »

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…

Are you flipping from your main GPU to like a GT710 to do the gpu vfio mount? Or can you share the dgpu directly and not have to go headless now?

I've done this on both a hackintosh and void linux. I was so excited to get the hackintosh working because I honestly hate day desktop linux, it's my day job to work on and I just don't want to deal with it after work.

Unfortunately both would break in significant ways and I'd have to trudge through and fix things. I had that void desktop backed up with Duplicacy (duplicati front end) and IIRC I tried to roll back after breaking qemu, it just dumps all your backup files into their dirs, and I think I broke it more.

I think at that point I was back up in Windows in 30 mins.. and all of its intricacies like bsoding 30% of the time that I either restart it or unplug a usb hub. But my Macbooks have a 30% chance of not waking up on Monday morning when I haven't used them all weekend without me having to grab them and open the screen.

Post reply on HN