AMD Instinct MI300X Accelerators
amd.com
amd.com
(Note: I know they never will. This story, multiplied by the number of people building stuff now, is why I'm bearish on AMD and bullish on competitors. This would be a very nice card -- 192GB is sexy -- but I just get headaches thinking about compatibility, software, and drivers issues. To quote Steve Balmer, what AMD is missing is: "Developers, developers, developers." That's not a small hole to dig out of.)
"Bug fixes / critical security patches will continue to be supported for the gfx906 GPUs till Q2 2024"
Worse, a lot of tooling will break before then. If you need a security patch for anything built on top of ROCm or CUDA, you often can't have an ancient version.
That's not to mention that I'd like to do new development and prototyping.
I don't do business with AMD for the same reason I don't do business with Google. They're not a reliable partner.
Some very spectacular compromises by Lapsus$ aren’t originating from any of the above, but instead from the West, specifically the UK:
The difference, however, is that, in this case, as the article points out, the bad actor is in custody.
My local law enforcement, lawyer, and judicial system are able to help out with the bad actors here and keep the problem somewhat contained.
For a bad actor in Russia or India, you quite literally have no recourse. There are literally Youtube videos (Mark Rober did a special recently) showing out-of-jurisdiction scammer and hacker shops occupying entire office buildings, and there is almost nothing we can do about it.
I'm not even going to go on a diatribe about corruption and the quality of law enforcement, since one can have different opinions. What I will point out is that US+EU have extensive treaties which allow my local law enforcement agency to cooperate closely with law enforcement agencies between US, UK, and EU.
For a bad actor in Iran or North Korea? You're not even getting diplomatic contact.
Footnote: I mention India since they're a democracy and by all standards, try to act responsibly on the global stage. They just don't happen to be in-network for various US/EU-centric international conventions.
The tooling for older MI25 cards has yet to break, please avoid creating FUD on hardware you don't own.
Bought in 2020. Stopped working in 2020. Not the latest, but in-production, advertised ROCm-capable, and what I could find during the Great GPU Shortage of 2020.
That's pretty fucked. :(
Order of operations:
1. It just silently stopped working, started crashing, and I had no idea what was going on or why. Just sort of intermittent f-age where some older versions would work better, and newer ones would work worse. I never got it reliably working. In most cases, at some point, the system would become unresponsive, and then crash hard.
2. AMD removed it from the supported list (with no notice).
3. The github ticket above was filed, which explained what was going on.
Lots of time wasted debugging. This interacted with a half-dozen other AMD bugs and issues (such as learning the GPU only worked for compute headless; I needed to drive my monitor with a different card).
Human time is more expensive than equipment, so the total cost of this stuff was astronomical.
Yes, notice is industry-standard, but at the very least, when support broke / was later removed, the driver could try warning me "We no longer support this card, do you REALLY want to proceed?" rather than letting me know by hard-crashing my system.
AMD means something like "your engineers can raise jira tickets related to the supercomputer you bought". The general idea outside of that context seems to be "support" means "can run stuff on the GPU". There's some analogy to games dev - if call of duty doesn't run on an amdgpu, you also don't get to complain to AMD about it, but the games studio certainly will do. The games studio is the entity with the contact details.
ROCm is fairly likely to run on unsupported consumer cards if you build the libraries from source or use them from someone who did, which is just about viable from linux distributions now. You don't get to raise official jira tickets about it when it falls over because it's "unsupported". You'll have a moderately bad time if you ignore the docs recommendations about the kernel version for a given release, or if the difficult task of building the libraries from source goes awry.
The established packaging idea of only shipping machine code libraries for a subset of the GPUs you sell, and giving very limited information on how to make those libraries exist for other GPUs, is obviously making essentially everyone very pissed off with AMD. Their engineers are aware of that and disagree about what to do about it.
I personally think that'll resolve itself once Debian packaging is generally usable. People will install ROCm from their distro instead of from the official builds which don't have machine code for gaming GPUs anyway. That will give rise to new annoyances but at least the applications will try to run on whatever GPU you've got locally.
https://rocm.docs.amd.com/projects/radeon/en/latest/docs/com...
I bought my (in-production, advertised ROCm-capable) card during the great GPU shortage of 2020, and literally anything new stopped working a few months later when AMD decided to update ROCm to drop support for GFX8 GPUs:
https://github.com/ROCm/ROCm/issues/1353
All the packages I was using (like Spacy) required later ROCm almost immediately. There was literally no way to make them work. Running older packages is a non-starter if you want things like, say, your machines to not be compromised.
> if call of duty doesn't run on an amdgpu, you also don't get to complain to AMD about it, but the games studio certainly will do
If "Call of Duty" is advertised on the box, and doesn't run, yes, this is false advertising, and "consumers" get to complain to the graphics card maker or AMD. In this case, small claims court would give me a refund if I sued AMD; an advertised ROCm-compatible GPU stopped being ROCm-compatible within the warranty period. It's just not worth complaining or suing over a few hundred bucks.
I didn't need much performance, and this was purely for dev -- to make sure I bought this purely so I could have compatibility with AMD. AMD decided to not have compatibility with me, and I said f--k AMD.
The result is that if you want to run my data pipeline, it won't work on AMD. A major industry will hopefully standardize on it, and guess who is locked out of selling any GPUs to that industry if that happens?
I don't know what plays into which GPUs are listed as supported on which versions of ROCm. I'm sure my 6800GT was marked "supported" on some version and isn't on the current one. I think my radeon vii was likewise "supported" on some of them and isn't any more. I used a 5700 XT for a year or so which was never on the blessed list. I obsessively build everything from source instead of using the release binaries though.
That's the option I took.
Now, my software is tied to CUDA. Others are building more on top if it. If people want to run my software (or by proxy, and software which uses my software as a platform), they have more-or-less the same option if they accidentally bought AMD.
So far, I haven't heard from any users who accidentally bought AMD.
Right now, I'm just waiting for Arc A770 support to improve, so I can also support Intel. That will be the cheapest way to run my tools, since you get 16GB for $300.
I'm not the only one who took this path. I'm just more vocal about it.
* Some exclusions apply.
It is frustrating as a consumer - dealing with ROCm on an consumer card was a massive pain for the period I bothered to put in the effort. However, I remain bullish on AMD, I think their current GPUs are their Bulldozer-equivalent; I'm waiting patiently for the AMD GPU Zen-1-moment
To implement your strategy, you either don't ship mass market GPGPU cards, or you stick a big "beta / prototype" label on ROCm and make sure people use it only caveat emptor. I've bought plenty of half-baked things because I wanted to tinker with them or help a company along. AMD cards are very competitive for gaming too, which really brings volume much more so than GPGPU, so there's no reason to oversell.
AMD's problem is that they're claiming these things work, and they don't. I was fortunate to learn that lesson spending a few hundred bucks. I know people who learned that lesson spending thousands. I wouldn't want to figure out on a data center or a supercomputer whether or not the same lesson applies. If a company is willing to cheaply torch relationships as it figures out a strategy, ship half-baked ill-thought-out software, and make bold, unsubstantiated claims, I'll pick another vendor if at all competitive.
AMD is losing mind share, credibility, and branding. That will hurt if they ever have a product ready for the broader market, and it will also hurt (although not as much) with the strategy you described.
Software isn't catching up. For most AMD GPU owners, the software quality is getting worse over time.
How did you reach the conclusion? In almost all the metric, AMD is just 20-30% ahead or wildly behind. e.g. AMD is so much behind in tensor cores in consumer grade GPU or raytracing.