Repository navigation
Replies: 182 comments 326 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). |
|
Thanks for the feedback @janhec! I see that you've filed a few issues already, which we'll work on triaging and fixing.
I've seen a few similar issues (ROCm/TheRock#1135, ROCm/rocm-libraries#535 (comment)). If you file another issue on https://github.com/ROCm/TheRock or https://github.com/ROCm/rocm-libraries with more complete logs for that build error we can take a closer look. I think we're a few fixes away from solving that one for good 🤞 |
|
So, my build finally built, to use a grammarism. The only 'real' issues, which are not fatal, are the proper distribution of hip header files and rocblas building for Configure command was: gfx1032 was insufficiently supported for rocBLAS, so also cannot (yet?) be used for AI/MI/ML (whatever you prefer) with this distribution. Technically, only the fallback kernels where generated for gfx1032, which prevented building the optimized kernel(s) (lazy...) and stopped the build (and cost me plenty of time to find out). |
|
Note that the header folder structure under |
|
Should be ok now. |
|
Mate, just use the EDIT function instead of replying yourself 2 times, otherwise you are pinging 200 people every single time. If you guys are getting a problem, I would strongly recommend you to use the Issue tracking instead. |
|
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. |
|
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. |
|
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. |
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. |
|
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: |
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. |
|
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. |
|
while I like the idea and what you're doing is nice. how do you think people will comp |
|
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: |
|
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 |
|
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. |
|
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. |
|
@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 |
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. |
|
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) |
I don't think I have to remind you that 70% of the market uses Meme OS. |
|
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. |
|
me too. |
|
You can get Pytorch to work with rock 6.2 or later on a 5700xt, but you'll need to build it from source |
How do it for 6750xt? Is there guide for get PyTorch from source? |
|
https://github.com/ROCm/ROCm/discussions/4030 |
Which is insane... that should just work out of the box. |
|
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. |
|
Rdna2 can use directml in windows. |
|
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.. |
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. |
|
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. |
|
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. |
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. |
|
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. |
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. |
|
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. |
|
why not just all, like the other company? ;-) |
|
Eventually. But what would you prioritize? :) |
|
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. |
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. |
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. |
|
ROCm windows, All RDNA3 and newer. Don't forget integrated GPUs. Maybe next year? |
|
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 |
|
they even can't support linux... |
|
directml is crap... why divide things even further with yet another crappy API. They need one API that works everywhere. |
|
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. |
|
+1 !!!!! |
|
Hi, So you should start by supporting strix halo and RDNA 4. Then RDNA 3 and prior APUs. |
|
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. |
|
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. |
|
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. |
|
HSA acutally goes all the way back to Trinity in 2012... its missing shared virtual memory that Kaveri implemented though. |
|
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. |
|
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. |
|
Chicken and egg. I don't own any of your hardware because I can't run the software I want to run. Support Flux, Stable Diffusion, Tencent Hunyuan Video, Nvidia Cosmos, and I'll be in the market to buy your cards. As it stands, I can't leverage your offering. I'll gladly build AMD workstations if your hardware can do the things I want. Prioritize VRAM. The next battle is local image and video models. Nobody wants to use hosted SaaS and all the film and VFX people will be running local Comfy, Hunyuan, etc. in just a few years time. These models need a tremendous amount of VRAM, so you need to build consumer/prosumer SKUs that have it. If you time this right and build high VRAM consumer cards with broad software support, the next generation of media production could ride on your platform. Let me underscore: you must be able to run popular image and video models. |
...and run them near release, not first introduce support years down the line. |
|
a 9090 XTX 50GB VRAM would be the dream...doesn't even have to be fast (tbh why are GPU vendors focusing on speed when capacity is the more important thing for consumers?) |
|
It's probably been mentioned elsewhere but support for the AI 300 series processor onboard graphics, Radeon 840M, 860M, 880M and 890M. There are a lot of people who purchased these for AI workloads. |
|
I mean its just a IGP... the AI part of those SOCs is the XDNA NPU not the GPU. |
Yeah, but the XDNA NPU only supports int8 and bfloat16 it´s usefull for inference if you have a model that uses these datatypes. But hard to use for training or other calculations.. ROCm isn´t only about AI! It´s a general computing library! It provides things like BLAS and such. The GPU on Strix Halo is quite beefy compared to other APUs, supports fp32 and fp64 and has a wide interface to the full system ram which allows you to work with larger datasets that would not fit into to much smaller VRAM of other dedicated consumer GPUs. That makes it pretty unique for AMD64 based Systems in this price range.. There are only the M2/M3 Macs i know of which have a similar design but they are ARM64 based / run MacOS + their ecosystem. |
|
don't over estimate strix halo its still only 256GB/s ram give or take.... which is around 1/8 to 1/4 what a compute card would have. So even if you can fit a model in strix halo its going to run 4x slower just because the bandwidth isn't there, its also got far less compute than those cards. I mean its fine for some lightweight training and inference with larger models even... but it does have limitations. Beefy relative to an iGPU is still wimpy compared to we... any regular desktop compute cards with the exception of ram capacity. |
|
Don't sub-estimate strix halo either. For computing is great in comparison to Nvidia 5070 or 5080 Mobile - we can't compare desktop edition, it would be totally unfair due TDP. |
|
5080 mobile has 900GB/s of bandwidth... as long as the model can load its going to be 3x faster for text generation at LEAST. |
ROCm sometimes lags behind something rustic like RustiCL :\
|
|
I presume this is from https://www.phoronix.com/review/rocm-rusticl-strix-halo/. While it's great that rusticl does so well in this particular scenario, it seems ROCm still does better for most other OpenCL workloads. I've experimented a bit with rusticl, mainly on hardware that lacks official ROCm support, and at least compared with the PAL implementation in the Windows driver (on the same hardware) I found it lagged far behind ROCm (by an order of 3x). And in my observations ROCm implementation doesn't appear to perform significantly better or worse than PAL. Of course, that was a long time ago and things might have improved with Mesa (at the time, I didn't find rusticl significantly better than the previous Clover implementation). Maybe it's time to give it another go. |
|
I would like WSL2 support, I am alas a windows user, and would like to taste the awesome power of AMD cards in AI computations. but am limited by libraries, that doesn't allow to use the 24 GB of mem that I have, DirectML gets stuck, openCL gets stuck, WSL2 just doesn't see the card which I bought for AI computations, and feel like I am stuck in a 1*1 cells and cannot break out. on windows I at least can use the video card memory, WSL tensorflow, just doesn't see the card, no numa device, no fun. |
|
I'm assuming RX 7900 card? Do you have integrated graphics? Try disabling the iGPU in device manager or the bios. When installing ROCm on Ubuntu 24.04 make sure in the usecase "wsl" is there and the flag --no-dkms. |
|
What driver version I should install with ROCM support on AMD ATI Radeon RX 6600/6600 XT/6600M Ubuntu 24.04 ? When I install latest driver from official site
|
|
I am pretty sure your past experience is out of date. Worse case you just update amdgpu again manually. Amdgpu from AMD and from ubuntu are almost the same thing anyway and the package is just a stub that installs the amd official repos its only like 24kb. You apt install rocm to get the "blessed" releases of those. For it to acutally install the amdgpu driver itself you'd have to install amdgpu-dkms but I am pretty sure you can ignore that usually. |
|
I have fully reinstalled the system since I last installed amdgpu, so there is no residue of that. Doesn't the package also install an alternative driver in user space to mesa? I think I read a few weeks ago that AMD is giving up on it's user-space Linux driver and will support mesa instead, as mesa has already higher performance and is more feature complete I think, but I'm not sure if that already happened. I think that driver caused issues with video playback for me a few years ago. Ubuntu will come with a fairly recent kernel (with HWE installed) that has the driver (that is developed and maintained by AMD) included and fully supports ROCm, why install something that is not needed at all with the risk of breaking the system? There is no benefit, at best you only get some slight performance decrease on some games. All you need to do is install ROCm, and AMD provides a Ubuntu repository for that. Especially for Linux beginners I would recommend not to use any binary installer outside the package manager (that's one reason why many distributions ship a re-packaged NVIDIA driver with their package system, because the NVIDIA driver installer can also mess up a system). |
Not sure, I know the pro vulkan is now gone for sure though not sure about the OpenGL. Radv the Vulkan in Mesa is the one AMD supports. In any case you can have multiple of those installed anyway AFAIK.... You seem to be making alot of wrong assumptions. Installing the amd package doesn't do anything to the kernel.. its compiled against ubuntu's stock kernel. You should definitely stop commenting further if you aren't even going to look at what the offical package even is though. It's literally just a package that installs the requisite repos, there is no binary non deb installer anymore for Ubuntu. |
|
Sorry, you're right, I didn't look at the package up, as I gave up on it after my bad experience, it's not necessary for ROCm and I wanted to prevent someone else going through the bad experience I had. I had a look at the driver package and the situation is now very different since I last looked at it (good work AMD!). The setup tools are just scripts that will install packages. It seems you can set a later ROCm version yourself and then use the other script to only install rocm: This seems to do basically the same as what I described above, but all automated and therefore a lot more beginner friendly. If that's now all that is needed to install ROCm, well done AMD! |
|
|
https://www.phoronix.com/news/AMD-ROCm-7.0-Released Expectations for ROCm 7.0: Groundbreaking performance, broad compatibility with mainstream consumer hardware, and plug-and-play ease of use. |
|
The author was using a build of llama.cpp over a month old, which had none of the ported cuda kernels that the rocm build now has. |
|
Could add MAX+395 (8060s GPU, gfx1151 LLVM target) to the support wishlists? Somebody say ROCm7.0.1 could support MAX+395 (gfx1151), but ROCm7.0.1 could not be installed in WSL+ubuntu with error "Unable to locate package hsa-runtime-rocr4wsl-amdgpu", who can help to fix it? |
|
It seems we have to wait for the new AMD driver on windows to enable WSL2 support. |
|
Thanks for the new preview support for Strix Point with ROCm 6.4.4, and PyTorch packages! I've been trying out Stable Diffusion XL with ComfyUI following these instructions (here and here). The first image gen took a disappointing ~30 mins, but that seems to be a weird ComfyUI bug with ROCm, and subsequent runs for a previously-used resolution are much better at 1 minute. Performance seems comparable to DirectML with Amuse or Olive, but without having to find or convert to onnx format. |
|
Is the information in the initial post still up to date? I have the opportunity to build an AI-Server for the school I'm working at. The budget is quite low, though. So I wanted to settle with a few MI50 GPUs. But the initial post shows the MI50 as deprecated (but still supported), the AMD website on the other hand shows the MI50 as unsupported. So, my question is: is it still possible to use a bunch of MI50 for AI stuff nowadays? If not, is there a similar alternative for low budget systems? Thanks in advance for some hints. Greets |
|
As someone who deals with AMD devices for years now, you better stick to the list of officially supported hardware. Also, it is useful to know that you can't assume that something in the PRO line, even from the latest generation, will be supported. Just stick to the list. They want to improve the coverage and they work on it, but don't hold your breath because it will takes year. (Edit: and at the time the situation will be better, the already obsolete MI50 will even not be considered any more). |
|
That's a pity, because of the slim budget. But thanks for the information. I'll have to look for something else then. Greets |
|
For now mi50 is still well supported by the code, just AMD dosent build vor them anymore. This means you have to build rocm for gfx906 yourself (not so easy unless you are expiranced) or you can use rocm built by people other than and such as distro maintainers I would recommend arch Linux. On arch Linux installing rocm for mi50 is trivial, simply install the rocm packages via pacman. |
|
@RealTehreal |
|
Thanks for adding gfx1151 and gfx1150 on the roadmap. |
|
Voting for "GCN and prior" because there is no dedicated Polaris option. I agree with most of the comments here, it's quite unfortunate that so many people can't use their older cards(for example mine rx580/gfx830) with ROCm. |
|
I got excited about the new changes, and since i was looking to move definitively to linux, i bought an affordable radeon gpu thinking it would benefit from the rumored rocm updates. I bought the rX 7600(gfx1102 as that's the best that my budget allowed, but it sucks that there's still no support for it on linux with rocm 7.0.2. Please add support for at least the entire previous generation family, the 7000 series i still good, don't cripple it by limiting support for it :( |
|
with the news of AMD dropping RDNA 2 from the latest drivers, and rocm 7.1 still not adding support for the full RDNA 3 family, now I very much regret my choice. If RDNA 3 is dropped before 7 years, I'll never get another AMD card no matter how annoying the competition makes it to set it up on linux. I'm now stuck with this until i can afford another card, but yeah, good bye AMD, good luck with killing radeon |
|
This doesn't affect Linux at all. There's a lot of sensationalism out there. |
|
If I understand correctly, RDNA 2 was not buried in legacy support, it went to a secondary branch with less priority since RDNA 2 does not support the same ML instructions as its successors. @powderluv |
|
Rdna 2 is indeed in a bit oft a wird spot, being the last GPU without any Kind of matrix instructions |
|
@powderluv / @stellaraccident It's great to see the recent cadence and build improvements for ROCm. Keep up the good work. :) Can you comment if these statements on aiter / CK non-support, or non-optimized support, for navi3/navi4 are still accurate? See ROCm/aiter#900 and ROCm/composable_kernel#1958 A key quote:
I guess the build teams and library teams might be separate, but is it possible to get some roadmap clarity? Beyond that, a few suggestions/ideas:
|
|
CK support for navi3/4 is being worked on right now with an ETA of end of year. Getting clarity on AITER is a work in progress. Agreed with the meta point of providing more fine grained detail on library-level maturity vs an all or nothing "supported" state. |
|
@saadrahim Can we capture this feedback about request for roadmap/maturity? |
|
@stellaraccident |
Let me see if I can get a team juggled to focus on this and make sure the work that is being done on all of the individual projects rolls up to make this meet the standard you are calling for in 5674. On my side, I see the necessary work getting done, but let me see if I can get the eta tightened up and make sure nothing is missed (again). |
|
FYI awesome to see the new 7.10 preview and it's expanded HW support. I see no official preview support for gfx12/rdna4 yet though. That's fine. Do what makes sense to do first. But hopefully the teams are using the time to get their gfx12-specific improvements up to snuff. :) |
|
please support ryzen 5 8600 G |
|
Folks - this poll has been idle for a long time but it is still receiving a trickle of comments based on proliferation on social, etc. So I'm posting an update here. We have consolidated the work to support all of our in-market GPUs on ROCm for both Linux and Windows under TheRock project and the current status will be kept updated here: https://github.com/ROCm/TheRock/blob/main/SUPPORTED_GPUS.md These represent development releases that we use and make available publicly for bringup and qualification of the software. As the software support for each of the items on that list hits maturity, they will be made available by default in future, officially supported ROCm versions. While the older cards may receive more limited investment with respect to performance and latest library support, we will keep them all in our public CI/CD system and ensure that the software does not regress until they are end of lifed. Especially for these older parts, community feedback and contributions are welcome. And we will take responsibility for the overall availability and baseline quality of the software supporting them. Currently, the next major version of ROCm will begin to incorporate this change of approach and you will see that in the first half of 2026. Minor versions will enable additional targets as they become release ready at a cadence of every 6 weeks from there. Both of these are a continuation of what you can get today on TheRock as development builds but will receive additional diligence for official (re)release as time goes on. Thank you for continuing to choose AMD products. |
|
Basically, support is okay for RDNA3 and 4, and a "maybe it will work" for anything prior to that. Totally dishonest with what was promised, but it doesn't surprise me anymore. So... At least provide quick support for RDNA3 and 4 at a minimum; ROCm' issues have been piling up for many months. |
|
It won't be "maybe it will work". The current state is degraded, as that document shows (six months ago, I couldn't even have told you how degraded but we have brought the software support for these cards back and are working through them). But we are working on qualifying to a higher standard for the older cards. Just being transparent that is the plan and we aren't there yet. On these development channels, I try to represent reality and what the plan is. And yes, there is much work that remains. |
|
@stellaraccident maybe add gfx900 and gfx803 to your array, obviously marked as not "Build Passing" and not "Sanity Tested" for now. I know for a fact that gfx900 still works fine if you build the stack for it and gfx803 needs patching around things. Even if you never re qualify either of those to any standard it would be good to document this. |
|
@sa-faizal feedback for you ^ |
|
Stella, thanks.
i read the page a lot more positively.
i can see that the builds for the two old series (MI50/Radeon Pro VII) are
no longer being forcibly disabled, completed recently and that one can help
matters by CI configuration or some manual testing.
i can infer that this is the mechanism for any kind of architecture.
i can see what OS is preferable also.
i could not find out what tests to run etc. but that is a different problem
than knowing neither that nor the rules of the game.
engineering wise we can now talk one language.
if i want it to work i need to make sure everything works that makes up 3
green checkmarks, and then it works.
i can tell that if overnight i turn lnto an AI genius and i fix a feature
that was missing or tune something, that will be OK if i ensure 3 fresh
green test results. ok, ill not become that, but many others are doing
those exact things.
logic and experience tell us that AMD will also become more quick and
reliable adding new cards and getting feedback from distro maintainers and
users via this approach.
i don't think is less than promlsed, even if the next architecture still
needs to be added. they removed obstacles.
Florian
Stella Laurenzo ***@***.***> schrieb am Do., 4. Dez. 2025,
20:52:
… It won't be "maybe it will work". The current state is degraded, as that
document shows. But we are working on qualifying to a higher standard for
the older cards. Just being transparent that is the plan and we aren't
there yet.
On these development channels, I try to represent reality and what the
plan is. And yes, there is much work that remains.
—
Reply to this email directly, view it on GitHub
<#4276 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AAVSVGYDW4FJEXGKGXSXMQL4ACGINAVCNFSM6AAAAABVQ66K5GVHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKMJWGQ4DGOI>
.
You are receiving this because you commented.Message ID:
***@***.***>
|
and others
Uh oh!
There was an error while loading. Please reload this page.
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 ·
All reactions