11 ms·
ROCm Device Support Wishlist
- superkuh 2y agoMy wishlist for ROCm support is actually supporting the cards they already released. But that's not going to happen. By the time an (consumer) AMD device is supported by ROCm it'll only have a few years of ROCm support left before support is removed. Lifespan of support for AMD cards with ROCm is very short. You end up having to use Vulkan which is not optimized, of course, and a bit slower. I once bought an AMD GPU 2 years after release and 1 year after I bought it ROCm support was dropped.
- slavik81 2y agoFWIW, every ROCm library currently in the Debian 13 'main' and Ubuntu 24.04 'universe' repository has been built for and tested on every discrete consumer GPU architecture since Vega. Not every package is available that way, but the ones that are have been tested on and work on Vega 10, Vega 20, RDNA 1, 2 and 3. Note that these are not the packages distributed by AMD. They are the packages in the OS repositories. Not all the ROCm packages are there, but most of them are. The biggest downside is that some of them are a little old and don't have all the latest performance optimizations for RDNA 3. Those operating systems will be around for the next decade, so that should at least provide one option for users of older hardware.
- deleted 2y ago[deleted]
- mappu 2y agoI can confirm this, Debian's ROCm distribution worked great for me on some "unsupported" cards.
- buildbot 2y agoPackages existing and the software actually working are very different things. You can run rocm on unsupported GPUs like a 780m, but as soon as you hit an issue you are out of luck. And you’ll hit an issue. For example, my 780m gets 1-2 inferences from llama.cpp before dropping off the bus due to a segfault in the driver. It’s a bad enough lockup that linux can’t cleanly shutdown and will hang under hard rebooted.
- slavik81 2y agoThe 780m is an integrated GPU. I specified discrete GPUs because that's what I have tested and can confirm will work. I have dozens of different AMD GPUs and I personally host most of the Debian ROCm Team's continuous integration servers. Over the past year, I have worked together with other members of the Debian project to ensure that every potentially affected ROCm library is tested on every discrete consumer AMD GPU architecture since Vega whenever a new version of a package is uploaded to Debian. FWIW, Framework Computers donated a few laptops to Debian last year, which I plan to use to enable the 780m too. I just haven't had the time yet. Fedora has some patches that add support for that architecture.
- deleted 2y ago[deleted]
- bb88 2y agoThey should have at a minimum 5 year support release cycle.
- deleted 2y ago[deleted]
- kllrnohj 2y agoIt kinda seems like they do - 5 years would only include the RX 6xxx and 7xxx. 5 years is not very long tbh.
- mikepurvis 2y agoAs the underdog AMD can't afford to have their efforts perceived as half-assed or a hobby or whatever. They should be moving heaven and earth to maximize their value proposition, promising and delivering on longer support horizons to demonstrate the long term value of their ecosystem.
- deleted 2y ago[deleted]
- seanhunter 2y agoHonestly at this point half-assed support would be a significant step up from their historical position. The one thing they have pioneered is new tiers of fractional assedness asymptotically approaching zero.
- XorNot 2y agoI mean at this point my next card is going to be an nvidia. It has been a total waste of time trying to use rocm for anything machine-learning based. No one uses it. No one can use it. The card I have is somehow always not quite supported.
- llm_trw 2y agoWe go from: Support is coming in three months! To This card is ancient and will be no longer developed for. Buy our brand new card released in three months! Every damned time.
- 7speter 2y agoI have a mi50 with 16gb of hbm thats collecting dust (its Vega bases, so it can play games, I guess) because I don’t want to bother setting up a system with Ubuntu 20.04, the last version of Ubuntu the last version of ROCM that supported the MI50 works on. With situations like this, its not hard to see why Nvidia totally dominates in the compute/ai market.
- slavik81 2y agoThe MI50 may be considered deprecated in newer releases, but it seems to work fine in my experience. I have a Radeon VII in my workstation (which shares the same architecture) and I host the MI60 test machine for Debian AI Team. I haven't had any trouble with them.
- 7speter 2y agoI don’t think the mi60 has reached deprecated status yet (the last time I look at prices for the mi50 and mi60, the mi60 was something like 3x expensive, and I think thats because its still officially supported), but I’ll check this all out. Thanks.
- slavik81 2y agoThe MI60 is basically just a faster MI50 with more memory. They were deprecated together. It's plausible there could be small firmware or driver differences that cause issues in one but not the other, but I think that's unlikely.
- nalllar 2y agoI had the impression Debian applied patches that widen arch support from what upstream officially supports, including for the MI50/MI60. https://salsa.debian.org/rocm-team/rocm-hipamd/-/raw/d6d20142c37e1dff820950b16ff8f0523241d935/debian/patches/0026-extend-hip-isa-compatibility-check.patch https://salsa.debian.org/rocm-team/rocm-hipamd/-/raw/d6d2014... (one patch of many)
- 2y ago
- FuriouslyAdrift 2y agoAMD has separate architectures for GPU compute (Instinct https://www.amd.com/en/products/accelerators/instinct/mi300.html https://www.amd.com/en/products/accelerators/instinct/mi300....) and consumer video (Radeon). AMD are merging the architectures (UDNA) like nVidia but it's not going to be before 2026. (https://wccftech.com/amd-ryzen-zen-6-cpus-radeon-udna-gpus-utilize-n3e-high-end-gaming-gpus-3d-stacking-for-next-gen-halo-console-apus-rumor/ https://wccftech.com/amd-ryzen-zen-6-cpus-radeon-udna-gpus-u...)
- 7speter 2y agoYou can use ROCM on consumer radeon as long as you pay more than 400 dollars for one of their gpus. Meanwhile, you can run stable diffusion with the -lowvram flag on a 3050 6gb that goes for 180 dollars
- nubinetwork 2y agoSeeing Radeon VII on the deprecation list is a little saddening, unless they start putting out more 16gb+ GPUs that aren't overly expensive...
- ghostpepper 2y agoI can understand wanting to prioritize support for the cards people want to use most, but they should still plan to write software support for all the cards that have hardware support.
- KeplerBoy 2y agoImagine Nvidia not supporting CUDA on any of their cards. Unthinkable.
- latchkey 2y agoNvidia takes a software first approach and AMD takes a hardware first approach. It is clear that AMD's approach isn't working and they need to change their balance.
- kouteiheika 2y agoHardware first, but then their hardware isn't any better than NVidia's, so I don't see how that's a valid excuse here. (Okay, maybe their super high end unobtanium-level GPUs are better hardware-wise. Don't know, don't care about enterprise-only hardware that is unbuyable by mere mortals.)
- latchkey 2y agoSome of it isn't unbuyable... it is just expensive. https://www.ebay.com/itm/305850340813 https://www.ebay.com/itm/305850340813 But that's why my business exists... https://news.ycombinator.com/item?id=42759191 https://news.ycombinator.com/item?id=42759191
- whywhywhywhy 2y agoIt's just not, people like to try and defend AMD out of hatred for Nvidia but the thousands of fumbles over the past 15 years that have led AMD to their current position and Nvidia to their current dominance are not deserving of coddling and excuses. The fact support still isn't there, they've had 2 years since Stable Diffusion to get a serious team up and shipping and they still don't even have enough resources pointed at this to not have to be asking what should be prioritized. The only way to fix their culture/priorities is to stop buying their cards.
- latchkey 2y agoFor context, the submitter of the issue is Anush Elangovan from AMD who's recently been a lot more active on social after the SemiAnalysis article, and taking the reigns / responsibility of moving AMD's software efforts forward. However you want to dissect this specific issue, I'd generally consider this a positive step and nice to see it hit the front page. https://www.reddit.com/r/ROCm/comments/1i5aatx/rocm_feedback_for_amd/ https://www.reddit.com/r/ROCm/comments/1i5aatx/rocm_feedback... https://www.reddit.com/user/powderluv/ https://www.reddit.com/user/powderluv/
- KeplerBoy 2y agoAlso know as the AMD representative who recently argued with Hotz about supporting tinycorp.
- latchkey 2y agoIs that a bad thing? Good for him to stand up to extortion.
- modeless 2y agoOffering software support in exchange for payment is extortion?
- KeplerBoy 2y agoHard to say from my perspective. I think AMDs offer was fair (full remote access to several test machines), then again just giving tinycorp the boxes on their terms with no strings attached as a kind of research grant would have earned them some goodwill with that corner of the community. Either way both parties will continue making controversial decisions.
- ac29 2y agoAMD supports only a single Radeon GPU in Linux (RX 7900 in three variants)? Windows support is also bad, but supports significantly more than one GPU.
- llm_trw 2y agoImagine nvidia supported only the 4090, 4080 and 4070 for cuda at the consumer level. With the 3090 not being supported since the 40xx series came out. This is what amd is defending here.
- Delk 2y agoI honestly can't figure out which Radeon GPUs are supposed to be supported. The GitHub discussion page in the title lists RX 6800 (and a bunch of RX 7xxx GPUs) as supported, and some lower-end RX 6xxx ones as supported for runtime. The same comment also links to a page on the AMD website for a "compatibility matrix" [1]. That page only shows RX 7900 variants as supported on the consumer Radeon tab. On the workstation side, Radeon Pro W6800 and some W7xxx cards are listed as supported. It also suggests to see the "Use ROCm on Radeon GPU documentation" page [2] if using ROCm on Radeon or Radeon Pro cards. That link leads to a page for "compatibility matrices" -- again. If you click the link for Linux compatibility, you get a page on "Linux support matrices by ROCm version" [3]. That "by ROCm version" page literally only has a subsection for ROCm 6.2.3. It only lists RX 7900 and Pro W7xxx cards as supported. No mention of W6800. (The page does have an unintuitively placed "Version List" link through which you can find docs for ROCm 5.7 [4]. Those older docs are no more useful than the 6.2.3 ones.) Is RX 6800 supported? Or W6800? Even the amd.com pages seem to contradict each other on the latter. Maybe the pages on the AMD site only list official production support or something. In any case it's confusing as hell. Nothing against the GitHub page author who at least seems to try and be clear but the official documentation leaves a lot to be desired. [1] https://rocm.docs.amd.com/projects/install-on-linux/en/latest/reference/system-requirements.html https://rocm.docs.amd.com/projects/install-on-linux/en/lates... [2] https://rocm.docs.amd.com/projects/radeon/en/latest/docs/compatibility.html https://rocm.docs.amd.com/projects/radeon/en/latest/docs/com... [3] https://rocm.docs.amd.com/projects/radeon/en/latest/docs/compatibility/native_linux/native_linux_compatibility.html https://rocm.docs.amd.com/projects/radeon/en/latest/docs/com... [4] https://rocm.docs.amd.com/projects/radeon/en/docs-5.7.0/docs/compatibility.html https://rocm.docs.amd.com/projects/radeon/en/docs-5.7.0/docs...
- wtcactus 2y agoI’m constantly baffled and amused on why AMD keeps majorly failing at this. Either the management at AMD is not smart enough to understand that without the computing software side they will always be a distant number 2 to NVIDIA, or the management at AMD considers it hopeless to ever be able to create something as good as CUDA because they don’t have and can’t hire smart enough people to write the software. Really, it’s just baffling why they continue on this path to irrelevance. Give it a few years and even Intel will get ahead of them on the GPU side.
- musicale 2y agoIf I were Jensen, I would snap up all the GPU software experts I possibly could, and put them to work improving the CUDA ecosystem. I'd also spin up a big research group to further fuel the CUDA pipeline for hardware, software, and application areas. Which is exactly what NVIDIA seems to be doing. AMD's ROCm software group seems far behind, is probably understaffed, and probably is paid a fraction of what NVIDIA pays its CUDA software groups. AMD also has to catch up with NVlink and Spectrum-X (and/or InfiniBand.) AMD's main leverage point is its CPUs, and its raw GPU hardware isn't bad, but there is a long way to go in terms of GPU software ecosystem and interconnect.
- almostgotcaught 2y ago> I’m constantly baffled and amused on why AMD keeps majorly failing at this. i wonder if you've considered the possibility that there's some component/dimension of this that you're simply unaware of? that it's not as straightforward as whatever reductive mental model you have? is that even like within the universe of possibilities?
- rcxdude 2y agoI mean, they did say they were baffled. I'd say that probably includes "I don't know"
- omcnoe 2y agoI've never understood why they have such a fractured approach to software:hardware support. I remember reading and writing comments about this on hn nearly a decade ago now. It's a long time to keep making the same mistake. They had the exact same kind of support issues back in the OpenCL days, where they didn't manage to provide cross platform, cross card support for same versions of the platform. I have never been able to reconcile it with their turnaround and newfound competence on the CPU side.
- maverwa 2y agoI figure that list is only what’s officially supported, meaning things not on that list may or may not work?. For example, my 6800 XT runs stable diffusion just fine on Linux with PyTorch ROCm.
- Toutouxc 2y agoWhat’s the performance like? Was it easy to set up?
- maverwa 2y agoI cannot compare the performance with other cards, but it takes a few seconds for SDXL images (e.g. 1024x512) as long as it doesn’t run OOM. I use a fork of the stable diffusion webui [0] which, for me, handled memory better. Setup was relatively easy: install the pytorch packages from the ROCm repo and it worked. [0]: https://github.com/lllyasviel/stable-diffusion-webui-forge https://github.com/lllyasviel/stable-diffusion-webui-forge
- phkahler 2y agoAdd support for every APU. They can have much more RAM than discrete graphics.
- __turbobrew__ 2y agorocm is kind of a joke. Recently I wanted to write some golang code which talks to rocm devices using amd smi. You have to build and install the go amd smi from source, the go amd smi repo has dead links and there is basically no documentation anywhere on how to get this working. Compare this to nvidia where I just imported the go nvml library and it built the cgo code and automatically links to nvidia-ml.so at runtime.
- magic_at_nodai 2y agoIs this the repo you are referring to https://github.com/amd/go_amd_smi https://github.com/amd/go_amd_smi ? Would having a prebuilt version there help you ?
- __turbobrew__ 2y ago“ * NOTE: * The GO SMI binding depends on the following libraries: - E-SMI inband library ("https://github.com/amd/esmi_ib_library https://github.com/amd/esmi_ib_library") - ROCm SMI library("https://github.com/ROCm/rocm_smi_lib https://github.com/ROCm/rocm_smi_lib") - AMDSMI library("https://github.com/ROCm/amdsmi https://github.com/ROCm/amdsmi") - goamdsmi_shim library ("https://github.com/amd/goamdsmi/goamdsmi_shim")” https://github.com/amd/goamdsmi/goamdsmi_shim")” First of all this link is dead: https://github.com/amd/goamdsmi/goamdsmi_shim https://github.com/amd/goamdsmi/goamdsmi_shim Second: these dependencies should all be packaged into deb/rpm Third: there should be a goamdsmi package which has a proper dependency tree. I should be able to do ‘apt-get install goamdsmi’ and it should install everything I need. This is how it works with go-nvml.
- cherryteastain 2y agoReally telling they have to ask us for what cards we want as opposed to supporting all cards by default from day 1 like Nvidia. All because they went with a boneheaded decision to require per-device code compilation (gfx1030, gfx1031...) instead of compiling to an intermediate representation like CUDA's PTX. Doubly boneheaded considering the graphics API they developed, Vulkan, literally does that via SPIR-V!
- diggan 2y agoReally telling who comments before reading :) The author of the issue comments that they'll eventually support all cards. What he really is asking for, is what cards people want them to prioritize, not just support.
- magic_at_nodai 2y agoyes. We are behind on software support for all consumer cards and would love to support all cards. But are looking for guidance / feedback so we can prioritize.
- cherryteastain 2y agoThis line sparks no confidence: > No guarantees of future support but we will try hard to add support. AMD reps told me exactly the same thing years ago about how they'd love to support all cards, when RDNA2 had just launched. Fast forward, only W6800 is properly supported from that gen. The last time I tried, it had tons of kernel bugs that caused hard freezes outside most basic cases. You need to come out and say that you will support all cards, no ifs or buts, by a hard deadline.
- cherryteastain 2y agoI read it fully. Whole point of my post is that, based on their track record so far plus the technical limitations, it is impossible for AMD to provide the same day 1 drop in compatibility that the CUDA ecosystem offers. Edit: > No guarantees of future support but we will try hard to add support.
- jms55 2y agoAs someone from the rendering side of GPU stuff, what exactly is the point of ROCm/CUDA? We already have Vulkan and SPIR-V with vendor extensions as a mostly-portable GPU API, what do these APIs do differently? Furthermore, don't people use PyTorch (and other libraries? I'm not really clear on what ML tooling is like, it feels like there's hundreds of frameworks and I haven't seen any simplified list explaining the differences. I would love a TLDR for this) and not ROCm/CUDA directly anyways? So the main draw can't be ergonomics, at least.
- currymj 2y agousers mainly use PyTorch and Jax and these days rarely write CUDA code. however separately, installing drivers and the correct CUDA/CuDNN libraries is the responsibility of the user. this is sometimes slightly finicky. with ROCm, the problem is that 1) PyTorch/Jax don't support it very well, for whatever reason which may be partly to do with the quality of ROCm frustrating PyTorch/Jax devs, 2) installing drivers and libraries is a nightmare. it's all poorly documented and constantly broken. 3) hardware support is very spotty and confusing.
- jms55 2y agoPyTorch and Jax, good to know. Why do they have ROCm/CUDA backends in the first place though? Why not just Vulkan?
- RandyOrion 2y agoWhy are people in AMD assuming other people don't want more software support for their GPUs by default? This is not nice.
- suprjami 2y agoBecause they don't have infinite resources like nVidia so they're asking what people want the most to prioritise it. Please read the link before commenting on future. We do that here. This info is is an early comment by an AMD employee.
- RandyOrion 2y agoIt's not nice to assume that people don't read then proceed to comment. I read the link and I upvoted the "just support all GPUs you recently produced" comment. I don't think the solution to bad software support is the prioritization. The prioritization is causing even more discrimination among different GPUs and different customers. You can say whatever you want, and downvote whatever you want. However, that doesn't solve the real problem.
- nsriv 2y agoReally hoping for support for an AMD Radeon Pro W5700 I have kicking around.
- nicman23 2y agoi really need amd to make an apu with eight channels and ddr5
- zoobab 2y agoLatest AMD miniPCs APUs have DDR5 memory (up to 96GB). Don't know about the channels. But this APU hack might work: https://blog.machinezoo.com/Running_Ollama_on_AMD_iGPU https://blog.machinezoo.com/Running_Ollama_on_AMD_iGPU https://github.com/ollama/ollama/pull/6282 https://github.com/ollama/ollama/pull/6282 Linux since 6.1 made some changes to allocate the memory to the GPU from userspace, but it seems the GTT method has degrated performance even more.
- nicman23 2y agothey are very limited by bandwidth :/ that is why i want 8 channels
- sorenjan 2y agoROCm is a mistake. It's fundamentally broken by compiling to hardware specific code instead of CUDA's RTX, so it will always be plagued with this issue of not supporting all cards, and even if a certain GPU is supported today they can stop supporting it next version. It has happened, it will continue happen. It's also a strange value proposition. If I'm a programmer in some super computer facility and my boss has bought a new CDNA based computer, fine, I'll write AMD specific code for it. Otherwise why should I? If I want to write proprietary GPU code I'll probably use the de facto industry standard from the industry giant and pick CUDA. AMD could be collaborating with Intel and a myriad of other companies and organizations and focus on a good open cross platform GPU programming platform. I don't want to have to think about who makes my GPU! I recently switched from an Intel CPU to an AMD, obviously to problem. If I had to get new software written for AMD processors I would have just bought a new Intel, even though AMD are leading in performance at the moment. Even Windows on ARM seems to work ok, because most things aren't written in x86 assembly anymore. Get behind SYCL, stop with the platform specific compilation nonsense, and start supporting consumer GPUs on Windows. If you provide a good base the rest of the software community will build on top. This should have been done ten years ago.
- frognumber 2y agoAgreed. Honestly, the problem isn't just which devices, but even more so, this (from the page, not your comment): > No guarantees of future support but we will try hard to add support. During the Great GPU Shortage, I bought an AMD RX5xx card for ML work. It was explicitly advertised to work with ROCm. Within a couple of months, AMD dropped ROCm support. EOLing an actively-sold product from being used for an advertised purpose within the warranty period was, if I understand consumer protection laws in my state correctly, fraud. There was no support from either the card vendor (MSI). No support from AMD. No support from the reseller. Short of small claims, which was not worth it, there was no recourse. This is on a long list of issues AMD needs to sort out to be a credible player in this space: * Those are the kinds of experiences which cause people to drop a vendor and not look back. AMD needs to either support cards forever, or at the very least, have an advertised expiration date (like Chromebooks and Android phones). * Broad support is helpful from a consumer perspective from the simply pragmatic point of view that only a tiny fraction of the population has the time to read online forums, footnotes, or fine print. People should be able to buy a card on Amazon, at Best Buy, and Microcenter, and expect things to Just Work. * Being able to plan is essential for enterprise use. I can't build a system around AMD if AMD might stop supporting their platform on 0 days notice, and the next day, there might be a security exploit which requires a version bump. I'm hoping Intel gets their act together here, since NVidia needs a credible competitor. I've given up on AMD.
- wkat4242 2y agoThey should just support all cards. Just like Nvidia does. And they drop support too quickly too. The Radeon Pro VII is already out of support. It's barely 5 years since release. This way it will never be a counterpart to CUDA.
- criticalfault 2y agoA lot of people think rocm is basically a big pile of crap. What are the chances for amd to consider alternatives: - adopt oneapi and try to fight Nvidia together with intel - Vulkan and implement pytorch backend - sycl