ROCm has not been abandoned. PyTorch is built on top of rocBLAS, rocFFT, and Tensile (among other libraries) which are all under active development. You can watch the commits roll in day-by-day on their public GitHub repositories.
I can't speak about hardware support beyond what's written in the docs, but there are more senior folks at AMD who do comment on future plans (like John Bridgman).
CUDA works with basically any card made in the last 5 years, consumer or compute. ROCm seems to work with a limited set of compute cards only.
There's a ROCm team in Debian [1] trying to push ROCm forward (ROCm being open), but just getting supported hardware alone is already a major roadblock, which stalls the effort, and hence any contributions Debian could give back.
From what I recall, on the software side, I think the difficulties stemmed from ROCm being distributed (naturally, of course) as a vendor would do it, for example: targeting specific kernels, compilers, distribution versions. The problem with this is that all these may become out of date, which means that the GitHub instructions may no longer work for anyone wanting to give it a try. This was the case for some of the team members attempting to rebuild some of the packages.
The Debian team would prefer to package all elements of the ROCm ecosystem and include them in the official Debian archive, so that users can just run `apt-get install rocm-something` without worrying about the kernel version etc., just as they can already do a trivial `apt-get install nvidia-cuda-toolkit`.
I think collaboration with AMD here would be mutually beneficial, as on the one hand, Debian wants FOSS accelerated computing, which AMD is pushing, and on the other hand, Debian is naturally experienced in distributing things for Debian, Ubuntu, etc., something AMD could benefit from.
Thank you for engaging!
I want to buy AMD because they are more open than Nvidia. But Nvidia supports CUDA day one for all their graphic cards and AMD still don't have rocm support on most of their product even years after their release [0]
Given AMD size & budget, the reason why they don't hire a few more employee full time on making rocm work with their own graphic card is beyond me.
The worst is how they keep people in waiting. It's always vague phrases like "not currently", "may be supported in the future", " "future plan", " we cannot comment on specific model support ", etc.
AMD doesn't want rocm on consumer card ? Then say it. Stop making me check rocm repos every week to get always more disappointed.
AMD plans to support it on consumer card ? Then say it and give a release date : "In May 2021 , the RX 6800 will get rocm support, thanks for your patience and your trust in our product".
I like AMD for their openness and support of standards, but they are so unprofessional when it comes to Compute
The reason is that it would take more than a few more employees to provide optimized support across all GPUs. If nothing else, it's a significant testing burden.
The following is my speculation. For what I noticed, Polaris and Vega had a brute force approach; you could throw a workload on them and they would brute force through it. Navi generation is more gamer oriented; it does not have the hardware for the brutal approach, it relies more on optimizations from the software running on it and using it in specific ways. Provides better perfomance for games, but worse compute - and that's why it is not and is not going to be supported by ROCm.
The downside of course is, that you can no longer buy Vega. If I knew it last time it was on sale...
That's not very helpful if we can't use them on our own computers... Not many devs are able to put their hands on a datacentre-class card...
It’s Linux only so no Mac, Windows or WSL.
No support what so ever for APUs which means if you have a laptop without a dedicated GPU you’re out of luck (tho discrete mobile GPUs aren’t officially supported either and often do not work).
They’ve not only haven’t been supporting any of their consumer based R“we promise it’s not GCN this time”DNA GPUs, but since December last year (2020) they’ve dropped support for all pre-Vega GCN cards which means that Polaris (400/500 series) which is not only the most prolific of AMD GPUs that have been released in the past 5 years or so but also the most affordable ones are no longer supported.
That’s on top of all the technical and architectural software issues that plague the framework.
Does WSL not support PCIe passthrough?
And even then, almost all AMD customer GPUs are not supported. (Everything but Vega)
APUs? Nope too.
> It’s Linux only so no Mac, Windows or WSL.
I don't see really a problem here. You want Office or Photoshop? It runs on Mac and Windows only, so you better get one. You want ROCm? Get Linux for exactly the same reason.
Keep in mind that not only is it Linux only, it doesn't work on consumer hardware either.
So ship linux version and let the customers decide whether they want it or not.
If you are doing server product, it is even handy; just ship docker image or docker-compose/set of k8s pods, if it needs them.
> or if you want to do some GPU programming on your own computer in your free time.
You can install Linux very easily; it's not that it is some huge expense.
> it doesn't work on consumer hardware either.
It does, just not on the current gen one or even currently purchasable one. I agree, this is a problem.
What if I want to use GPGPU in Photoshop, or a game with more than two users? Or really anything aimed at consumers?
> If you are doing server product
That's irrelevant, server products can choose their own hardware and OS.
> You can install Linux very easily
"For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem"
Also, their main competitor with a huge market lead have this: https://docs.nvidia.com/cuda/cuda-installation-guide-microso...
> It does, just not on the current gen one or even currently purchasable one. I agree, this is a problem.
Only on old hardware, and you can't expect users' computers to be compatible. In fact, you should expect users' copmuters to be incompatible. That's like saying consumer hardware support GLIDE.
Then use API supported on your target platform. It's not ROCm then. Maybe Vulcan Compute/DirectCompute/Metal Compute?
> That's irrelevant, server products can choose their own hardware and OS.
It is relevant for ROCm.
> > You can install Linux very easily
> "For a Linux user, you can already build such a system yourself quite trivially by getting an FTP account, mounting it locally with curlftpfs, and then using SVN or CVS on the mounted filesystem"
I'm quite surprised to see comparisons ad absurdum after suggesting to use proper tool for a job. Installing a suitable operating system - for a supposed hacker - is a convoluted, nonsensical action nowadays?
> Only on old hardware, and you can't expect users' computers to be compatible. In fact, you should expect users' copmuters to be incompatible. That's like saying consumer hardware support GLIDE.
Vega is not that old; the problem is that is not not procurable anymore, which, if you read my comment again, I agreed that it is a problem.
Why should Linux platform give up its competitive advantages against others? It would only diminish the reasons for running it. The other platforms won't do the same -- and nobody is bothered by that. In fact, it is generally considered to be an advantage of platform and reasons for getting it.
And it's not like getting Linux to run could be a significant expense (like purchasing an Apple computer is for many) or you need to get a license (like getting Windows). You can do it for free, and you will only learn something from it.
I've got my nix chops in the early '90 exactly this way: I wanted 32-bit flat-memory C compiler, didn't have the money for Watcom and associated DOS-extenders and djgpp wasn't a thing yet (or I didn't know about it yet). So I've got Slackware at home, as well as access to DG-UX at uni. It was different, I had to learn something, but ultimately, I'm glad I did.
It provides no competitive advantage to Linux, not to mention that that entire concept is a bitty laughable as far as FOSS/OS goes.
I don’t understand why AMD seems adamant at not wanting to be a player in the GPU compute market.
Close to Metal was aborted.
OpenCL was abandoned.
HSA never got off the ground.
ROCm made every technical decision possible to ensure it won’t be adopted.
Can’t get GPUs that could run it, can’t ship a product to customers because good luck buying the datacenter GPUs from AMD the MI100 is unavailable for purchase unless you make a special order and even then apparently AMD doesn’t want anyone to actually buy it, can’t really find GPU cloud instances that run it on any of the major providers.
So what exactly is it? It’s been 5 years and if you want today to develop anything on the platform you have to build a desktop computer, find overpriced hardware on the second hand market pay a premium for it, hope that AMD won’t deprecate it within months like they did with GCN 2/3 without even a heads up notice all so you can develop something that only you can run with no future compatibility or interoperability.
If this is the right tool for the job then the job is wrong.
About DirectCompute, C++ AMP is in practice dead on Windows, stuck at a DX11 feature level with no significant updates since 2012-13, staying present just for backwards compatibility.
That's the point, ROCm isn't suitable for things outside datacenters or maybe some workstations. Cuda is however, and that's what AMD should be aiming for. Their best bet is SYCL, but that uses ROCm as backend...
> Installing a suitable operating system - for a supposed hacker - is a convoluted, nonsensical action nowadays?
Again, if all you need is to run ROCm on your own computer Linux isn't a hurdle. If you want to ship software to customers you can't just say "switch OS", they're probably already using their computers for other things.
> Vega is not that old; the problem is that is not not procurable anymore, which, if you read my comment again, I agreed that it is a problem.
The fact that they used to support something isn't a relevant argument and I just don't see the point in bringing it up, other than to underline the fact that AMD doesn't care about compute support for the mass market anymore. At least we agree on one thing.
The splitting between graphics specific and compute specific hardware is an even bigger issue than Linux only. ROCm stands for RadeonOpenCompute, and their Radeon DNA hardware can't run it, so streamers can't use AMD hardware to play games and improve their mic sound, while it's trivial to do with Nvidias OptiX. And what good are all the ML models if you can't ship them to customers?
Every decision AMD made with ROCm seems to boil down too “i never want to be actually competitive with CUDA”.
Everything from being Linux only and yes that’s is a huge huge huge limitation because most people don’t want ROCm but many would like Photoshop or Premier or Blender being able to use it. Especially with the OpenCL issues AMD has....
Through them not supporting their own hardware to other mind boggling decisions like the fact that ROCm binaries are hardware specific so you have no guarantee of interoperability and worse no guarantee for future compatibility and in fact it does break.
The point is that I can take a 6 years old CUDA binary and run it today still on everything form an embedded system through a high end server, it would maintain its compatibility across multiple generations of GPU hardware, multi operating systems and multiple CPU architectures.
And if you can’t understand why that is not only valuable but more or less mandatory for every GPGPU application you would ever ship to customers, perhaps you should stick to photoshop.
AMD is a joke in this space and they are very much actively continuing in making themselves one with every decision they make.
It’s not that they’ve abandoned ROCm is that it’s entire existence is telegraphing “Don't take use seriously, because we don’t”.
It would be very nice for them to refresh their compute cards as well.
With the price to match for those...
Good luck getting an instinct card.
AMD meanwhile considers GPU compute as a premium feature... which is a different approach.
Not having a shippable IR like PTX but explicitly targeting a given GPU ISA, making this unshippable outside of HPC and supporting Linux only also points in that direction.
Intel will end up being a much better option than AMD for GPU compute once they ship dGPUs... in their first gen.
AMD doesn't seem to want to be part of future computer usages, it's a shame. "Armies prepare to fight their last war, rather than their next war".
Example: I bought a 16GB Radeon VII for €550 (including 19% VAT). That would be a decent value proposition for Deep Learning even today. However, the card appears to trade second hand(!) for €1300+ on e-bay, because you apparently can run 90-100 MH/sec or so (this is an estimate I found on the web, I don't engage in this type of thing). As a result, you would not be able to get consumer Vega with these performance characteristics for a good price even if AMD produced them.