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…
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
AMD funded a drop-in CUDA implementation built on ROCm: It's now open-source
101–110 of 425 posts
Re: AMD funded a drop-in CUDA implementation built on ROCm: It's now open-source
#102Why 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 brings back memories of late 90s / early 00s of Microsoft pushing hard their proprietary graphic libraries (DirectX) vs open standards (OpenGL).
Fast forward 25-years and even today, Microsoft still dominates in PC gaming as a result.
There's a bad track record of open standard for GPUs.
Even Apple themselves gave up on OpenGL and has their own proprietary offering (Metal).
Re: AMD funded a drop-in CUDA implementation built on ROCm: It's now open-source
#103Earlier quoted context omitted.
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
#104Why 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
#105It 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…
If they want me as a customer, and they have not created a viable alternative to CUDA, they need to pursue this.
Re: AMD funded a drop-in CUDA implementation built on ROCm: It's now open-source
#106Earlier 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.
> The problem with effectively supporting CUDA is that encourages CUDA adoption all the more strongly. I'm curious about this. Sure some CUDA code has already been written. If something new comes along that provides better performance per dollar spent, why continue writing CUDA for new projects? I don't think the argument that "this is what we know how to write" works in this case. These aren't scripts you want someo…
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 only then, if they can start actually producing cards with equivalent performance (also a big stretch) they can try for an Embrace Extend Extinguish play against CUDA.
Re: AMD funded a drop-in CUDA implementation built on ROCm: It's now open-source
#107Why 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.
Worked fine for MS with Excel supporting Lotus 123 and Word supporting WordPerfect's formats when those were dominant...
Re: AMD funded a drop-in CUDA implementation built on ROCm: It's now open-source
#108ROCm 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.
My understanding is that there was some trademark silliness around "open compute", and AMD decided that instead of doing a full rebrand, they would stick to ROCm but pretend that it wasn't ever an acronym.
Re: AMD funded a drop-in CUDA implementation built on ROCm: It's now open-source
#109Earlier quoted context omitted.
With Nvidia controlling 90%+ of the market, this is not a viable option. They'd better lean hard into CUDA support if they want to be relevant.
A bit of story telling here: IBM and Microsoft made OS/2. The first version worked on 286s and was stable but useless. The second version worked only on 386s and was quite good, and even had wonderful windows 3.x compatibility. "Better windows than windows!" At that point Microsoft wanted out of the deal and they wanted to make their newer version of windows, NT, which they did. IBM now had a competitor to "new" wind…
Windows NT wasn't really relevant in that competition for much longer, only XP was finally for end consumers.
> where nvidia has the standard that AMD is implementing, and so no matter what if you play in the backward compatibility realm you're always going to be playing catch-up
That's not true. If AMD starts adding their own features and have their own advantages, that can flip.
It only takes a single generation of hardware, or a single feature for things to flip.
Look at Linux and Unix. Its started out with Linux implementing Unix, and now the Unix are trying to add compatibility with with Linux.
Is SGI still the driving force behind OpenGL/Vulcan? Did you think it was a bad idea for other companies to use OpenGL?
AMD was successful against Intel with x86_64.
There are lots of example of the company making something popular, not being able to take full advantage of it in the long run.
Re: AMD funded a drop-in CUDA implementation built on ROCm: It's now open-source
#110Earlier 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
AMD should have the funds to push both of these initiatives at once. If the ROCM team has political reasons to kill the competition, it is because they are scared it will succeed. I've seen this happen in big companies. But management at AMD should be above petty team politics and fund both because at the company level they do not care which solution wins in the end.
Good enough CUDA + New feature x gives them leverage in the inevitable court battle(S) and patten sharing agreement that everyone wants to see.
AMD' already stuck its toe in the water: new CPU's with their AI cores built in. If you can get a AM5 socket to run with 196 gigs, that's a large (all be it slow) model you can run.