Open-Source AMD GPU Implementation of CUDA "Zluda" Has Been Taken Down | Hacker News Reader

Open-Source AMD GPU Implementation of CUDA "Zluda" Has Been Taken Down

phoronix.com

39 pointsTiredOfLife16 comments

Open articleView on HN

I'm confused by this. It's open source, it's been forked. The code doesn't disappear because you delete one copy of it.

This move primarily makes AMD legal look frightened of Nvidia, which seems a bad thing to put out there on every axis.

Grab Version 3 source code from the releases section while you still can!

https://github.com/vosen/ZLUDA/releases

... or mirror a recently updated fork. :)

https://github.com/vosen/ZLUDA/forks?include=active&page=1&p...

It seems the last commit to master was 9e56862.

I don't quite get the strategy at AMD here. This would have allowed them to compete directly with NVIDIA.

And by none other than AMD themselves.

Disappoining. Nvidia wouldn't have surprised me at all, but amd seems to be turning more and more into this. Inevitable if you're successful enough?

Not the first time it happens. Another drop-in replacement for CUDA was also stopped in its tracks last decade by them.

The surprise here is that AMD was sponsoring it.

I wonder if we could train an LLM to port CUDA to Metal, OpenCL, etc?

Seems like the lock in here actually isn’t that powerful. Fundamentally it’s math implemented in a C-like language.

The lock-in is mostly in libraries and tooling. It's not really your CUDA code that is the issue.

You would need to translate CUDA already compiled for an Nvidia GPU to e.g. OpenCL that runs fast on an AMD GPU, which is close AGI level in difficulty.

People keep forgetting CUDA is polyglot, and then there is the graphical tooling, IDE integration, and libraries ecosystem.

This has already been done multiple times without using LLMs. For HIP, there are tools like hipify-clang, hipify-perl, and hipify (the Python-based tool in PyTorch). For SYCL, there is SYCLomatic.

The devil is in the details, though; at some point, all projects encounter non-portable code due to different instruction sets. For example, if the hardware does not support Warpgroup Level Multiply-and-Accumulate or a specific minifloat format, it is actively harmful to translate the code 'as is.' These platforms require software redesign, which is not something that LLMs are currently capable of handling.

AMD makes it really hard to cheer for them, even with such a desperate need for competition to keep nVidia honest.

I can understand AMD not actively working on this solution since it gains them little while costing a hefty amount of developer time. Especially considering the fact that nVidia will be able to arbitrarily break this implementation with every update. What I don't understand is why they would take it down completely, is there some safety concern or are we in the 11 competing standards xkcd again?

zluda is a thin wrapper around ROCm. AMD is investing heavily into ROCm.

Reply on news.ycombinator.com