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

271–280 of 425 posts

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

#271

Post by stonogo »

slavik81 wrote: post #111
sorenjan wrote: post #66

Earlier quoted context omitted.

Funnily enough it doesn't work on their RDNA ("Radeon DNA") hardware (with some exceptions I think), but it's aimed at their CDNA (Compute DNA). If they would come up with a new name today it probably wouldn't include Radeon. AMD seems to be a firm believer in separating the consumer chips for gaming and the compute chips for everything else. This probably makes a lot of sense from a chip design and current business…

ROCm works fine on the RDNA cards. On Ubuntu 23.10 and Debian Sid, the system packages for the ROCm math libraries have been built to run on every discrete Vega, RDNA 1, RDNA 2, CDNA 1, and CDNA 2 GPU. I've manually tested dozens of cards and every single one worked. There were just a handful of bugs in a couple of the libraries that could easily be fixed by a motivated individual. https://slerp.xyz/rocm/logs/full/ T…

It doesn't matter to my lab whether it technically runs. According to https://rocm.docs.amd.com/projects/install-on-linux/en/lates... it only supports three commercially-available Radeon cards (and four available Radeon Pro) on Linux. Contrast this to CUDA, which supports literally every nVIDIA card in the building, including the crappy NVS series and weirdo laptop GPUs, and it basically becomes impossible to convince anyone to develop for ROCm.

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

#272

Post by BizarroLand »

paulmd wrote: post #229
BizarroLand wrote: post #184

Earlier quoted context omitted.

Todays linux OS's would have competed incredibly strongly against Vista and probably would have gone blow for blow against 7. Proton, Wine, and all of the compatibility fixes and drive improvements that the community has made in the last 16 years has been amazing, and every day is another day where you can say that it has never been easier to switch away from Windows. However, Microsoft has definitely been drinking t…

> However, Microsoft has definitely been drinking the IBM koolaid a little to long and has lost the mandate of heaven. I think in the next 7-10 years we will reach a point where there is nothing Windows can do that linux cannot do better and easier without spying on you that's a fascinating statement with the clear ascendancy of neural-assisted algorithms etc. Things like DLSS are the future - small models that just…

Counterpoint: Most AI stuff is developed on either an OS agnostic language like Python or C, and then ported to Linux/OSX/Windows, so for AI it is less about the OS it runs on than the hardware, drivers, and/or connections that the OS supports.

For the non-vendor lock in AI's (copilot), casting as wide of a net as possible to catch customers as easily as possible should by default mean that they would invest the small amount of money to build linux integrations into their AI platforms.

Plus, the googs has a pretty deep investment into the linux ecosystem and should have little issue pushing bard or gemini or whatever they'll call it next week before they kill it out into a linux compatible interface, and if they do that then the other big players will follow.

And, don't overlook the next generation of VR headsets. People have gotten silly over the Apple headset, but Valve should be rolling out the Deckhard soon and others will start to compete in that space since Apple raised the price bar and should soon start rolling out hardware with more features and software to take advantage of it.

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

#273

Post by nocombination »

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…

As other folks have commented, CUDA not being an open standard is a large part of the problem. That and the developers who target CUDA directly when writing Stable Diffusion algorithms—they are forcing the monopoly. Even at the cost of not being able to squeeze every ounce out of the GPU, portability greatly improves software access when people target Vulkan et al.

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

#274

Post by Uehreka »

bachmeier wrote: post #157
Uehreka wrote: post #106

Earlier quoted context omitted.

> If something new comes along that provides better performance per dollar spent They won’t be able to do that, their hardware isn’t fast enough. Nvidia is beating them at hardware performance, AND ALSO has an exclusive SDK (CUDA) that is used by almost all deep learning projects. If AMD can get their cards to run CUDA via ROCm, then they can begin to compete with Nvidia on price (though not performance). Then, and o…

> They won’t be able to do that, their hardware isn’t fast enough. Well, then I guess CUDA is not really the problem, so being able to run CUDA on AMD hardware wouldn't solve anything. > try for an Embrace Extend Extinguish play against CUDA They wouldn't need to go that route. They just need a way to run existing CUDA code on AMD hardware. Once that happens, their customers have the option to save money by writing R…

> Well, then I guess CUDA is not really the problem

It is. All the things are the problem. AMD is behind on both hardware and software, for both gaming and compute workloads, and has been for many years. Their competitor has them beat in pretty much every vertical, and the lock-in from CUDA helps ensure that even if AMD can get their act together on the hardware side, existing compute workloads (there are oceans of existing workloads) won’t run on their hardware, so it won’t matter for professional or datacenter usage.

To compete with Nvidia in those verticals, AMD has to fix all of it. Ideally they’d come out with something better than CUDA, but they have not shown an aptitude for being able to do something like that. That’s why people keep telling them to just make a compatibility layer. It’s a sad place to be, but that’s the sad place where AMD is, and they have to play the hand they’ve been dealt.

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

#275

Post by Jorropo »

hamandcheese wrote: post #144
Jorropo wrote: post #123

Earlier quoted context omitted.

This is extremely different, apple was targeting end consumers that just want their app to run. The performance between apple rosetta and native cpu were still multiple times different. People writing CUDA apps don't just want stuff to run, performance is an extremely important factor else they would target CPUs which are easier to program for. From their readme: > On Server GPUs, ZLUDA can compile CUDA GPU code to r…

> The performance between apple rosetta and native cpu were still multiple times different. Rosetta 2 runs apps at 80-90% their native speed.

Indeed I got that wrong. Sadly minimal SIMD and hardware acceleration support.

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

#276

Post by krab »

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…

Isn't API out of scope for copyright? In the case of CUDA, it seems they can copy most of it and then iterate in their own, keeping a compatible subset.

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

#277

Post by CuriousCosmic »

Keyframe wrote: post #173

This event of release is however a result of AMD stopped funding it per "After two years of development and some deliberation, AMD decided that there is no business case for running CUDA applications on AMD GPUs. One of the terms of my contract with AMD was that if AMD did not find it fit for further development, I could release it. Which brings us to today." from https://github.com/vosen/ZLUDA?tab=readme-ov-file#faq…

I mean it could also be that there was no business case for it as long as it remained closed source work.

If the now very clearly well functioning implementation continues to perform as well as it is, the community may be able to keep it funded and functioning.

And the other side of this is that with renewed AMD interest/support for the rocm/HIP project, it might be just good enough as a stopgap step to push projects towards rocm/HIP adoption. (included below is another blurb from the readme).

> I am a developer writing CUDA code, does this project help me port my code to ROCm/HIP?

> Currently no, this project is strictly for end users. However this project could be used for a much more gradual porting from CUDA to HIP than anything else. You could start with an unmodified application running on ZLUDA, then have ZLUDA expose the underlying HIP objects (streams, modules, etc.), allowing to rewrite GPU kernels one at a time. Or you could have a mixed CUDA-HIP application where only the most performance sensitive GPU kernels are written in the native AMD language.

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

#278

Post by smoldesu »

Avamander wrote: post #199
smoldesu wrote: post #124

Earlier quoted context omitted.

Those people should have spoken up when their hardware manufacturers abandoned OpenCL. The industry set itself 5-10 years behind by ignoring open GPGPU compute drivers while Nvidia slowly built their empire. Just look at how long it's taken to re-impliment a fraction of the CUDA featureset on a small handful of hardware. CUDA shouldn't exist. We should have hardware manufacturers working together , using common APIs…

Is my impression wrong, that people understood the need for OCL only after CUDA had already cornered and strangled the market?

You're mostly right. CUDA was a "sleeper product" that existed early-on but didn't see serious demand until later. OpenCL was Khronos Group's hedged bet against the success of CUDA; it was assumed that they would invest in it more as demand for GPGPU increased. After 10 years though, OpenCL wasn't really positioned to compete and CUDA was more fully-featured than ever. Adding insult to injury, OS manufacturers like Microsoft and Apple started to avoid standardized GPU libraries in favor of more insular native APIs. By the time demand for CUDA materialized, OpenCL had already been left for dead by most of the involved parties.

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

#279

Post by formerly_proven »

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

On the other hand:

> The next major ROCm release (ROCm 6.0) will not be backward [source] compatible with the ROCm 5 series.

Even worse, not even the driver is backwards-compatible:

> There are some known limitations though like currently only targeting the ROCm 5.x API and not the newly-released ROCm 6.x releases.. In turn having to stick to ROCm 5.7 series as the latest means that using the ROCm DKMS modules don't build against the Linux 6.5 kernel now shipped by Ubuntu 22.04 LTS HWE stacks, for example. Hopefully there will be enough community support to see ZLUDA ported to ROCM 6 so at least it can be maintained with current software releases.

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

#280

Post by hyperbovine »

rvnx wrote: post #86
phh wrote: post #35

Earlier quoted context omitted.

I have no idea what CUDA stands for, and I live just fine without knowing it.

Countless Updates Developer Agony

Lost five hours of my life yesterday discovering the fact that "CUDA 12.3" != "CUDA 12.3 Update 2".

(Yes, that's obvious, but not so obvious when your GPU applications submitted to a cluster start crashing randomly for no apparent reason.)

Post reply on HN