8 ms·

Taking on CUDA with ROCm: 'One Step After Another'

264 points by mindcrime 6mo ago

blovescoffee 6mo ago
Naive question, could agents help speed up building code for ROCm parity with CUDA? Outside of code, what are the bottlenecks for reaching parity?
- jiggawatts 6mo ago
  Lack of focus from AMD management. See the sibling comment: https://news.ycombinator.com/item?id=47745611 https://news.ycombinator.com/item?id=47745611 They just don't care enough to compete.
- WorldPeas 6mo ago
  to be honest, outside of fullstack and basic MCU stuff, these agents aren't very good. Whenever a sufficiently interesting new model comes out I test it on a couple problems for android app development and OS porting for novel cpu targets and we still haven't gotten there yet. I'd be happy to see a day where it was possible however
  - catgary 6mo ago
    I’ve found they’re quite good when you’re higher in the compiler stack, where it’s essentially a game of translating MLIR dialects.
    - WorldPeas 6mo ago
      it'd be nice if one of these environment labs made an environment for cross-architecture porting, it'd be really cool to see some old ppc mac programs running natively, or compiled to wasm (yes, yes I know the visual elements would need to be ported as well)
- hypercube33 6mo ago
  Maybe this is dumb but at the moment through windows (and WSL?) you get: rocm DirectML Vulkan OpenML?
- m-schuetz 6mo ago
  Agents work great for tasks that thousands of developers have done before. This isn't one of those tasks.
  - WithinReason 6mo ago
    Unless you train them with RL in the right task specifically
superkuh 6mo ago
AMD hasn't signaled in behavior or words that they're going to actually support ROCm on $specificdevice for more than 4-5 years after release. Sometimes it's as little as the high 3.x years for shrinks like the consumer AMD RX 580. And often the ROCm support for consumer devices isn't out until a year after release, further cutting into that window. Meanwhile nvidia just dropped CUDA/driver support for 1xxx series cards from their most recent drivers this year. For me ROCm's mayfly lifetime is a dealbreaker.
- canpan 6mo ago
  I was thinking to get 2x r9700 for a home workstation (mostly inference). It is much cheaper than a similar nvidia build. But still not sure if good value or more trouble.
  - chao- 6mo ago
    Talking to friends who have fought more homelab battles than I ever will, my sense is that (1) AMD has done a better job with RDNA4 than the past generations, and (2) it seems very workload-dependent whether AMD consumer gear is "good value", "more trouble", or both at the same time. Edit: I misread the "2x r9700" as "2 rx9700" which differs from the topic of this comment (about RNDA4 consumer SKUs). I'll keep my comment up, but anyone looking to get Radeon PRO cards can (should?) disregard.
    - KennyBlanken 6mo ago
      Given RDNA3 was a pathetic joke, it wouldn't be hard for them to do a better job.
  - cyberax 6mo ago
    I have this setup, with 2x 32Gb cards. It's perfect for my needs, and cheaper than anything comparable from NV.
  - stephlow 6mo ago
    I own a single R9700 for the same reason you mentioned, looking into getting a second one. Was a lot of fiddling to get working on arch but RDNA4 and ROCm have come a long way. Every once in a while arch package updates break things but that’s not exclusive to ROCm. LLM’s run great on it, it’s happily running gemma4 31b at the moment and I’m quite impressed. For the amount of VRAM you get it’s hard to beat, apart from the Intel cards maybe. But the driver support doesn’t seem to be that great there either. Had some trouble with running comfyui, but it’s not my main use case, so I did not spent a lot of time figuring that out yet
shmerl 6mo ago
Side question, but why not advance something like Rust GPU instead as a general approach to GPU programming? https://github.com/Rust-GPU/rust-gpu/ https://github.com/Rust-GPU/rust-gpu/ From all the existing examples, it really looks the most interesting. I.e. what I'm surprised about is lack of backing for it from someone like AMD. It doesn't have to immediately replace ROCm, but AMD would benefit from it advancing and replacing the likes of CUDA.
- MobiusHorizons 6mo ago
  From the readme: > Note: This project is still heavily in development and is at an early stage. > Compiling and running simple shaders works, and a significant portion of the core library also compiles. > However, many things aren't implemented yet. That means that while being technically usable, this project is not yet production-ready. Also projects like rust gpu are built on top of projects like cuda and ROCm they aren’t alternatives they are abstractions overtop
  - shmerl 6mo ago
    I think Rust GPU is built on top of Vulkan + SPIR-V as their main foundation, not on top of CUDA or ROCm. What I meant more is the language of writing GPU programs themselves, not necessarily the machinery right below it. Vulkan is good to advance for that. I.e. CUDA and ROCm focus on C++ dialect as GPU language. Rust GPU does that with Rust and also relies on Vulkan without tying it to any specific GPU type.
    - markisus 6mo ago
      The article mentions Triton for this purpose. I don’t think you will get maxed out performance on the hardware though because abstraction layers won’t let you access the fastest possible path.
      - shmerl 6mo ago
        > I don’t think you will get maxed out performance on the hardware though because abstraction layers won’t let you access the fastest possible path. You could argue about CPU architectures the same, no? Yet compilers solve this pretty well most of the time.
lrvick 6mo ago
Just spent the last week or so porting TheRock to stagex in an effort to get ROCm built with a native musl/mimalloc toolchain and get it deterministic for high security/privacy workloads that cannot trust binaries only built with a single compiler. It has been a bit of a nightmare and had to package like 30+ deps and their heavily customized LLVM, but got the runtime to build this morning finally. Things are looking bright for high security workloads on AMD hardware due to them working fully in the open however much of a mess it may be.
- jauntywundrkind 6mo ago
  https://github.com/ROCm/TheRock/issues/3477 https://github.com/ROCm/TheRock/issues/3477 makes me quite sad for a variety of reasons. It shouldn't be like this. This work should be usable.
  - deleted 6mo ago
    [deleted]
  - lrvick 6mo ago
    Oh I fully abandoned TheRock in my stagex ROCm build stack. It is not worth salvaging, but it was an incredibly useful reference for me to rewrite it.
  - hackernows_test 6mo ago
    [flagged]
  - MrDrMcCoy 6mo ago
    So much about this confuses me. What do Kitty and ncurses have to do with ROCm? Why is this being built with GCC instead of clang? Why even bother building it yourself when the tarballs are so good and easy to work with?
    - CamouflagedKiwi 6mo ago
      On the last one: OP said they were trying to get it working for a musl toolchain, so the tarballs are probably not useful to them (I assume they're built for glibc). Agreed on the others though. Why's it even installing ncurses, surely that's just expected to be on the system?
alecco 6mo ago
Apple got it right with unified memory with wide bus. That's why Mac Minis are flying for local models. But they are 10x less powerful in AI TOPS. And you can't upgrade the memory. I really wish AMD and Intel boards get replaced by competent people. They could do it in very short time. Both have integrated GPUs with main memory. AMD and Intel have (or at least used to have) serious know-how in data buses and interconnects, respectively. But I don't see any of that happening. ROCm? It can't even support decent Attention. It lacks a lot of features and NVIDIA is adding more each year. Soon they will reach escape velocity and nobody will catch them for a decade. smh
- caycep 6mo ago
  Granted, I feel like NVIDIA GPU pricing is such that Mac minis will be way less than 10x cheaper if not already, so one might still get ahead purchasing a bulk order of Mac minis....
  - KennyBlanken 6mo ago
    A 5090 will cost you about the same amount of money as a Mac Studio M3 Ultra with eight times the RAM. It's pretty insane how overpriced NVIDIA hardware is.
    - corndoge 6mo ago
      But the 5090 can run Crysis
    - LoganDark 6mo ago
      Yes but the 5090 can run games. Running games on my loaded M4 Max is worse than on my 3090 despite the over-four-year generational gap. Like, Pacific Drive will reach maybe 30fps at less than 1080p whereas the 3090 will run it better even in 4K. That could just be CrossOver's issue with Unreal Engine games, but "just play different games" is not a solution I like.
    - kimixa 6mo ago
      The 256GB Mac Studio (the one with "eight times the RAM") is listed for ~$2000 more than the current 5090 prices, and another additional $1500 for the 80-core GPU variant. Only the "base" model with 96gb is a remotely similar price, $3600-$4000. And a 5090 has a little over 2x the memory bandwidth - ~820GB/s vs ~1790GB/s. And significantly higher peak FLOPS on the 5090 too. Sure, if the goal is to get the "Cheapest single-device system with 256GB ram" it looks pretty good, but there's lots of other axes it falls down on. Great if you know you don't care about them, but not "Better In Every Way". Arguably, better in only a single way - but that single way may well be the one you need. And the current 5090 price might be a transient peak - only three months ago they were closer to $2500 - significantly less than half the $6000 base-spec 256GB Mac Studio. While the Mac Studio has been constant.
deleted 6mo ago
[deleted]
p1esk 6mo ago
Someone from AMD posted this a few minutes ago, then deleted it: "Anush's success is due to opting out of internal bureaucracy than anything else. most Claude use at AMD goes through internal infrastructure that can take hundreds of seconds per response due to throttling. Anush got us an exemption to use Anthropic directly. he is also exempt from normal policies on open source and so I can directly contribute to projects to add AMD support. He's an effective leader and has turned ROCm into a internal startup based in California. Definitely worth joining the team even if you've heard bad things about AMD as a whole." This kind of bullshit is why I don't want to join AMD, even if this particular team is temporarily exempt from it.
- brcmthrowaway 6mo ago
  So join NVIDIA instead
- nl 6mo ago
  > he is also exempt from normal policies on open source and so I can directly contribute to projects to add AMD support. It's crazy that this is a big deal. I understand the need for some kind of governance around this but for it to require a special exemption just shows how far the AMD culture needs to shift.
  - 0xbadcafebee 6mo ago
    Liability is always a big deal.
    - nl 6mo ago
      Sure, but it's not like other large companies don't have policies that address this.
- noident 6mo ago
  Policies like these are widespread in most companies with >1000 employees
  - 6mo ago
hurricanepootis 6mo ago
I've been using ROCm on my Radeon RX 6800 and my Ryzen AI 7 350 systems. I've only used it for GPU-accelerated rendering in Cycles, but I am glad that AMD has an option that isn't OpenCL now.
roenxi 6mo ago
> Challenger AMD’s ability to take data center GPU share from market leader Nvidia will certainly depend on the success or failure of its AI software stack, ROCm. I don't think this is true. ROCm is a huge advantage for Nvidia but as far as I can tell it is more a set of R&D libraries than anything else, so all the Hot New Stuff keeps being Nvidia first and only (to start with) as the library ecosystem for the hotness doesn't exist yet. Then eventually new libraries are created that are CUDA independent and AMD turns out to make pretty good graphics cards. I wouldn't be surprised of ROCm withered on the vine and AMD still does fine.
ycui1986 6mo ago
For many LLM load, it seems ROCm is slower than vulkan. What’s the point?
- mmis1000 6mo ago
  Compatibility so foundation packages like torch onnx-runtime can run on AMD GPU without massive change in architecture. It's the biggest reason for those stuff that "only works on nvidia gpu". It's not faster if vulkan alternative exists, but at least it runs.
rdevilla 6mo ago
ROCm is not supported on some very common consumer GPUs, e.g. the RX 580. Vulkan backends work just fine.
- hurricanepootis 6mo ago
  RX 580 is a GCN 4 GPU. I'm pretty sure the bare minimum for ROCm is GCN 5 (Vega) and up.
  - daemonologist 6mo ago
    Among consumer cards, latest ROCm supports only RDNA 3 and RDNA 4 (RX 7000 and RX 9000 series). Most stuff will run on a slightly older version for now, so you can get away with RDNA 2 (6000 series).
    - hurricanepootis 6mo ago
      Huh, I just saw that. Huge bummer. I have a Radeon RX 6800 and on my system, I use ROCm's OpenCL for some stuff and HIP for blender cycles rendering. If ROCm were to drop support for my card, that'd be a huge bummer.
- BobbyTables2 6mo ago
  Did it used to be different? A few years ago I thought I had used the ROCm drivers/libraries with hashcat on a RX580 Now it’s obsolete ?
- maxloh 6mo ago
  I have the same experience with my RX 5700. The supported ROCm version is too old to get Ollama running. Vulkan backend of Ollama works fine for me, but it took one year or two for them to officially support it.
- chao- 6mo ago
  I purchased my RX 580 in early 2018 and used it through late 2024. I am critical of AMD for not fully supporting all GPUs based on RNDA1 and RDNA2. While backwards compatibility is always better than less for the consumer, the RX 580 was a lightly-updated RX 480, which came out in 2016. Yes, ROCm technically came out in 2016 as well, but I don't mind acknowledging that it is a different beast to support the GCN architecture than the RDNA/CDNA generations that followed (Vega feels like it is off on an island of its own, and I don't even know what to say about it). As cool as it would be to repurpose my RX 580, I am not at all surprised that GCN GPUs are not supported for new library versions in 2026. I would be MUCH more annoyed if I had any RDNA1 GPU, or one of the poorly-supported RDNA2 GPUs.
bruce343434 6mo ago
In my experience fiddling with compute shaders a long time ago, cuda and rocm and opencv are way too much hassle to set up. Usually it takes a few hours to get the toolkits and SDK up and running that is, if you CAN get it up and running. The dependencies are way too big as well, cuda is 11gb??? Either way, just use Vulkan. Vulkan "just works" and doesn't lock you into Nvidia/amd.
- cmovq 6mo ago
  Vulkan is a pain for different reasons. Easier to install sure, but you need a few hundred lines of code to set up shader compilation and resources, and you’ll need extensions to deal with GPU addresses like you can with CUDA.
  - rdevilla 6mo ago
    Ah yes, but those hundred lines of code are basically free to produce now with LLMs...
    - cylemons 6mo ago
      Whatabout the extensions? is it widely supported
      - NekkoDroid 6mo ago
        That is always one check away: https://vulkan.gpuinfo.org/listextensions.php https://vulkan.gpuinfo.org/listextensions.php
        cylemons 6mo ago
        VK_KHR_buffer_device_address has 91.3% support and VK_KHR_variable_pointers has 98.66% support looks good to me
- Arech 6mo ago
  Haha. People have already said what is Vulkan in practice - it's very convoluted low-level API, in which you have to write pretty complicated 200+LoC just to have simplest stuff running. Also doing compute on NVIDIA in Vulkan is fun if you believe the specs word for word. If you don't, you switch a purely compute pipeline into a graphical mode with a window and a swapchain, and instantly get roughly +20% of performance out of that. I don't know if this was a bug or an intended behavior (to protect CUDA), but this how it was a couple years ago.
0xbadcafebee 6mo ago
AMD has years of catching up to do with ROCm just to get their devices to work well. They don't support all their own graphics cards that can do AI, and when it is supported, it's buggy. The AMDGPU graphics driver for Linux has had continued instability since 6.6. I don't understand why they can't hire better software engineers.
- onlyrealcuzzo 6mo ago
  Because they aren't willing to pay for them?
- oofbey 6mo ago
  Years. They neglected ROCm for soooo long. I have friends who worked there 5+ years ago who tried desperately to convince execs to invest more in ROCm and failed. You had to have your head stuck pretty deep in the sand back then to not see that AI was becoming an important workload. I would love AMD to be competitive. The entire industry would be better off if NVIDIA was less dominant. But AMD did this to themselves. One hundred percent.
  - tux1968 6mo ago
    It would be very helpful to deeply understand the truth behind this management failing. The actual players involved, and their thinking. Was it truly a blind spot? Or was it mistaken priorities? I mean, this situation has been so obvious and tragic, that I can't help feeling like there is some unknown story-behind-the-story. We'll probably never really know, but if we could, I wouldn't spend quite as much time wearing a tinfoil hat.
    - throwawayrgb 6mo ago
      if you asked AMD execs they'd probably say they never had the money to build out a software team like NVIDIA's. that might only be part of the answer. the rest would be things like lack of vision, "can't turn a tanker on a dime", etc.
      - 6mo ago
cameolkc 6mo ago
[dead]
nnevatie 6mo ago
Why is it called "ROCm” (with the strange capitalization) in the first place? This may sound silly, but in order to compete, every detail matters, including the name.
- WanderPanda 6mo ago
  This is so true! Shows a lack of care that usually doesn’t stop at just the naming
- slongfield 6mo ago
  It used to stand for "[R]adeon [O]pen [C]o[m]pute", but since it's not affiliated with the Open Compute Project, they dropped the meaning of it a little while ago, and now it doesn't stand for anything.
- dnautics 6mo ago
  presumably a reference to rocm/socm robots?
jmward01 6mo ago
I really want to get to the point that I am looking online for a GPU and Nvidia isn't the requirement. I think we are really close to there. Maybe we are there and my level of trust just needs to bump up.
- m-schuetz 6mo ago
  Problem is, NVIDIA has so many quality of life features for developers. It's not easy getting especially smaller scale developers and academia to use other vendors that are 1) much more difficult to use while 2) also being slower and not as rich in features. Personally I opted in to being NVIDIA-vendor-locked a couple of years ago because I just couldn't stand the insanely bonkers and pointless complexity of APIs like Vulkan. I used OpenGL before which supported all vendors, but because newer features weren't added to OpenGL I eventually had to make the switch. I tried both Vulkan and CUDA, and after not getting shit done in Vulkan for a week I tried CUDA, and got the same stuff done in less than a day that I could not do in a whole week in Vulkan. At that moment I thought, screw it, I'm going to go NV-only now.
  - pjmlp 6mo ago
    I did my thesis porting my supervisor's project from NeXTSTEP into Windows, was an OpenGL fanboy up to the whole Long Peaks disaster. Additionally Vulkan has proven to be yet another extension mess (to the point now are actions try to steer it back on track), Khronos is like the C++ of API design, while expecting vendors to come up with the tools. However, as great as CUDA, Metal and DirectX are to play around with, we might be stuck with Khronos APIs, if geopolitcs keep going as bad or worse, as they have been thus far.
suprjami 6mo ago
Just in time for Vulkan tg to be faster in almost all situations, and Vulkan pp to be faster in many situations with constant improvements on the way, making ROCm obsolete for inference.
- kimixa 6mo ago
  ROCm vs Vulkan has never been about performance - you should be able to represent the "same" shader code in either, and often they back onto the same compilers and optimizers anyway. If one is faster, that often means something has gone /wrong/. The advantages for ROCm would be integration into existing codebases/engineer skillsets (e.g. porting an existing C++ implementation of something to the GPU with a few attributes and API calls rather than rewriting the core kernel in something like GLSL and all the management vulkan implies).
- m-schuetz 6mo ago
  Vulkan has abysmal UX though. At one point I had to chose between Vulkan and Cuda for future projects, and I ended up with Cuda because a feasibilty study I couldn't get to work in Vulkan for an entire week, easily worked in Cuda in less than a day.
xkbear89 6mo ago
[flagged]
pjmlp 6mo ago
They need lots of steps, hardware support, IDE and graphical debugging integrations , the polyglot ecosystem, having a common bytecode used by several compiler backends (CUDA is not only C++), the libraries portfolio.
emilyhudson 6mo ago
[dead]
taherchhabra 6mo ago
Genuine question. After claude code, codex etc, can't this be speedup ?
- Gasp0de 6mo ago
  I believe this is what that teamlead in the article comments on as next steps?
mstaoru 6mo ago
I'm team "taking on CUDA with OpenVINO" (and SYCL*), Intel seems really upped their game on iGPU and dGPU lately, with sane prices and fairly good software support and APIs. I'm not talking gaming CUDA, but CV and data science workloads seem to scale well on Arc and work well on Edge on Core Ultra 2/3.
formerly_proven 6mo ago
We’ve been talking about this for a good ten years at least and AMD is still essentially in the “concepts of a plan” phase. The AMD GPGPU software org has to be one of the most inconsequential ones at this rate.
- mmis1000 6mo ago
  At least they finally do something this time. Now torch and whatever transformer stuff runs normally on windows/linux as long as you installed correct wheel from amd's own repository. It's a huge step though.
DeathArrow 6mo ago
Do we get better perf or tokens per second with AMD and its software stack than with Nvidia?
- wongarsu 6mo ago
  The metric where AMD usually comes out on top is perf/$. Or with their instinct cards VRAM/$
techpulselab 6mo ago
[dead]
amelius 6mo ago
How long until we can use AI to simply translate all the CUDA stuff to another (more open) platform? I'm getting the feeling we're getting close. AI won't be working in nVidia's advantage this time.
- mugivarra69 6mo ago
  [dead]
neuroelectron 6mo ago
Now that the AI bubble is starting to burst, it's a great time for AMD to reveal their AI ambitions. They've set the tone by hiring low cost, outsourced labor. Of course everybody knows what's really going on here. It's not an open discussion, however.
adev_ 6mo ago
A little feedback to AMD executives about the current status of ROCm here: (1) - Supporting only Server grade hardware and ignoring laptop/consumer grade GPU/APU for ROCm was a terrible strategical mistake. A lot of developers experiments first and foremost on their personal laptop first and scale on expensive, professional grade hardware later. In addition: some developers simply do not have the money to buy server grade hardware. By locking ROCm only to server grade GPUs, you restrict the potential list of contributors to your OSS ROCm ecosystem to few large AI users and few HPC centers... Meaning virtually nobody. A much more sensible strategy would be to provide degraded performance for ROCm on top of consummer GPUs, and this is exactly what Nvidia with CUDA is doing. This is changing but you need to send a clear message there. EVERY new released device should be properly supported by ROCm. - (2) Supporting only the two last generations of architecture is not what customers want to see. https://rocm.docs.amd.com/projects/install-on-linux/en/docs-6.0.2/reference/system-requirements.html#supported-gpus https://rocm.docs.amd.com/projects/install-on-linux/en/docs-... People with existing GPU codebase invests significant amount of effort to support ROCm. Saying them two years later: "Sorry you are out of update now!" when the ecosystem is still unstable is unacceptable. CUDA excels to backward compatibility. The fact you ignore it entirely plays against you. (3) - Focusing exclusively on Triton and making HIP a second class citizen is non-sensical. AI might get all the buzz and the money right now, we go it. It might look sensible on the surface to focus on Python-base, AI focused, tools like Triton and supporting them is definitively necessary. But there is a tremendous amount of code that is relying on C++ and C to run over GPU (HPC, simulation, scientific, imaging, ....) and that will remain there for the multiple decades to come. Ignoring that is loosing, again, custumers to CUDA. It is currently pretty ironic to see such a move like that considering that AMD GPUs currently tend to be highly competitive over FP64, meaning good for these kind of applications. You are throwing away one of your own competitive advantage... (4) - Last but not least: Please focus a bit on the packaging of your software solution. There has been complained on this for the last 5 years and not much changed. Working with distributions packagers and integrating with them does not cost much... This would currently give you a competitive advantage over Nvidia..
- pjmlp 6mo ago
  Additional points, CUDA is polyglot, and some people do care about writing their kernels in something else other than C++, C or Fortran, without going through code generation. NVidia is acknowledging Python adoption, with cuTile and MLIR support for Python, allowing the same flexibility as C++, using Python directly even for kernels. They seem to be supportive of having similar capabilities for Julia as well. The IDE and graphical debuggers integration, the libraries ecosystem, which now are also having Python variants. As someone that only follows GPGPU on the side, due to my interests in graphics programming, it is hard to understand how AMD and Intel keep failing to understand what CUDA, the whole ecosystem, is actually about. Like, just take the schedule of a random GTC conference, how much of it can I reproduce on oneAPI or ROCm as of today.
grokcodec 6mo ago
The day ROCm supports EVERY AMD card on release, just like CUDA does, is the day I will actually believe this marketing hype.They really dropped the ball here, also when they abandoned recently released cards (at the time) like the 400 series. Hopefully management gets their heads out of their butts and invests more in the software stack.
- greenail 6mo ago
  I think GB10 is a bit of a counter point. There are tons of features that are not implemented for GB10 which was released 8/2025 It isn't all roses on the cuda side.
AshamedCaptain 6mo ago
> Last year, AMD ran a GitHub poll for ROCm complaints and received more than 1,000 responses. Many were around supporting older hardware, which is today supported either by AMD or by the community, and one year on, all 1,000 complaints have been addressed, Elangovan said. Must have been by waiting for each of the 1000 complainers to die of old age, because I do not know what old hardware they have added support for.
- throwaway173738 6mo ago
  I guess it counts if you can find the information from one of the many conflicting wikis out there and then figure out how to hack support for your card into the specific version of ROCm.
androiddrew 6mo ago
I have been trying since February to get someone at AMD to shipped tuned Tensile kernels in the rcom-libs for the gfx1201. They are used by Ollama but no one on the Developer Discord knows who is responsible for that. It has been pretty frustrating and it shows that AMD has an organizational problem to overcome in addition to all the things technically that they want rocm to do.
- FuriouslyAdrift 6mo ago
  Have you filed anything at github? https://github.com/zichguan-amd https://github.com/zichguan-amd seems to be one of the main people for that... or https://github.com/harkgill-amd https://github.com/harkgill-amd
  - androiddrew 6mo ago
    I’ll try and get in touch with them. Thank you.
naasking 6mo ago
ROCm is so annoying (buggy, fiddly dependencies, limited hardware support) that TinyGrad built its own compiler and toolchain that targets the hardware directly. And it has broader device support than ROCm, which primarily seems focused on their datacenter GPUs.
- ethan_smith 6mo ago
  The TinyGrad approach of going straight to the hardware is telling. Between that, Vulkan compute getting faster for inference (llama.cpp Vulkan backend is competitive now), and SYCL/oneAPI, it feels like the real threat to CUDA might not be ROCm at all but a fragmented set of alternatives that each bypass AMD's broken software stack entirely.
xyzsparetimexyz 6mo ago
Better title: One Dispatch After Another
nullpoint420 6mo ago
I just don’t understand how they haven’t figured this out yet. I genuinely want to know the corporate structure and politics that have lead to their inability to execute. Is it leadership? Something else?
StillBored 6mo ago
I just wish they would make another pass at cleaning up the stack. It should be easy to `git clone --recurse-submodules rocm` followed by a configure/make that both prints out missing dependencies and configures without them, along with choices for 'build the world' vs just build some lower level opencl/HIP/SPIRV tooling without all the libraries/etc on top in a clear way. Right now the entire source base is literally throw a bunch of crap into the rocm brand and hope it builds together vs some overarching architecture. Presumably the entire spend it also tied to "whatever big Co's evaluation needs this week" when it comes to developing with it.
mellosouls 6mo ago
Related from Jan 2025: ROCm Device Support Wishlist (205 points, 107 comments) https://news.ycombinator.com/item?id=42772170 https://news.ycombinator.com/item?id=42772170

264 points by mindcrime 6mo ago

Naive question, could agents help speed up building code for ROCm parity with CUDA? Outside of code, what are the bottlenecks for reaching parity?

jiggawatts 6mo ago
Lack of focus from AMD management. See the sibling comment: https://news.ycombinator.com/item?id=47745611 https://news.ycombinator.com/item?id=47745611 They just don't care enough to compete.
WorldPeas 6mo ago
to be honest, outside of fullstack and basic MCU stuff, these agents aren't very good. Whenever a sufficiently interesting new model comes out I test it on a couple problems for android app development and OS porting for novel cpu targets and we still haven't gotten there yet. I'd be happy to see a day where it was possible however
- catgary 6mo ago
  I’ve found they’re quite good when you’re higher in the compiler stack, where it’s essentially a game of translating MLIR dialects.
  - WorldPeas 6mo ago
    it'd be nice if one of these environment labs made an environment for cross-architecture porting, it'd be really cool to see some old ppc mac programs running natively, or compiled to wasm (yes, yes I know the visual elements would need to be ported as well)
hypercube33 6mo ago
Maybe this is dumb but at the moment through windows (and WSL?) you get: rocm DirectML Vulkan OpenML?
m-schuetz 6mo ago
Agents work great for tasks that thousands of developers have done before. This isn't one of those tasks.
- WithinReason 6mo ago
  Unless you train them with RL in the right task specifically

superkuh 6mo ago

AMD hasn't signaled in behavior or words that they're going to actually support ROCm on $specificdevice for more than 4-5 years after release. Sometimes it's as little as the high 3.x years for shrinks like the consumer AMD RX 580. And often the ROCm support for consumer devices isn't out until a year after release, further cutting into that window. Meanwhile nvidia just dropped CUDA/driver support for 1xxx series cards from their most recent drivers this year. For me ROCm's mayfly lifetime is a dealbreaker.

canpan 6mo ago
I was thinking to get 2x r9700 for a home workstation (mostly inference). It is much cheaper than a similar nvidia build. But still not sure if good value or more trouble.
- chao- 6mo ago
  Talking to friends who have fought more homelab battles than I ever will, my sense is that (1) AMD has done a better job with RDNA4 than the past generations, and (2) it seems very workload-dependent whether AMD consumer gear is "good value", "more trouble", or both at the same time. Edit: I misread the "2x r9700" as "2 rx9700" which differs from the topic of this comment (about RNDA4 consumer SKUs). I'll keep my comment up, but anyone looking to get Radeon PRO cards can (should?) disregard.
  - KennyBlanken 6mo ago
    Given RDNA3 was a pathetic joke, it wouldn't be hard for them to do a better job.
- cyberax 6mo ago
  I have this setup, with 2x 32Gb cards. It's perfect for my needs, and cheaper than anything comparable from NV.
- stephlow 6mo ago
  I own a single R9700 for the same reason you mentioned, looking into getting a second one. Was a lot of fiddling to get working on arch but RDNA4 and ROCm have come a long way. Every once in a while arch package updates break things but that’s not exclusive to ROCm. LLM’s run great on it, it’s happily running gemma4 31b at the moment and I’m quite impressed. For the amount of VRAM you get it’s hard to beat, apart from the Intel cards maybe. But the driver support doesn’t seem to be that great there either. Had some trouble with running comfyui, but it’s not my main use case, so I did not spent a lot of time figuring that out yet

shmerl 6mo ago

Side question, but why not advance something like Rust GPU instead as a general approach to GPU programming? https://github.com/Rust-GPU/rust-gpu/ https://github.com/Rust-GPU/rust-gpu/ From all the existing examples, it really looks the most interesting. I.e. what I'm surprised about is lack of backing for it from someone like AMD. It doesn't have to immediately replace ROCm, but AMD would benefit from it advancing and replacing the likes of CUDA.

MobiusHorizons 6mo ago
From the readme: > Note: This project is still heavily in development and is at an early stage. > Compiling and running simple shaders works, and a significant portion of the core library also compiles. > However, many things aren't implemented yet. That means that while being technically usable, this project is not yet production-ready. Also projects like rust gpu are built on top of projects like cuda and ROCm they aren’t alternatives they are abstractions overtop
- shmerl 6mo ago
  I think Rust GPU is built on top of Vulkan + SPIR-V as their main foundation, not on top of CUDA or ROCm. What I meant more is the language of writing GPU programs themselves, not necessarily the machinery right below it. Vulkan is good to advance for that. I.e. CUDA and ROCm focus on C++ dialect as GPU language. Rust GPU does that with Rust and also relies on Vulkan without tying it to any specific GPU type.
  - markisus 6mo ago
    The article mentions Triton for this purpose. I don’t think you will get maxed out performance on the hardware though because abstraction layers won’t let you access the fastest possible path.
    - shmerl 6mo ago
      > I don’t think you will get maxed out performance on the hardware though because abstraction layers won’t let you access the fastest possible path. You could argue about CPU architectures the same, no? Yet compilers solve this pretty well most of the time.

lrvick 6mo ago

Just spent the last week or so porting TheRock to stagex in an effort to get ROCm built with a native musl/mimalloc toolchain and get it deterministic for high security/privacy workloads that cannot trust binaries only built with a single compiler. It has been a bit of a nightmare and had to package like 30+ deps and their heavily customized LLVM, but got the runtime to build this morning finally. Things are looking bright for high security workloads on AMD hardware due to them working fully in the open however much of a mess it may be.

jauntywundrkind 6mo ago
https://github.com/ROCm/TheRock/issues/3477 https://github.com/ROCm/TheRock/issues/3477 makes me quite sad for a variety of reasons. It shouldn't be like this. This work should be usable.
- deleted 6mo ago
  [deleted]
- lrvick 6mo ago
  Oh I fully abandoned TheRock in my stagex ROCm build stack. It is not worth salvaging, but it was an incredibly useful reference for me to rewrite it.
- hackernows_test 6mo ago
  [flagged]
- MrDrMcCoy 6mo ago
  So much about this confuses me. What do Kitty and ncurses have to do with ROCm? Why is this being built with GCC instead of clang? Why even bother building it yourself when the tarballs are so good and easy to work with?
  - CamouflagedKiwi 6mo ago
    On the last one: OP said they were trying to get it working for a musl toolchain, so the tarballs are probably not useful to them (I assume they're built for glibc). Agreed on the others though. Why's it even installing ncurses, surely that's just expected to be on the system?

alecco 6mo ago

Apple got it right with unified memory with wide bus. That's why Mac Minis are flying for local models. But they are 10x less powerful in AI TOPS. And you can't upgrade the memory. I really wish AMD and Intel boards get replaced by competent people. They could do it in very short time. Both have integrated GPUs with main memory. AMD and Intel have (or at least used to have) serious know-how in data buses and interconnects, respectively. But I don't see any of that happening. ROCm? It can't even support decent Attention. It lacks a lot of features and NVIDIA is adding more each year. Soon they will reach escape velocity and nobody will catch them for a decade. smh

caycep 6mo ago
Granted, I feel like NVIDIA GPU pricing is such that Mac minis will be way less than 10x cheaper if not already, so one might still get ahead purchasing a bulk order of Mac minis....
- KennyBlanken 6mo ago
  A 5090 will cost you about the same amount of money as a Mac Studio M3 Ultra with eight times the RAM. It's pretty insane how overpriced NVIDIA hardware is.
  - corndoge 6mo ago
    But the 5090 can run Crysis
  - LoganDark 6mo ago
    Yes but the 5090 can run games. Running games on my loaded M4 Max is worse than on my 3090 despite the over-four-year generational gap. Like, Pacific Drive will reach maybe 30fps at less than 1080p whereas the 3090 will run it better even in 4K. That could just be CrossOver's issue with Unreal Engine games, but "just play different games" is not a solution I like.
  - kimixa 6mo ago
    The 256GB Mac Studio (the one with "eight times the RAM") is listed for ~$2000 more than the current 5090 prices, and another additional $1500 for the 80-core GPU variant. Only the "base" model with 96gb is a remotely similar price, $3600-$4000. And a 5090 has a little over 2x the memory bandwidth - ~820GB/s vs ~1790GB/s. And significantly higher peak FLOPS on the 5090 too. Sure, if the goal is to get the "Cheapest single-device system with 256GB ram" it looks pretty good, but there's lots of other axes it falls down on. Great if you know you don't care about them, but not "Better In Every Way". Arguably, better in only a single way - but that single way may well be the one you need. And the current 5090 price might be a transient peak - only three months ago they were closer to $2500 - significantly less than half the $6000 base-spec 256GB Mac Studio. While the Mac Studio has been constant.

deleted 6mo ago

[deleted]

p1esk 6mo ago

Someone from AMD posted this a few minutes ago, then deleted it: "Anush's success is due to opting out of internal bureaucracy than anything else. most Claude use at AMD goes through internal infrastructure that can take hundreds of seconds per response due to throttling. Anush got us an exemption to use Anthropic directly. he is also exempt from normal policies on open source and so I can directly contribute to projects to add AMD support. He's an effective leader and has turned ROCm into a internal startup based in California. Definitely worth joining the team even if you've heard bad things about AMD as a whole." This kind of bullshit is why I don't want to join AMD, even if this particular team is temporarily exempt from it.

brcmthrowaway 6mo ago
So join NVIDIA instead
nl 6mo ago
> he is also exempt from normal policies on open source and so I can directly contribute to projects to add AMD support. It's crazy that this is a big deal. I understand the need for some kind of governance around this but for it to require a special exemption just shows how far the AMD culture needs to shift.
- 0xbadcafebee 6mo ago
  Liability is always a big deal.
  - nl 6mo ago
    Sure, but it's not like other large companies don't have policies that address this.
noident 6mo ago
Policies like these are widespread in most companies with >1000 employees
- 6mo ago

hurricanepootis 6mo ago

I've been using ROCm on my Radeon RX 6800 and my Ryzen AI 7 350 systems. I've only used it for GPU-accelerated rendering in Cycles, but I am glad that AMD has an option that isn't OpenCL now.

roenxi 6mo ago

> Challenger AMD’s ability to take data center GPU share from market leader Nvidia will certainly depend on the success or failure of its AI software stack, ROCm. I don't think this is true. ROCm is a huge advantage for Nvidia but as far as I can tell it is more a set of R&D libraries than anything else, so all the Hot New Stuff keeps being Nvidia first and only (to start with) as the library ecosystem for the hotness doesn't exist yet. Then eventually new libraries are created that are CUDA independent and AMD turns out to make pretty good graphics cards. I wouldn't be surprised of ROCm withered on the vine and AMD still does fine.

ycui1986 6mo ago

For many LLM load, it seems ROCm is slower than vulkan. What’s the point?

mmis1000 6mo ago
Compatibility so foundation packages like torch onnx-runtime can run on AMD GPU without massive change in architecture. It's the biggest reason for those stuff that "only works on nvidia gpu". It's not faster if vulkan alternative exists, but at least it runs.

rdevilla 6mo ago

ROCm is not supported on some very common consumer GPUs, e.g. the RX 580. Vulkan backends work just fine.

hurricanepootis 6mo ago
RX 580 is a GCN 4 GPU. I'm pretty sure the bare minimum for ROCm is GCN 5 (Vega) and up.
- daemonologist 6mo ago
  Among consumer cards, latest ROCm supports only RDNA 3 and RDNA 4 (RX 7000 and RX 9000 series). Most stuff will run on a slightly older version for now, so you can get away with RDNA 2 (6000 series).
  - hurricanepootis 6mo ago
    Huh, I just saw that. Huge bummer. I have a Radeon RX 6800 and on my system, I use ROCm's OpenCL for some stuff and HIP for blender cycles rendering. If ROCm were to drop support for my card, that'd be a huge bummer.
BobbyTables2 6mo ago
Did it used to be different? A few years ago I thought I had used the ROCm drivers/libraries with hashcat on a RX580 Now it’s obsolete ?
maxloh 6mo ago
I have the same experience with my RX 5700. The supported ROCm version is too old to get Ollama running. Vulkan backend of Ollama works fine for me, but it took one year or two for them to officially support it.
chao- 6mo ago
I purchased my RX 580 in early 2018 and used it through late 2024. I am critical of AMD for not fully supporting all GPUs based on RNDA1 and RDNA2. While backwards compatibility is always better than less for the consumer, the RX 580 was a lightly-updated RX 480, which came out in 2016. Yes, ROCm technically came out in 2016 as well, but I don't mind acknowledging that it is a different beast to support the GCN architecture than the RDNA/CDNA generations that followed (Vega feels like it is off on an island of its own, and I don't even know what to say about it). As cool as it would be to repurpose my RX 580, I am not at all surprised that GCN GPUs are not supported for new library versions in 2026. I would be MUCH more annoyed if I had any RDNA1 GPU, or one of the poorly-supported RDNA2 GPUs.

bruce343434 6mo ago

In my experience fiddling with compute shaders a long time ago, cuda and rocm and opencv are way too much hassle to set up. Usually it takes a few hours to get the toolkits and SDK up and running that is, if you CAN get it up and running. The dependencies are way too big as well, cuda is 11gb??? Either way, just use Vulkan. Vulkan "just works" and doesn't lock you into Nvidia/amd.

cmovq 6mo ago
Vulkan is a pain for different reasons. Easier to install sure, but you need a few hundred lines of code to set up shader compilation and resources, and you’ll need extensions to deal with GPU addresses like you can with CUDA.
- rdevilla 6mo ago
  Ah yes, but those hundred lines of code are basically free to produce now with LLMs...
  - cylemons 6mo ago
    Whatabout the extensions? is it widely supported
    - NekkoDroid 6mo ago
      That is always one check away: https://vulkan.gpuinfo.org/listextensions.php https://vulkan.gpuinfo.org/listextensions.php
      - cylemons 6mo ago
        VK_KHR_buffer_device_address has 91.3% support and VK_KHR_variable_pointers has 98.66% support looks good to me
Arech 6mo ago
Haha. People have already said what is Vulkan in practice - it's very convoluted low-level API, in which you have to write pretty complicated 200+LoC just to have simplest stuff running. Also doing compute on NVIDIA in Vulkan is fun if you believe the specs word for word. If you don't, you switch a purely compute pipeline into a graphical mode with a window and a swapchain, and instantly get roughly +20% of performance out of that. I don't know if this was a bug or an intended behavior (to protect CUDA), but this how it was a couple years ago.

0xbadcafebee 6mo ago

AMD has years of catching up to do with ROCm just to get their devices to work well. They don't support all their own graphics cards that can do AI, and when it is supported, it's buggy. The AMDGPU graphics driver for Linux has had continued instability since 6.6. I don't understand why they can't hire better software engineers.

onlyrealcuzzo 6mo ago
Because they aren't willing to pay for them?
oofbey 6mo ago
Years. They neglected ROCm for soooo long. I have friends who worked there 5+ years ago who tried desperately to convince execs to invest more in ROCm and failed. You had to have your head stuck pretty deep in the sand back then to not see that AI was becoming an important workload. I would love AMD to be competitive. The entire industry would be better off if NVIDIA was less dominant. But AMD did this to themselves. One hundred percent.
- tux1968 6mo ago
  It would be very helpful to deeply understand the truth behind this management failing. The actual players involved, and their thinking. Was it truly a blind spot? Or was it mistaken priorities? I mean, this situation has been so obvious and tragic, that I can't help feeling like there is some unknown story-behind-the-story. We'll probably never really know, but if we could, I wouldn't spend quite as much time wearing a tinfoil hat.
  - throwawayrgb 6mo ago
    if you asked AMD execs they'd probably say they never had the money to build out a software team like NVIDIA's. that might only be part of the answer. the rest would be things like lack of vision, "can't turn a tanker on a dime", etc.
    - 6mo ago

cameolkc 6mo ago

[dead]

nnevatie 6mo ago

Why is it called "ROCm” (with the strange capitalization) in the first place? This may sound silly, but in order to compete, every detail matters, including the name.

WanderPanda 6mo ago
This is so true! Shows a lack of care that usually doesn’t stop at just the naming
slongfield 6mo ago
It used to stand for "[R]adeon [O]pen [C]o[m]pute", but since it's not affiliated with the Open Compute Project, they dropped the meaning of it a little while ago, and now it doesn't stand for anything.
dnautics 6mo ago
presumably a reference to rocm/socm robots?

jmward01 6mo ago

I really want to get to the point that I am looking online for a GPU and Nvidia isn't the requirement. I think we are really close to there. Maybe we are there and my level of trust just needs to bump up.

m-schuetz 6mo ago
Problem is, NVIDIA has so many quality of life features for developers. It's not easy getting especially smaller scale developers and academia to use other vendors that are 1) much more difficult to use while 2) also being slower and not as rich in features. Personally I opted in to being NVIDIA-vendor-locked a couple of years ago because I just couldn't stand the insanely bonkers and pointless complexity of APIs like Vulkan. I used OpenGL before which supported all vendors, but because newer features weren't added to OpenGL I eventually had to make the switch. I tried both Vulkan and CUDA, and after not getting shit done in Vulkan for a week I tried CUDA, and got the same stuff done in less than a day that I could not do in a whole week in Vulkan. At that moment I thought, screw it, I'm going to go NV-only now.
- pjmlp 6mo ago
  I did my thesis porting my supervisor's project from NeXTSTEP into Windows, was an OpenGL fanboy up to the whole Long Peaks disaster. Additionally Vulkan has proven to be yet another extension mess (to the point now are actions try to steer it back on track), Khronos is like the C++ of API design, while expecting vendors to come up with the tools. However, as great as CUDA, Metal and DirectX are to play around with, we might be stuck with Khronos APIs, if geopolitcs keep going as bad or worse, as they have been thus far.

suprjami 6mo ago

Just in time for Vulkan tg to be faster in almost all situations, and Vulkan pp to be faster in many situations with constant improvements on the way, making ROCm obsolete for inference.

kimixa 6mo ago
ROCm vs Vulkan has never been about performance - you should be able to represent the "same" shader code in either, and often they back onto the same compilers and optimizers anyway. If one is faster, that often means something has gone /wrong/. The advantages for ROCm would be integration into existing codebases/engineer skillsets (e.g. porting an existing C++ implementation of something to the GPU with a few attributes and API calls rather than rewriting the core kernel in something like GLSL and all the management vulkan implies).
m-schuetz 6mo ago
Vulkan has abysmal UX though. At one point I had to chose between Vulkan and Cuda for future projects, and I ended up with Cuda because a feasibilty study I couldn't get to work in Vulkan for an entire week, easily worked in Cuda in less than a day.

xkbear89 6mo ago

[flagged]

pjmlp 6mo ago

They need lots of steps, hardware support, IDE and graphical debugging integrations , the polyglot ecosystem, having a common bytecode used by several compiler backends (CUDA is not only C++), the libraries portfolio.

emilyhudson 6mo ago

[dead]

taherchhabra 6mo ago

Genuine question. After claude code, codex etc, can't this be speedup ?

Gasp0de 6mo ago
I believe this is what that teamlead in the article comments on as next steps?

mstaoru 6mo ago

I'm team "taking on CUDA with OpenVINO" (and SYCL*), Intel seems really upped their game on iGPU and dGPU lately, with sane prices and fairly good software support and APIs. I'm not talking gaming CUDA, but CV and data science workloads seem to scale well on Arc and work well on Edge on Core Ultra 2/3.

formerly_proven 6mo ago

We’ve been talking about this for a good ten years at least and AMD is still essentially in the “concepts of a plan” phase. The AMD GPGPU software org has to be one of the most inconsequential ones at this rate.

mmis1000 6mo ago
At least they finally do something this time. Now torch and whatever transformer stuff runs normally on windows/linux as long as you installed correct wheel from amd's own repository. It's a huge step though.

DeathArrow 6mo ago

Do we get better perf or tokens per second with AMD and its software stack than with Nvidia?

wongarsu 6mo ago
The metric where AMD usually comes out on top is perf/$. Or with their instinct cards VRAM/$

techpulselab 6mo ago

[dead]

amelius 6mo ago

How long until we can use AI to simply translate all the CUDA stuff to another (more open) platform? I'm getting the feeling we're getting close. AI won't be working in nVidia's advantage this time.

mugivarra69 6mo ago
[dead]

neuroelectron 6mo ago

Now that the AI bubble is starting to burst, it's a great time for AMD to reveal their AI ambitions. They've set the tone by hiring low cost, outsourced labor. Of course everybody knows what's really going on here. It's not an open discussion, however.

adev_ 6mo ago

A little feedback to AMD executives about the current status of ROCm here: (1) - Supporting only Server grade hardware and ignoring laptop/consumer grade GPU/APU for ROCm was a terrible strategical mistake. A lot of developers experiments first and foremost on their personal laptop first and scale on expensive, professional grade hardware later. In addition: some developers simply do not have the money to buy server grade hardware. By locking ROCm only to server grade GPUs, you restrict the potential list of contributors to your OSS ROCm ecosystem to few large AI users and few HPC centers... Meaning virtually nobody. A much more sensible strategy would be to provide degraded performance for ROCm on top of consummer GPUs, and this is exactly what Nvidia with CUDA is doing. This is changing but you need to send a clear message there. EVERY new released device should be properly supported by ROCm. - (2) Supporting only the two last generations of architecture is not what customers want to see. https://rocm.docs.amd.com/projects/install-on-linux/en/docs-6.0.2/reference/system-requirements.html#supported-gpus https://rocm.docs.amd.com/projects/install-on-linux/en/docs-... People with existing GPU codebase invests significant amount of effort to support ROCm. Saying them two years later: "Sorry you are out of update now!" when the ecosystem is still unstable is unacceptable. CUDA excels to backward compatibility. The fact you ignore it entirely plays against you. (3) - Focusing exclusively on Triton and making HIP a second class citizen is non-sensical. AI might get all the buzz and the money right now, we go it. It might look sensible on the surface to focus on Python-base, AI focused, tools like Triton and supporting them is definitively necessary. But there is a tremendous amount of code that is relying on C++ and C to run over GPU (HPC, simulation, scientific, imaging, ....) and that will remain there for the multiple decades to come. Ignoring that is loosing, again, custumers to CUDA. It is currently pretty ironic to see such a move like that considering that AMD GPUs currently tend to be highly competitive over FP64, meaning good for these kind of applications. You are throwing away one of your own competitive advantage... (4) - Last but not least: Please focus a bit on the packaging of your software solution. There has been complained on this for the last 5 years and not much changed. Working with distributions packagers and integrating with them does not cost much... This would currently give you a competitive advantage over Nvidia..

pjmlp 6mo ago
Additional points, CUDA is polyglot, and some people do care about writing their kernels in something else other than C++, C or Fortran, without going through code generation. NVidia is acknowledging Python adoption, with cuTile and MLIR support for Python, allowing the same flexibility as C++, using Python directly even for kernels. They seem to be supportive of having similar capabilities for Julia as well. The IDE and graphical debuggers integration, the libraries ecosystem, which now are also having Python variants. As someone that only follows GPGPU on the side, due to my interests in graphics programming, it is hard to understand how AMD and Intel keep failing to understand what CUDA, the whole ecosystem, is actually about. Like, just take the schedule of a random GTC conference, how much of it can I reproduce on oneAPI or ROCm as of today.

grokcodec 6mo ago

The day ROCm supports EVERY AMD card on release, just like CUDA does, is the day I will actually believe this marketing hype.They really dropped the ball here, also when they abandoned recently released cards (at the time) like the 400 series. Hopefully management gets their heads out of their butts and invests more in the software stack.

greenail 6mo ago
I think GB10 is a bit of a counter point. There are tons of features that are not implemented for GB10 which was released 8/2025 It isn't all roses on the cuda side.

AshamedCaptain 6mo ago

> Last year, AMD ran a GitHub poll for ROCm complaints and received more than 1,000 responses. Many were around supporting older hardware, which is today supported either by AMD or by the community, and one year on, all 1,000 complaints have been addressed, Elangovan said. Must have been by waiting for each of the 1000 complainers to die of old age, because I do not know what old hardware they have added support for.

throwaway173738 6mo ago
I guess it counts if you can find the information from one of the many conflicting wikis out there and then figure out how to hack support for your card into the specific version of ROCm.

androiddrew 6mo ago

I have been trying since February to get someone at AMD to shipped tuned Tensile kernels in the rcom-libs for the gfx1201. They are used by Ollama but no one on the Developer Discord knows who is responsible for that. It has been pretty frustrating and it shows that AMD has an organizational problem to overcome in addition to all the things technically that they want rocm to do.

FuriouslyAdrift 6mo ago
Have you filed anything at github? https://github.com/zichguan-amd https://github.com/zichguan-amd seems to be one of the main people for that... or https://github.com/harkgill-amd https://github.com/harkgill-amd
- androiddrew 6mo ago
  I’ll try and get in touch with them. Thank you.

naasking 6mo ago

ROCm is so annoying (buggy, fiddly dependencies, limited hardware support) that TinyGrad built its own compiler and toolchain that targets the hardware directly. And it has broader device support than ROCm, which primarily seems focused on their datacenter GPUs.

ethan_smith 6mo ago
The TinyGrad approach of going straight to the hardware is telling. Between that, Vulkan compute getting faster for inference (llama.cpp Vulkan backend is competitive now), and SYCL/oneAPI, it feels like the real threat to CUDA might not be ROCm at all but a fragmented set of alternatives that each bypass AMD's broken software stack entirely.

xyzsparetimexyz 6mo ago

Better title: One Dispatch After Another

nullpoint420 6mo ago

I just don’t understand how they haven’t figured this out yet. I genuinely want to know the corporate structure and politics that have lead to their inability to execute. Is it leadership? Something else?

StillBored 6mo ago

I just wish they would make another pass at cleaning up the stack. It should be easy to `git clone --recurse-submodules rocm` followed by a configure/make that both prints out missing dependencies and configures without them, along with choices for 'build the world' vs just build some lower level opencl/HIP/SPIRV tooling without all the libraries/etc on top in a clear way. Right now the entire source base is literally throw a bunch of crap into the rocm brand and hope it builds together vs some overarching architecture. Presumably the entire spend it also tied to "whatever big Co's evaluation needs this week" when it comes to developing with it.

mellosouls 6mo ago

Related from Jan 2025: ROCm Device Support Wishlist (205 points, 107 comments) https://news.ycombinator.com/item?id=42772170 https://news.ycombinator.com/item?id=42772170