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"
AMD funded a drop-in CUDA implementation built on ROCm: It's now open-source
151–160 of 425 posts
Re: AMD funded a drop-in CUDA implementation built on ROCm: It's now open-source
#152Earlier 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…
CUDA currently has the better raw performance, better availability, and a long record indicating that the platform won't just disappear in a couple of years. You can use it on pretty much any NVIDIA GPU and it's properly supported. The same CUDA code that ran on a GTX680 can run on an RTX4090 with minimal changes if any (maybe even the same binary).
In comparison, AMD has a very spotty record with their compute technologies, stuff gets released and becomes effectively abandonware, or after just a few years support gets dropped regardless of the hardware's popularity. For several generations they basically led people on with promises of full support on consumer hardware that either never arrived or arrived when the next generation of cards were already available, and despite the general popularity of the rx580 and the popularity of the Radeon VII in compute applications, they dropped 'official' support. AMD treats its 'consumer' cards as third class citizens for compute support, but you aren't going to convince people to seriously look into your platform like that. Plus, it's a lot more appealing to have "GPU acceleration will allow us to take advantage of newer supercomputers, while also offering massive benefits to regular users" than just the former.
This was ultimately what removed AMD as a consideration for us when we were deciding on which to focus on for GPU acceleration in our application. Many of us already had access to an NVIDIA GPU of any sort, which would make development easier, while the entire facility had one ROCm capable AMD GPU at the time, specifically so they could occasionally check in on its status.
Re: AMD funded a drop-in CUDA implementation built on ROCm: It's now open-source
#153Why 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
#154Earlier 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.
Intel embraced Amd64 ditching Itanium. Wasn't it a good decision that worked out well? Is it comparable?
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 top of it.
Re: AMD funded a drop-in CUDA implementation built on ROCm: It's now open-source
#155Earlier 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…
Common API means being replaceable, fungible. There are no margins in that.
Re: AMD funded a drop-in CUDA implementation built on ROCm: It's now open-source
#156Why 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 right path for AMD has always been to make their own API that runs on all of their own hardware, just as CUDA does for Nvidia, and push support for that API into all the open source ML projects (but mostly PyTorch), while attacking Nvidia's price discrimination by providing features they use to segment the market (e.g. virtualization, high VRAM) at lower price points.
Perhaps one day AMD will realize this. It seems like they're slowly moving in the right direction now, and all it took for them to wake up was Nvidia's market cap skyrocketing to 4th in the world on the back of their AI efforts...
Re: AMD funded a drop-in CUDA implementation built on ROCm: It's now open-source
#157Earlier quoted context omitted.
> 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…
> 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…
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 ROCm or whatever AMD is working on at that time.
Re: AMD funded a drop-in CUDA implementation built on ROCm: It's now open-source
#158Earlier quoted context omitted.
Is it? Apple Silicon exists, but Apple created a translation layer above it so the transition could be smoother.
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…
Not at all, the performance hit was in the low 10s %, before natively supporting Apple Silicon most of the apps I use for music/video/photography didn't seem to have a performance impact at all, even more when the M1 machines were so much faster than the Intels.
Re: AMD funded a drop-in CUDA implementation built on ROCm: It's now open-source
#159AMD fail to realize software toolchain is what makes nvidia great. AMD thinks the hardware is all that’s needed
ROCm has different bugs, which the application workarounds tend to miss.
Re: AMD funded a drop-in CUDA implementation built on ROCm: It's now open-source
#160Why is CUDA so prevalent oppose to its alternatives?