Live data from Hacker News

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

phoronix.com

61–70 of 425 posts

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

#61
post #50

Earlier quoted context omitted.

x86 is not the same, the courts forced the release of x86 architecture to AMD during an antitrust lawsuit

You don't think the courts would force the opening of CUDA? Didn't a court already rule that API cannot be patented. I believe it was a Google case. As long as no implementation was stolen, the API itself is not able to be copyrighted. Here it is: https://arstechnica.com/tech-policy/2021/04/how-the-supreme-...

Regardless of the legal status of APIs, this Phoronix article is about AMD providing a replacement ABI and I wouldn't assume the legal issues are necessarily the same. But because this is a case where AMD is following a software target there's the possibility, if AMD starts to succeed, that NVidia might change their ABI in ways that deliberatly hurt AMD's compatibility efforts in ways that would be much more difficult for APIs or hardware. That's, presumably, why AMD is going forward with their API emulation effort instead.

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

#62
post #40

Earlier quoted context omitted.

If the alternative it to ignore one of the biggest developing markets then yeah, maybe they should start trying to catch up. Unless you think GPU compute is a fad that's going to fizzle out?

One of the most important decisions a company can do, is to decide which markets they'll focus in and which they won't. This is even true for megacorps (see: Google and their parade of messups). There's just not enough time to be in all markets all at once. So, again, it's not at all clear that AMD being in the compute GPU game is the automatic win for them in the future. There's plenty of companies that killed thems…

AMD is literally the only company on the market poised to exploit the explosion in demand for GPU compute after nVidia (sorry Intel). To not even really try to break in is insanity. nVidia didn't grow their market cap by 5x over the course of a year because people really got into 3D gaming. Even as an also ran on the coat tails of nVidia with a compatibility glue library the market is clearly demanding more product.

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

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

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

#64
post #50

Earlier quoted context omitted.

You don't think the courts would force the opening of CUDA? Didn't a court already rule that API cannot be patented. I believe it was a Google case. As long as no implementation was stolen, the API itself is not able to be copyrighted. Here it is: https://arstechnica.com/tech-policy/2021/04/how-the-supreme-...

Regardless of the legal status of APIs, this Phoronix article is about AMD providing a replacement ABI and I wouldn't assume the legal issues are necessarily the same. But because this is a case where AMD is following a software target there's the possibility, if AMD starts to succeed, that NVidia might change their ABI in ways that deliberatly hurt AMD's compatibility efforts in ways that would be much more difficul…

If you read the article, it's about Google's re-implementation of the Java API and runtime. Thus, yes, Google was providing both API and ABI compatibility.

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

#65
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…

This feels like a massive punch in the gut. An opensource project, not ruined by AMD's internal mismanaged gets shit done within two years and AMD goes "meh"?!? There are billions of dollars on the line! It's like AMD actively hates it's customers.

Now the only thing they need to do is make sure ROCm itself is stable.

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

#66

ROCm is not spelled out anywhere in their documentation and the best answers in search come from Github and not AMD official documents "Radeon Open Compute Platform" https://github.com/ROCm/ROCm/issues/1628 And they wonder why they are losing. Branding absolutely matters.

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 perspective, but I think it's shortsighted and a bad idea. GPUs are very competent compute devices, and basically wasting all that performance for "only" gaming is strange to me. AI and other compute is getting more and more important for things like image and video processing, language models, etc. Not only for regular consumers, but for enthusiasts and developers it makes a lot of sense to be able to use your 10 TFLOPS chip even when you're not gaming.

While reading through the AMD CDNA whitepaper I saw this and got a good chuckle. "culmination of years of effort by AMD" indeed.

> The computational resources offered by the AMD CDNA family are nothing short of astounding. However, the key to heterogeneous computing is a software stack and ecosystem that easily puts these abilities into the hands of software developers and customers. The AMD ROCm 4.0 software stack is the culmination of years of effort by AMD to provide an open, standards-based, low-friction ecosystem that enables productivity creating portable and efficient high-performance applications for both first- and third-party developers.

https://www.amd.com/content/dam/amd/en/documents/instinct-bu...

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

#67
post #35

ROCm is not spelled out anywhere in their documentation and the best answers in search come from Github and not AMD official documents "Radeon Open Compute Platform" https://github.com/ROCm/ROCm/issues/1628 And they wonder why they are losing. Branding absolutely matters.

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

Cleverly Undermining Disorganized AMD

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

#68
post #23
post #11

Earlier quoted context omitted.

They would always be at the mercy of NVIDIA's API. Without knowing the inner workings, perhaps a major concern with this approach is the need to implement on NVIDIA's schedule instead of AMD's which is a very reactive stance. This approach actually would make sense if AMD felt, like most of us perhaps, that the NVIDIA ecosystem is too entrenched, but perhaps they made the decision recently to discontinue funding beca…

They've been at mercy of Intel x86 APIs for a long time. Didn't kill them. What happens here is that the original vendor loses control of the API once there are multiple implementations. That's the best possible outcome for AMD. In either case, they have a limited window to be adopted, and that's more important. The abstraction layer here helps too. AMD code is !@#$%. If this were adopted, it makes it easier to fix t…

My understanding is that with AMD64 there's a circular dependency where AMD need Intel for x86 and Intel need AMD for x86_64?

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

#69
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…

It certainly seems ironic that the company that beat Intel at its own compatibility game with x86-64 would abandon compatibility with today's market leader.

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

#70
post #10

Earlier quoted context omitted.

According to the article, AMD seems to have pulled the plug on this as they think it will hinder ROCMv6 adoption, which still btw only supports two consumer cards out of their entire line up[1] 1. https://www.phoronix.com/news/AMD-ROCm-6.0-Released

With the most recent card being their one year old flagship ($1k) consumer GPU... Meanwhile CUDA supports anything with Nvidia stamped on it before it's even released. They'll even go as far as doing things like adding support for new GPUs/compute families to older CUDA versions (see Hopper/Ada and CUDA 11.8). You can go out and buy any Nvidia GPU the day of release, take it home, plug it in, and everything just work…

You've got to remember that AMD are behind at all aspects of this, including documenting their work in an easily digestible way.

"Support" means that the card is actively tested and presumably has some sort of SLA-style push to fix bugs for. As their stack matures, a bunch of cards that don't have official support will work well [0]. I have an unsupported card. There are horrible bugs. But the evidence I've seen is that the card will work better with time even though it is never going to be officially supported. I don't think any of my hardware is officially supported by the manufacturer, but the kernel drivers still work fine.

> Meanwhile CUDA supports anything with Nvidia stamped on it before it's even released...

A lot of older Nvidia cards don't support CUDA v9 [1]. It isn't like everything supports everything, particularly in the early part of building out capability. The impression I'm getting is that in practice the gap in strategy here is not as large as the current state makes it seem.

[0] If anyone has bought an AMD card for their machine to multiply matrices they've been gambling on whether the capability is there. This comment is reasonable speculation, but I want to caveat the optimism by asserting that I'm not going to put money into AMD compute until there is some some actual evidence on the table that GPU lockups are rare.

[1] https://en.wikipedia.org/wiki/CUDA#GPUs_supported

Post reply on HN