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

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

#421

Post by paulmd » Wed, Feb 14, 2024, 10:30 PM UTC

acchow wrote: post #373

kllrnohj wrote: post #302

Earlier quoted context omitted.

For some reason AMD's GPU division continues to be run, well, horribly. The CPU division is crushing it, but the GPU division is comically bad. During the great GPU shortage AMD had multiple opportunities to capture chunks of the market and secure market share, increasing the priority for developers to acknowledge and target AMD's GPUs. What did they do instead? Not a goddamn thing, they followed Nvidia's pricing and…

Does this have anything to do with AMD's GPU division being a result of an acquisition (ATI)?

I think it has a lot more to do with this: https://youtu.be/590h3XIUfHg?t=1956

AMD fundamentally viewed/views GPUs as nothing more than a tool to make semicustom deals. Just like "xbox isn't the product, gamepass is the product" - well, for AMD "radeon isn't the product, semicustom is the product". The only thing they really need graphics for is APUs, and they don't need to beat the 4090, they just need to beat Xe-LP. They don't need raytracing, they don't need that "AI" crap (oops), just to run games at 720p/1080p.

They're happy to squeeze whatever they can out of Sony/MS's R&D spend, but they aren't going to invest heavily on their own. And now that there is an obvious money fountain occurring in AI/ML... that is starting to change.

It was always about the money, specifically the lack of it. AMD knew HSA-Library/OpenCL/etc sucked, they didn't care, especially when the money was better spent going after Intel instead of NVIDIA. Intel is dysfunctional and AMD had a chance to crack their marketshare, and that's where every penny they had went. And that's probably not a wrong business decision.

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

#422

Post by smcl » Fri, Feb 16, 2024, 8:37 AM UTC

bigdict wrote: post #290

smcl wrote: post #261

Earlier quoted context omitted.

I know that Lina doesn't like a lot of the attention HN sends her way so it may be better if you don't link her socials here.

Sounds ridiculous, why have a public presence on a social network then?

She's gotten a fair amount of unwanted attention from HN specifically, guys trying to dox her and stirring rumours about her. Like just mean-spirited stuff, and if you or I had experienced this then we'd likely feel the same animosity towards HN.

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

#423

Post by CoolCold » Fri, Feb 16, 2024, 11:18 AM UTC

swozey wrote: post #197

bick_nyers wrote: post #162

Earlier quoted context omitted.

The latest version of CUDA is 12.3, and version 12.2 came out 6 months prior. How many people are running an older version of CUDA right now on NVIDIA hardware for whatever particular reason? Even if AMD lagged support on CUDA versioning, I think it would be widely accepted if the performance per dollar at certain price points was better. Taking the whole market from NVIDIA is not really an option, it's better to att…

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…

> halfway into it my WSL2 completely broke and I had to reinstall windows

I'm curios, so WSL2 broke that you cannot even add new distros, remove broken distros? or Windows host itself became unstable?

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

#424

Post by paulmd » Sat, Feb 17, 2024, 8:40 AM UTC

incrudible wrote: post #409

paulmd wrote: post #317

Earlier quoted context omitted.

I think we're well past the "dlss is just FSR2 with lookup tables, you can ALWAYS replicate the outcomes of neural algorithms with deterministic ones" phase, imo. if that's the case you have billion-dollar opportunities waiting for you to prove it!

Floating point inaccuracies and random seeds aside, something like DLSS is entirely deterministic. It is just a bunch of matrix multiplications.

You can’t possibly expect me to take your post seriously when there’s not even any true evidence of cognition involved in its writing. Just some meat flopping around spastically from some chemicals pumped up from the gut, and electrical zaps from the nervous system.

We can see that it’s not magic, the neuron either activates or it doesn’t, so why should I pay attention to some probabilistic steam of gibberish it spewed out? There is nothing meaningful that can be inferred from such systems, right?

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

#425

Post by mtrower » Mon, Feb 19, 2024, 7:05 PM UTC

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…

This is the exact reason* I bought a 4090 for my recent rebuild instead of the rDNA card I actually wanted. I really wanted to go with AMD for the driver integration with the Linux graphics stack —- I’m so, so tired of shenanigans when it comes to decades old features of X not working or working poorly due to some nvidia bug/non-integration.

But being able to leverage my graphics card for GPGPU was a top priority for me, and like you, I was appalled with the ROCm situation. Not necessarily the tech itself (though I did not enjoy the docker approach), but more the developer situation surrounding it.

* well, that and some vague notions about RTX