Replies: 116 comments 132 replies
-
|
Honestly, anything that has 16GB VRAM or more (or the ability to have reserved more, for eg. the iGPUs like 680/780/890M and Strix Halo iGPUs). |
Beta Was this translation helpful? Give feedback.
-
|
So does Strix Halo?
|
Beta Was this translation helpful? Give feedback.
-
|
Radeon VII and Radeon Pro VII are legends... specially in FP64 computation... they have 16GB VRAM and in some benchmarks they just make the current NVIDIA consumer cards feel ashamed. |
Beta Was this translation helpful? Give feedback.
-
|
And the Vega Frontier Edition (16GB HMB2)! |
Beta Was this translation helpful? Give feedback.
-
|
I bought a Sapphire Nitro+ Radeon RX 7800 XT hoping to use it in an OpenShift cluster homelab, so I would like to have support for the RX 7800 XT added to ROCm on Linux. Actually, how about creating an open source community and supplying the information we need to form teams, collaborate, and submit pull requests to add support for different cards? AMD is about open source, right? Let's work together to make something better for all of us! BTW, I think adding support Strix / Strix Halo APU (including NPU) would be great as well. Extending features like this to current and past GPUs with the appropriate hardware and delivering long term support will help build a loyal customer base and increase sales of new consumer GPUs. Eventually, it will help to increase your sales in server GPU hardware. |
Beta Was this translation helpful? Give feedback.
-
|
Good news! The community you're looking for already exists in Debian's ROCm team. They have ROCm CI which appears to be better than AMD's own, and they compile support for everything back to gfx800. Their library is a little old (11.8) but they'll probably update it over the next year or so. |
Beta Was this translation helpful? Give feedback.
-
|
I would like support for ROCm to be restored to all the relatively recent GPUs (last 5-6 years) AMD has released and then dropped ROCm support for. New I could not care much about. Actually supporting the AMD cards I bought in the past would be great. |
Beta Was this translation helpful? Give feedback.
-
|
Yep, it's bad enough the seperation between the ordinary mesa drivers and ROCM, but when things get dropped it really rubs it in. I've bought two AMD laptops in a row, and not sure about the next one. |
Beta Was this translation helpful? Give feedback.
-
|
I don't know about the GCN architecture at this point, but any RDNA cards should be supported at a bare minimum. If you can't support GPU compute on your current cards, then I can't take you seriously. I shouldn't have to have two computers in 2025 in order to do local ML. |
Beta Was this translation helpful? Give feedback.
-
Literally no reason not to support GCN... its a compute oriented architecture. I can understand not supporting terascale but, AMD has to support their stuff at least as long as Nvidia is supporting their own. Failing to support relatively recent stuff is just sad. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, RDNA cards are GCN cards. RDNA 1 is like GCN 6, RDNA 4 would be like GCN 9. They did some hardware architectural changes and it was time for AMD to pump some buzz out of some branding play. You can compare the move from GCN to RDNA on GPU like the move from Bulldozer to Zen on CPU: names change, products get re-architectured, branding is done, but the compiler still targets amd64 on CPU side and still target amdgcn on GPU side. TeraScale was something else entirely indeed, it's a different architectures. TeraScale as an architecutre is compatible with most modern usages starting with TeraScale 2 (OpenCL isn't a hack starting with TeraScale 2, Vulkan could be doable starting with TeraScale 2, SPIR-V is doable I guess, etc.). ROCm supported GCN before, I ran it on GCN2 Hawaii/Grenada (R9 390X), it only worked for a couple of weeks though. AMD let the code rot and they just dropped support for them in ROCm like any older card they drop support every now and then. They can support those cards if they want to, or at least make them work and let the users deal with ”I'm aware there is no official support but I can report bugs and they may fix it”. They know how to make GCN supported, they already did it. Here is my most recent issue about GCN2: |
Beta Was this translation helpful? Give feedback.
-
That is incorrect actually, its an assumption i also incorrectly have mad int he past, even GCN cards do not have the same ISA... so its not really the same thing as just targeting amd64 on CPUs... each GPU generation usually has a different ISA encoding but a lot of stuff other than that does stay the same or very similar. And of course terascale is indeed drastically different being a completely different architecture. |
Beta Was this translation helpful? Give feedback.
-
|
I think it might be interesting to share here that Debian has built a CI at ci.rocm.debian.net where the ROCm stack, and any package that depends on it, is continuously tested. Our CI includes all of the architectures listed above. We would be happy to cooperate on increasing device support for Debian and derivatives. |
Beta Was this translation helpful? Give feedback.
-
|
while I like the idea and what you're doing is nice. how do you think people will comp |
Beta Was this translation helpful? Give feedback.
-
|
I mean to have my gfx1100 properly working in let's say FLUX, I need a modern linux kernel for /dev/kfd and AMDGPU (there have been a lot of crucial fixes for RDNA3/gfx1100 in between linux 6.10-6.12) as well as ROCm 6.1+. I used to barely get it working with rocm 5.7.3 but it would not support flash attention and crap itself all the time (meaning my whole system would hang) randomly. Current Pytorch Versions don't even support old ROCm anymore: |
Beta Was this translation helpful? Give feedback.
-
|
Wonderfull. Debian magicians might build a configurator utility to build the most stable system with given set of features: I need rocm+AdaptiveCPP+Gromacs-gpu |
Beta Was this translation helpful? Give feedback.
-
|
This is not a "device" support wish, but a "platform" one. Stable Diffusion on native Windows with AMD GPUs is not possible until we get "Windows" support for "AI Libraries" (specifically MIOpen) here: https://rocm.docs.amd.com/projects/install-on-windows/en/develop/reference/component-support.html This is required to get PyTorch working. I've seen so many AMD users in recent times selling their AMD GPUs and buying "the competition" because WSL and ZLUDA are their only options, and those are half-baked solutions. Native Windows support should be a top priority. |
Beta Was this translation helpful? Give feedback.
-
|
Windows really needs some love guys, specially for HIP Runtime supported cards. I'd love to see official gfx1031 support on Windows even if through the same Linux way of gfx1030. |
Beta Was this translation helpful? Give feedback.
-
|
@V6ser gfx1031 is basically the same as gfx1030 hip kernels. you can just change one environment variable and it will work just as good as a gfx1030. Also doesn't ROCm have full native support for WSL since like 2 minor releases (I think 6.1?) I don't even understand why people use meme stuff like ZLUDA when you have ROCm (or directML that is kinda slow but works well since 2023) in WSL or Docker |
Beta Was this translation helpful? Give feedback.
-
Have you tried getting gfx1031 to work in WSL yourself or are you just saying things? I'm also not concerned with WSL usage, I wish my architecture to run natively on the OS of my choice because it's convenient and a good experience. We disagree DirectML is only 'kinda slow'. And other projects like the one you called a meme have provided people with a better experience than native HIP on Windows. |
Beta Was this translation helpful? Give feedback.
-
|
well I consider Windows a meme OS so I guess we have a different viewpoint. If you want to use your computer to do actual compute you'd not be on windows imo :D But yeah it's very much possible nonetheless. I don't have a RDNA2 myself but my friend has and got it working with rocm 6.3 (and I think already with 6.2) |
Beta Was this translation helpful? Give feedback.
-
I don't think I have to remind you that 70% of the market uses Meme OS. |
Beta Was this translation helpful? Give feedback.
-
|
A bit older than the ones listed there, but I own a 5700XT, and a good few other people do too, from my extensive looking for how to get it to work online. Still holding on to the precompiled wheel for torch 1.13 ROCM 5.2 for Python 3.10 which is the last one that works (after setting HSA_OVERRIDE_GFX_VERSION). Later versions seem to either outright crash, or import correctly but then crash when a tensor is sent to the GPU. Using this older version as a workaround was doable back when torch 2.0 was new, but now as most new code has already been using 2.0+ for a while, it's effectively not functional at all anymore for any recently written code. |
Beta Was this translation helpful? Give feedback.
-
|
me too. |
Beta Was this translation helpful? Give feedback.
-
|
You can get Pytorch to work with rock 6.2 or later on a 5700xt, but you'll need to build it from source |
Beta Was this translation helpful? Give feedback.
-
How do it for 6750xt? Is there guide for get PyTorch from source? |
Beta Was this translation helpful? Give feedback.
-
|
#4030 |
Beta Was this translation helpful? Give feedback.
-
Which is insane... that should just work out of the box. |
Beta Was this translation helpful? Give feedback.
-
|
Considering my GPU( 6600 XT) was released near the end of 2021 it would be nice to know that I don't need to buy a new GPU every year just to have support. It would also be nice to have actual proper Windows support instead of having to deal with the clusterfuck that is Zluda, or other translation layers. This kind of treatment from AMD is why I'll probably go nvidia the next time my budget allows it. |
Beta Was this translation helpful? Give feedback.
-
|
Rdna2 can use directml in windows. |
Beta Was this translation helpful? Give feedback.
-
|
why are you downvoting zamroni? it's the "official" way to use compute on older cards in windows. also it should be trivial to get your rdna2 working with rocm in wsl. The average windows user seems to not accept a "hard" solution as a solution when it is not handed premade to them. Compute/AI/ML is complex in nature and requires a bit of a learning curve to get into. if you refuse to learn and only complain then well.. |
Beta Was this translation helpful? Give feedback.
-
The OP said "or other translation layers" which probably includes DirectML. You are right that DirectML is easy to get it to work on almost any GPU but there are various caveats... In my small sample size most people get better performance and less vRAM consumption on ROCm compared to DirectML. You can and probably will experience bugs directly related to (pun unintended) DirectML, similar to ZLUDA & forks. Using DirectML also makes one dependent on Microsoft and their funding / investment in maintaining their compute / ML stack, torch-directml package has lagged behind CPU, CUDA and ROCm versions in the past leaving you stuck with old features while everyone else gets to explore and learn the new functionality. We also don't know how long Microsoft will support DirectML. I can't imagine the ROI is great at the moment. If you have no other option then DirectML is a nice alternative, but I think if many people here had to choose they would rather have official ROCm support.
Yes, some people are just lazy and like to complain but there are many people who don't have a lot of time. We can't just assume the former. Many are students who are doing b.sc or b.eng or just people learning in their limited budget and time. They simply cannot debug kernel modules (that crash their only computer) or build their own LLVM/clang compilers. Their friends or colleagues are using CUDA which allows them to get going fast and they want the same experience as them. We should try to be more humble and less judgemental. Try to see it from someone else's perspective. |
Beta Was this translation helpful? Give feedback.
-
|
APU support opens the door for introducing this software to a wide audience, please consider hitting the entire APU line (3 and 3.5.) Early ROCm worked for 780m and got me in the front door of working with this software at all (that said I had to use env var hacks to get it functioning). Later versions of ROCm stopped working at all. The hobbyist crowd would greatly benefit from APU support, which hopefully has the AMD financial incentive of market share and product familiarity (hobbyist engineers who do something neat at home and then bring the concepts to work, where you then pick up the larger purchases) If I was able to feel confident in better consumer ROCm support I would have gladly dropped money for 2 AMD graphics cards for the LLM stuff I do. |
Beta Was this translation helpful? Give feedback.
-
|
I have AMD with modest APUs I use a little for hobby stuff, and wow - what a pain. OK, I can just about llamacpp with vulkan (slowly) - but this whole ecosystem feels really disappointing. At work it's Macs and Nvidia, I couldn't see myself recommending AMD there, sort out the hobby bits + reap the rewards from people whose job this stuff is when they go back to work. |
Beta Was this translation helpful? Give feedback.
-
this is a little of a word salad. try using 70B models on strix halo, the only APU with quad channel, they're still going to be quite slow, because 250GB/s is just bad. |
Beta Was this translation helpful? Give feedback.
-
|
While it is true that running large models would not be as practical, I also believe hobbyists or students would benefit greatly from be able to get their foot in the door developing for AMD due to the rising market share of AMD laptops or even desktops with APUs. Just considering that Also being able to have it working on Windows would greatly reduce the barrier to entry. |
Beta Was this translation helpful? Give feedback.
-
No one would expect to run such heavy models on such a weak iGPU. Being able to run a 7B model and perform tasks that a 4060 Ti 16GB can do is already enough. Even if it’s slow, no one will complain because it’s an iGPU. The key is to build a ecosystem, and the APU is central to promoting that ecosystem. Affordable 780M laptops and mini-PCs are already mature, making it the perfect time to expand the ecosystem.Additionally, the memory bandwidth bottleneck may need to be circumvented with technologies like X3D; this is a technical issue, not an operational strategy issue. The problem with ROCm right now lies in its operational strategy. AMD has not correctly recognized the situation of ROCm. By only supporting consumer-grade flagship cards, it will not boost sales and will also lose the chance to make a comeback. |
Beta Was this translation helpful? Give feedback.
-
|
MOE models also make a lot of sense on Strix Halo... like Mistral Small 3 which is a 24B MOE text generation perf is gonna be fast but have better output than a similar sized non MOE model. if you have 128GB on a laptop it will let you run a large MOE model + Image generation + TTS + STT with vram/ram to spare. X3D doesnt' help AI models really at all because they don't fit in cache. |
Beta Was this translation helpful? Give feedback.
-
|
why not just all, like the other company? ;-) |
Beta Was this translation helpful? Give feedback.
-
|
Eventually. But what would you prioritize? :) |
Beta Was this translation helpful? Give feedback.
-
|
my .02 is starting from all RDNA 2 and newer. that's gonna take time. by the time they are all supported, RDNA 1 might have fairly faded out. |
Beta Was this translation helpful? Give feedback.
-
Definitelly start with RDNA2 & 3, since these series offered models with 16GB VRAM. That much memory deserves to stay around officially supported for as long as possible. Let alone the fact that cards like 6800XT still pack decent punch for local AI inference. |
Beta Was this translation helpful? Give feedback.
-
Beyond what they have to do? The low hanging fruit.. for one, like not screwing up things that already work. Like all GCN 8 and 9 GPUS should work out of the box instead of requiring people to rebuild with support enabled BECAUSE ITS ALREADY THERE. |
Beta Was this translation helpful? Give feedback.
-
|
ROCm windows, All RDNA3 and newer. Don't forget integrated GPUs. Maybe next year? |
Beta Was this translation helpful? Give feedback.
-
|
I prefer amd to focus on directml on windows. I want my phoenix xdna npu to be compatible with directml like Intel npu and Qualcomm npu do |
Beta Was this translation helpful? Give feedback.
-
|
they even can't support linux... |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
directml is crap... why divide things even further with yet another crappy API. They need one API that works everywhere. |
Beta Was this translation helpful? Give feedback.
-
|
I wish for AMD to look back at the RX 500 and the RX5000 series. And the reason being, the physical architectures for both lend themselves to really interesting compute because the RX 580 architecturally is very good to use as a modular scale up and scale down at 75 w. And based based on some back of the napkin maths that I've done an RX 580 8 gig with a 8 billion parameter model with a quant size of eight. Can pull about 15 to 30 tokens per second. |
Beta Was this translation helpful? Give feedback.
-
|
+1 !!!!! |
Beta Was this translation helpful? Give feedback.
-
|
Hi, So you should start by supporting strix halo and RDNA 4. Then RDNA 3 and prior APUs. |
Beta Was this translation helpful? Give feedback.
-
|
Thank you for reaching out and at least trying to extend the device support. The limited consumer hardware support has always been one of the weakest point of ROCm, and if AMD is serious about the future of ROCm, at least any upcoming hardware should be supported. Being able to get used to a platform without spending 1000s is actually huge. |
Beta Was this translation helpful? Give feedback.
-
|
It's ridiculous that lamikr has been able to do what he has as a one man show whilst AMD can't (or rather can't be bothered). Maybe AMD should engage with him. If you look at the people watching the repo there are some AMD engineers. |
Beta Was this translation helpful? Give feedback.
-
|
At one time Kaveri was promoted as a hybrid processor, and while HSA was being implemented its support disappeared. It would be fair, given the promises of marketers, to make HSA + ROCm for APU Kaveri. |
Beta Was this translation helpful? Give feedback.
-
|
HSA acutally goes all the way back to Trinity in 2012... its missing shared virtual memory that Kaveri implemented though. |
Beta Was this translation helpful? Give feedback.
-
|
Missing poll option: actually support the ✅ marked devices consistently There's not much point having a green icon in the support matrix if it doesn't mean your device is supported. |
Beta Was this translation helpful? Give feedback.
-
|
Yeah this is the big thing. Besides missing rdna1 support, the actual support matrix (not the mostly useless check mark, what the code supports) is mostly fine, except random libraries that then support only a subset of those. |
Beta Was this translation helpful? Give feedback.
-
We would like to hear from the community what other cards you would like to see ROCm support for. Currently compatibility matrix for Linux is at https://rocm.docs.amd.com/projects/install-on-linux/en/latest/reference/system-requirements.html and Windows is at https://rocm.docs.amd.com/projects/install-on-windows/en/latest/reference/system-requirements.html.
No guarantees of future support but we will try hard to add support.
ROCm on Linux
AMD Instinct
AMD Radeon PRO
AMD Radeon
HIP Runtime and SDK on Windows
AMD Radeon PRO
AMD Radeon
1k votes ·
Beta Was this translation helpful? Give feedback.
All reactions