Live data from Hacker News

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

phoronix.com

401–410 of 425 posts

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

#401

Earlier quoted context omitted.

oh. I think the emphasis is on hacker news. you know certain social media sites contain certain toxic conversants.

> you know certain social media sites contain certain toxic conversants. That's just people…

yes, but the difference between flys gathering at shit and bees to honey.

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

#402
post #242

Earlier quoted context omitted.

I recently gave this a go as I’d not had a windows desktop for a long time, have a beefy Proxmox server and wanted to play some windows only games - works shockingly well with an a4000 and 35m optical hdmi cables! - however I’m getting random audio crackling and popping and I’ve yet to figure out what’s causing it. First I thought it was hardware related in a Remote Desktop session leading me to think some weird audi…

What are you running for audio? pipewire+jack, pipewire, jack2, pulseaudio? I wonder if it's from latency. Pulseaudio is the most common but if you do any audio engineering or play guitar etc with your machine we all use jack protocol for less latency. https://linuxmusicians.com/viewtopic.php?t=25556 Could be completely unrelated though, RDP sessions can definitely act up, get audio out of sync etc. I try to never do…

I have tried Optical usb cable to kvm to dac, audio over hdmi, and audio over rdp. All have the same crackle

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

#403

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…

Perhaps AMD realizes that if they released something like this in a formal capacity, they might face a barrage of lawsuits, and IP claims from Nvidia. If this is completed through an Open Source project however, in which AMD is not directly funding, Nvidia would not have many legal avenues to attack. Just an opinion.

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

#404

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…

How is this not priority #1 for them, with NVIDIA stock shooting to the moon because everyone does machine learning using CUDA-centric tools? If AMD could get 90% of the CUDA ML stuff to seamlessly run on AMD hardware, and could provide hardware at a competitive cost-per-performance (which I assume they probably could since NVIDIA must have an insane profit margin on their GPUs), wouldn't that be the opportunity to e…

[deleted]

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

#405
post #242

Earlier quoted context omitted.

What are you running for audio? pipewire+jack, pipewire, jack2, pulseaudio? I wonder if it's from latency. Pulseaudio is the most common but if you do any audio engineering or play guitar etc with your machine we all use jack protocol for less latency. https://linuxmusicians.com/viewtopic.php?t=25556 Could be completely unrelated though, RDP sessions can definitely act up, get audio out of sync etc. I try to never do…

I have tried Optical usb cable to kvm to dac, audio over hdmi, and audio over rdp. All have the same crackle

Oh it's every single rpd connection? That's definitely not normal to rdp at all. I used to be a windows engineer so I RDP'd a LOT. RDP was our ssh, lol.

Crackle would happen so rarely that I KNOW it definitely happened but it wasn't like a 2 day thing it was probably like, once in a year or 6 months, etc.

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

#406

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…

> Proton+DXVK for Linux gaming "Building the DirectX shader compiler better than Microsoft?" (2024) https://news.ycombinator.com/item?id=39324800 E.g. llama.cpp already supports hipBLAS; is there an advantage to this ROCm CUDA-compatibility layer - ZLUDA on Radeon (and not yet Intel OneAPI) - instead or in addition? https://github.com/ggerganov/llama.cpp?tab=readme-ov-file#hi... https://news.ycombinator.com/item?id=3…

BLAS will only get you so far. About the highest level operation it has is matmul, which you can use to build convolution (im2col, matmul, col2im), but that won't be as performant as a hand optimized cuDNN convolution kernel. Same goes for any other high level neural net building blocks - trying to build them on top of BLAS will not get you remotely close to performance of a custom kernel.

What's nice about BLAS is that there are optimized implementations for CPUs (Intel MKL) as well as NVIDIA (cuBLAS) and AMD (hipBLAS), so while it's very much limited in what it can do, you can at least write portable code around it.

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

#407
post #63

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

If you replace CUDA -> x86 and NVIDIA -> Intel, you'll see a familiar story which AMD has already proved it can work through. These were precisely the arguments for 'x86 will entrench Intel for all time', and we've seen AMD succeed at that game just fine.

The difference is that AMD's CPUs are designed to implement the x86 and x86-64 ISA, so there is no loss of performance. In contrast, AMD and NVIDA's GPU instruction sets and architectures are not the same, and to get top performance out of these architectures code needs to be customized for them.

If you slap a CUDA compatibility layer on top of AMD, then CUDA code optimized for NVIDIA chips would run, but would suffer a performance penalty compared to code that was customized/tuned for AMD, so unless AMD GPUs were sold cheap enough (i.e. with low profit margin) to mitigate this loss of performance you might as well buy NVIDIA in the first place.

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

#408
post #399

Earlier quoted context omitted.

Do you have any recent examples? This has never been my experience, and in the post I linked, other users fail to find such examples too. It also seems strange to me to complain about comments/posts that are moderated?

https://news.ycombinator.com/item?id=39336904 is an example - an article about astronomy has a single mention of gendered language which kicks off an entire mess

That's a mess...? Seems like a relatively innocent discussion to me. Thanks for the example though.

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

#409
post #317

Earlier quoted context omitted.

"Neural assisted algorithms" are just algorithms with large lookup tables. Another magnitude of binary bloat, but that's nothing we haven't experienced before. There's no need to fundamentally change the OS paradigm for it.

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.

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

#410
post #373

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)?

That was 17 years ago at this point
Post reply on HN