Live data from Hacker News

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

phoronix.com

331–340 of 425 posts

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

#331

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…

Never underestimate AMD's ability to fail.

Ryzen was a surprise to everyone not because it was good, but because they didn't fuck it up within two generations.

AMD cards have more raw compute than nvidia, they are better than nvidia, yet the software is so bad that I gave up on using it and switched to nvidia. Two weeks of debugging driver errors vs 30 minutes of automated updates.

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

#332

Earlier quoted context omitted.

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.

Are they ported though? I would say thanks to the Steam Deck, Proton is at a point where native Linux ports are unnecessary. It's also a much more stable target to develop against than N+1 Linux distros.

Many are specifically ported to work with Linux without a wrapper, especially among indie games and games from smaller studios.

Unity, Unreal and Godot all support compiling for Linux either by default or with inexpensive or possibly free add-ons. I'm sure many other game engines do as well, and when you're taking a few hours of work at most to add everyone who owns a steam deck or a steam deck clone as a potential customer to your customer base then that is not a tall order.

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

#333

Earlier quoted context omitted.

The only reason our lab bought 20k worth of Nvidia gpu cards rather than amd was the cuda industry standard (might as wellbe). It's kind of mind boggling how much business amd must be losing over this.

So, your lab bought ~1 GPU?

Hey stop shaming the GPU poor, not everyone is Mark Zuckerberg ordering $8bn. of GPUs.

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

#334

Earlier quoted context omitted.

From the Phoronix comments section of the Article that I linked to: https://www.phoronix.com/forums/forum/linux-graphics-x-org-d... And I'm on Linux Mint 21.3 and so how to change any instillation script to think that Mint is Ubuntu to get that to maybe work there but there's no how-to for Mint like the one that AMD provides for Ubuntu! And really that's compiled By AMD for the specific Linux Kernel so not any DKMS s…

If you wait for a while then Debian packaging effort will flow down through the repos and you'll have apt install or synaptic GUI access to the prebuilt binaries. You've already got an amdgpu driver in your kernel. Possibly an old one but it'll be there. ROCm is userspace.

I'm waiting for Rusticl(OpenCL Implemented in the Rust programming language) as part of the MESA driver stack to get enabled in Mint 22(Sometime in April 2024). And maybe I can use the Older Legacy Blender 2.93/earlier editions that use OpenCl as the GPU compute API instead of Blender 3.0/later editions that have dropped support for OpenCL in favor of CUDA/PTX(Whatever) that requires the HIP part of ROCm to get translated to a form that can be executed on Radeon GPU hardware.

CUDA PTX is that Intermediate Language representation that's portable for cross platform usage but I'm not exactly sure how that is implemented for Blender 3.0/later.

P.S I have Ryzen 3000/Zen+ series APUs and Vega Integrated Graphics on 2 systems and the laptop has Ryzen 3550H/Vega 8CU iGPU and Polaris Radeon RX560X dGPU while the Mini Desktop PC has Ryzen 3400G/Vega 11CU iGPU only.

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

#335

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…

Hey there - I'm a maintainer (and CEO) of Invoke. It's something we're monitoring as well. ROCm has been challenging to work with - we're actively talking to AMD to keep apprised of ways we can mitigate some of the more troublesome experiences that users have with getting Invoke running on AMD (and hoping to expand official support to Windows AMD) The problem is that a lot of the solutions proposed involve significan…

Hi! I really appreciate you taking the time to reply.

I have since gotten Invoke to run and was already able to get some results I'm really quite happy with, so thank you for your time and commitment working on Invoke!

I understand that ROCm is still challenging, but it seems my problems were less related to ROCm or Invoke itself and more to Python dependency management. It really boiled down to getting the correct (ROCm) versions of packages installed. Installing Invoke from PyPi always removed my Torch and installed CUDA-enabled Torch (as well as cuBLAS, cuDNN, ...). Once I had the correct versions of packages, everything just worked.

To me, your pyproject.toml looks perfectly sane, so I wasn't sure how to go about fixing the problem.

What ended up working for me was to use one of AMD's ROCm OCI base images, manually installing all dependencies, foregoing a virtual environment, cloning your repo (, building the frontend), and then installing from there.

The majority of my struggle would have been solved by a recent working Docker image containing a working setup. (The one on Docker Hub is 9 months old.) Trying to build the Dockerfile from your repo, I also ended up with a CUDA-enabled Torch. It did install the correct one first, but in a later step removed the ROCm-enabled Torch to switch it for the CUDA-enabled one.

I hope you'll consider investing some resources into publishing newer, working builds of your Docker image.

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

#337

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'm really rooting for AMD to break the CUDA monopoly Personally I want Nvidia to break the x86-64 monopoly, with how amazing properly spec'd Nvidia cards are to work with I can only dream of a world where Nvidia is my CPU too.

How would this a good idea? I am not very familiar with GPU programming but the small amount I've tried was nothing but pain a few years ago on linux, it was so bad that Torvald publicly used the f word in a very public event. That aside, CUDA seem like a great way to lock people in even further like AWS does with absolutely everything

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

#338

ROCm is not spelled out anywhere in their documentation and the best answers in search come from Github and not AMD official documents "Radeon Open Compute Platform" https://github.com/ROCm/ROCm/issues/1628 And they wonder why they are losing. Branding absolutely matters.

Lisa Su in a later presentation/event announced that ROCM is no longer an acronym! So Radeon Open CoMpute is no longer the definition there! But ROCm/HIP and CUDA/CUDA Tools, and OneAPI/Level-0 are essentially the same coverage/scope for AMD, Nvidia, Intel respectively as far as GPU Compute API support goes and HPC/Accelerator workloads as well.

So there's a YouTube Video from some Supercomputer conference where the presenter goes over the support Matrix info for ROCm/HIP, CUDA/CUDA Tools, and OneAPI/Level-0 and they are similar in scope there.

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

#339

As I understand, Vulkan allows to run custom code on GPU, including the code to multiply matrices. Can one simply use Vulkan and ignore CUDA, PyTorch and ROCm?

I did a few times with Direct3D 11 compute shaders. Here’s an open-source example: https://github.com/Const-me/Cgml

Pretty sure Vulkan gonna work equally well, at the very least there’s an open source DXVK project which implements D3D11 on top of Vulkan.

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

#340

Earlier quoted context omitted.

They are focusing on HPC first. Which seems reasonable if your software stack is lacking. Look for sophisticated customers that can help build an ecosystem. As I mentioned elsewhere, 25% of GPU compute on the Top 500 Supercomputer list is AMD. This all on the back of a card that came out only three years ago. We are very rapidly moving towards a situation where there are many, many high-performance developers that wi…

Is a top 500 super computer list a good way of measuring relevancy in the future?

Yes it is, it's how cuda got it's dominance 10 years ago. Businesses don't release their source code, super computers are attached to labs and universities and have much better licenses for software, or publish papers about it.
Post reply on HN