Why CUDA translation wont unlock AMD • Hacker News Board

Re: Why CUDA translation wont unlock AMD

#51

Post by jsolson » Thu, Nov 20, 2025, 3:28 AM UTC

apfsx wrote: post #43

stingraycharles wrote: post #34

Earlier quoted context omitted.

Google has their own TPUs so they don’t have any vendor lock-in issues at all. OpenAI OTOH is big enough that the vendor lock-in is actually hurting them, and them making that massive deal with AMD may finally push the needle for AMD and improve things in the ecosystem to make AMD a smooth experience.

Google’s TPU’s are not powering Gemini or whatever X equivalent LLM you want to compare to.

This comment is incorrect: https://storage.googleapis.com/deepmind-media/Model-Cards/Ge...

Re: Why CUDA translation wont unlock AMD

#52

Post by fulafel » Thu, Nov 20, 2025, 3:35 AM UTC

Vulkan Compute is catching up with HIP (or whatever the compatibility stuff is called now), which seems like a welcome break from CUDA - in this benchmark it beats CUDA in some benchmarks on AMD: https://www.phoronix.com/review/rocm-71-llama-cpp-vulkan

Re: Why CUDA translation wont unlock AMD

#53

Post by measurablefunc » Thu, Nov 20, 2025, 3:44 AM UTC

colonCapitalDee wrote: post #49

measurablefunc wrote: post #42

Earlier quoted context omitted.

[flagged]

Well that's your problem. Here's a tip: just because someone says something doesn't mean you have to listen to them

[flagged]

Re: Why CUDA translation wont unlock AMD

#54

Post by bigyabai » Thu, Nov 20, 2025, 3:46 AM UTC

measurablefunc wrote: post #42

colonCapitalDee wrote: post #41

Earlier quoted context omitted.

No. This is far beyond the capabilities of current AI, and will remain so for the foreseeable future. You could let your model of choice churn on this for months, and you will not get anywhere. It will be able to reach a somewhat working solution quickly, but it will soon reach a point where for every issue it fixes, it introduces one or more issues or regressions. LLMs are simply not capable of scaffolding complexit…

[flagged]

This explains everything.

Re: Why CUDA translation wont unlock AMD

#55

Post by bigyabai » Thu, Nov 20, 2025, 3:47 AM UTC

measurablefunc wrote: post #16

Blackthorn wrote: post #15

Earlier quoted context omitted.

I don't know why you're being downvoted because even if you're Not Even Wrong, that's exactly the sort of thing that has been endlessly presented by people trying to sell AI as something that AI will absolutely do for us.

[flagged]

It's hard to catch-on to a deliberately dishonest pretense. You could clone 10,000 John Carmacks to do the job for you, Nvidia would still be a $5 trillion business next time you wake up.

Re: Why CUDA translation wont unlock AMD

#56

Post by apitman » Thu, Nov 20, 2025, 3:48 AM UTC

Our open source library is currently hard locked into CUDA due to nvCOMP for gzip decompression (bioinformatics files). What I wouldn't give for an open source implementation, especially if it targeted WebGPU.

Re: Why CUDA translation wont unlock AMD

#57

Post by [deleted] » Thu, Nov 20, 2025, 4:02 AM UTC

measurablefunc wrote: post #36

bigyabai wrote: post #32

Earlier quoted context omitted.

There is an old programmer's joke about writing abstractions and expecting zero-cost.

How does that apply in this case? The whole point is that the agentic AI/AGI skips all the abstractions & writes optimized low-level code for each GPU vendor from a high-level specification. There are no abstractions other than whatever specifications GPU vendors provide for their hardware which are fed into the agentic AI/AGI to do the necessary work of creating low-level & optimized code for specific tasks.

[deleted]

Re: Why CUDA translation wont unlock AMD

#58

Post by latchkey » Thu, Nov 20, 2025, 4:06 AM UTC

mandevil wrote: post #18

Yeah, ROCm focused code will always beat generic code compiled down. But this is a really difficult game to win. For example, Deepseek R-1 released optimized for running on Nvidia HW, and needed some adaption to run as well on ROCm. This was for the exact same reasons that ROCm code will beat generic code compiled into ROCm, in the same way. Basically the Deepseek team, for their own purposes, created R-1 to fit Nvid…

Kimi is the latest model that isn't running correctly on AMD. Apparently close to Deepseek in design, but different enough that it just doesn't work.

It isn't just the model, it is the engine to run it. From what I understand this model works with sglang, but not with vLLM.

Re: Why CUDA translation wont unlock AMD

#59

Post by latchkey » Thu, Nov 20, 2025, 4:27 AM UTC

A bit of background. This is directed towards Spectral Compute (Michael) and https://scale-lang.com/. I know both of these guys personally and consider them both good friends, so you have to understand a bit of the background in order to really dive into this.

My take on it is fairly well summed up at the bottom of Elio's post. In essence, Elio is taking the view of "we would never use scale-lang for llms because we have a product that is native AMD" and Michael is taking the view of "there is a ton of CUDA code out there that isn't just AI and we can help move those people over to AMD... oh and by the way, we actually do know what we are doing, and we think we have a good chance at making this perform."

At the end of the day, both companies (my friends) are trying to make AMD a viable solution in a world dominated by an ever growing monopoly. Stepping back a bit and looking at the larger picture, I feel this is fantastic and want to support both of them in their efforts.

Re: Why CUDA translation wont unlock AMD

#60

Post by measurablefunc » Thu, Nov 20, 2025, 5:02 AM UTC

bigyabai wrote: post #55

measurablefunc wrote: post #16

Earlier quoted context omitted.

[flagged]

It's hard to catch-on to a deliberately dishonest pretense. You could clone 10,000 John Carmacks to do the job for you, Nvidia would still be a $5 trillion business next time you wake up.

[flagged]