Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

phoronix.com

Post reply on HN
Print view View original

261–270 of 425 posts

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

#261

Post by smcl »

leeoniya wrote: post #179
enonimal wrote: post #91

From the ARCHITECTURE.md: > Those pointers point to undocumented functions forming CUDA Dark API. It's impossible to tell how many of them exist, but debugging experience suggests there are tens of function pointers across tens of tables. A typical application will use one or two most common. Due to they undocumented nature they are exclusively used by Runtime API and NVIDIA libraries (and in by CUDA applications in…

fertile soil for Alyssa and Asahi Lina :) https://rosenzweig.io/ https://vt.social/@lina

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.

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

#262

Post by beebeepka »

pjmlp wrote: post #255
alberth wrote: post #102

Earlier quoted context omitted.

DirectX vs OpenGL. This brings back memories of late 90s / early 00s of Microsoft pushing hard their proprietary graphic libraries (DirectX) vs open standards (OpenGL). Fast forward 25-years and even today, Microsoft still dominates in PC gaming as a result. There's a bad track record of open standard for GPUs. Even Apple themselves gave up on OpenGL and has their own proprietary offering (Metal).

Also to note, dispite urban myths, OpenGL never mattered on game consoles, which people keep forgeting about when praising OpenGL "portability". Then there is the whole issue of extension spaghetti, and incompatibilities across OpenGL, OpenGL ES and WebGL, hardly possible to have portable code 1:1 everywhere, beyond toy examples.

I guess every recent not-xbox never mattered.

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

#263

Post by PoignardAzur »

enonimal wrote: post #91

From the ARCHITECTURE.md: > Those pointers point to undocumented functions forming CUDA Dark API. It's impossible to tell how many of them exist, but debugging experience suggests there are tens of function pointers across tens of tables. A typical application will use one or two most common. Due to they undocumented nature they are exclusively used by Runtime API and NVIDIA libraries (and in by CUDA applications in…

Having an ARCHITECTURE.md file at all is extremely promising, but theirs seems pretty polished too!

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

#264

Post by latchkey »

beebeepka wrote: post #250
latchkey wrote: post #205

Earlier quoted context omitted.

I'm building a bare metal business around MI300x and top end Epyc CPUs. We will have them for rental soon. The goal is to build a public super computer that isn't just available to researchers in HPC.

Is it true MI300 line is 3-4x cheaper for similar performance than whatever nvidia is selling in highest segment?

I probably can't comment on that, but what I can comment on is this:

H100's are hard to get. Nearly impossible. CoreWeave and others have scooped them all up for the foreseeable future. So, if you are looking at only price as the factor, then it becomes somewhat irrelevant, if you can't even buy them [0]. I don't really understand the focus on price because of this fact.

Even if you do manage to score yourself some H100's. You also need to factor in the networking between nodes. IB (Infiniband) made by Mellanox, is owned by NVIDIA. Lead times on that equipment are 50+ weeks. Again, price becomes irrelevant if you can't even network your boxes together.

As someone building a business around MI300x (and future products), I don't care that much about price [!]. We know going in that this is a super capital intensive business and have secured the backing to support that. It is one of those things where "if you have to ask, you can't afford it."

We buy cards by the chassis, it is one price. I actually don't know the exact prices of the cards (but I can infer it). It is a lot about who you know and what you're doing. You buy more chassis, you get better pricing. Azure is probably paying half of what I'm paying [1]. But I'd also say that from what I've seen so far, their chassis aren't nearly as nice as mine. I have dual 9754's, 2x bonded 400G, 3TB ram, and 122TB nvme... plus the 8x MI300x. These are top of the top. They have Intel and I don't know what else inside.

[!] Before you harp on me, of course I care about price... but at the end of the day, it isn't what I'm focused on today as much as just being focused on investing all of the capex/opex that I can get my hands on, into building a sustainable business that provides as much value as possible to our customers.

[0] https://www.tomshardware.com/news/tsmc-shortage-of-nvidias-a...

[1] https://www.techradar.com/pro/instincts-are-massively-cheape...

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

#265

Post by modeless »

paulmd wrote: post #201
modeless wrote: post #181

Earlier quoted context omitted.

PTX is not a hardware ISA though, it's still software and can change more rapidly.

Not without breaking the support contract? If you change PTX format then CUDA 1.0 machines can no longer it and it's no longer PTX. Again, you are missing the point. Java is both a language (java source) and a machine (the JVM). The latter is a hardware ISA - there are processors that implement Java bytecode as their ISA format. Yet most people who are running Java are not doing so on java-machine hardware, yet they…

You are missing the point. PTX is not designed as a vendor neutral abstraction like JVM/CLR bytecode. Furthermore CUDA is a lot more than PTX. There's a whole API there, plus applications ship machine code and rely on Nvidia libraries which can be prohibited from running on AMD by license and with DRM, so those large libraries would also become part of the API boundary that AMD would have to reimplement and support.

Chasing CUDA compatibility is a fool's errand when the most important users of CUDA are open source. Just add explicit AMD support upstream and skip the never ending compatibility treadmill, and get better performance too. And once support is established and well used the community will pitch in to maintain it.

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

#266

Post by rvba »

michalf6 wrote: post #58

Złuda roughly means "delusion" / "mirage" / "illusion" in Polish, given the author is called Andrzej Janik this may be a pun :)

Arguably one could also translate it as "something that will never happen".

At the same time "cuda" could be translated as "wonders".

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

#267

Post by BizarroLand »

pjmlp wrote: post #253
BizarroLand wrote: post #184

Earlier quoted context omitted.

Todays linux OS's would have competed incredibly strongly against Vista and probably would have gone blow for blow against 7. Proton, Wine, and all of the compatibility fixes and drive improvements that the community has made in the last 16 years has been amazing, and every day is another day where you can say that it has never been easier to switch away from Windows. However, Microsoft has definitely been drinking t…

There is no competition when games only come to Linux by "emulating" Windows. The only thing it has going for it is being a free beer UNIX clone for headless environments, and even then, isn't that relevant on cloud environments where containers and managed languages abstract everything they run on.

Thanks to the Steam Deck, more and more games are being ported for Linux compatibility by default.

Maybe some Microsoft owned games makers will never make the shift, but if the majority of others do then that's the death knell.

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

#268

Post by nikanj »

Keyframe wrote: post #173

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…

This should be the top comment here, people are getting their hopes up for nothing

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

#269

Post by westurner »

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…

> 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=38588573

What can't WebGPU abstract away from CUDA unportability? https://news.ycombinator.com/item?id=38527552

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

#270

Post by Cu3PO42 »

bntyhntr wrote: post #228
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…

I would love to be able to have a native stable diffusion experience, my rx 580 takes 30s to generate a single image. But it does work after following https://github.com/AUTOMATIC1111/stable-diffusion-webui/wiki... I got this up and running on my windows machine in short order and I don't even know what stable diffusion is. But again, it would be nice to have first class support to locally participate in the fun.

I have heard that DirectML was a somewhat easier story, but allegedly has worse performance (and obviously it's Windows only...). But I'm not entirely suprised that setup is somewhat easier on Windows, where bundling everything is an accepted approach.

With AMD's official 15GB(!) Docker image, I was now able to get the A1111 UI running. With SD 1.5 and 30 sample iterations, generating an image takes under 2s. I'm still struggling to get InvokeAI running.

Post reply on HN