• Welcome to TechPowerUp Forums, Guest! Please check out our forum guidelines for info related to our community.

AMD ROCm 4.5 Drops "Polaris" Architecture Support

It seems AMD wants to get rid of GCN support, so to get people to move to RDNA.

CDNA is GCN actually. And ROCm doesn't support RDNA yet.

Honestly, the problem is that GPUs assembly languages keep changing. NVidia solved this problem by inventing PTX, a recompilable, portable assembly language that recompiles every time a new GPU comes out.

Intel solves this problem on the SIMD-side by simply always supporting older assembly language statements. Intel CPUs still boot in realmode IIRC (8086 compatible), and have a complicated bootup process to enable 16-bit 80286, then 32-bit 80386, and finally 64-bit modes.

-----------

I don't know if this is really that big a deal IMO. ROCm 4.5 will continue to work for the Polaris 580x. Your code will continue to run as written. In fact, most people on Polaris saw a bug on ROCm 3.8+, so I'm pretty sure most Polaris-users were sticking with ROCm 3.3 instead. "Officially" cutting support on 4.5 isn't a big deal since most ROCm / Polaris users are already just staying on 3.3 ya know?
 
Well CUDA is faster and better in the sense that practically any old card has it, so AMD can go take a long walk off a short pier.
 
Oh ROCm is still going?
Only way to get accelerated OpenCL on linux that I know of.

There's like one Polaris based compute card, which probably wasn't even that successful, this isn't exactly a tragedy.
Games use compute too. ROCm is needed for compute on linux, IIRC.
 
Only way to get accelerated OpenCL on linux that I know of.


Games use compute too. ROCm is needed for compute on linux, IIRC.
On Polaris and older, AMDGPU drivers will get you OpenCL. Vega and newer require ROCm, or at least AMDGPU drivers won’t get it for you.
 
A terrible decision on AMD's part, if you ask me. One of the reasons why Nvidia managed to build such fervent fanbase loyalty is the fact that they support their hardware and it's features for a very long time, as this news post writes. If they want people to move from GCN to RDNA, they need to build their product perception and make sure people are happy with existing products. The main reason why I use AMD GPUs is Linux. Nvidia just doesn't care about Linux enough for me to bother with their cards on Manjaro. But if I needed HPC computing I'd seriously consider CUDA and Nvidia just because of stuff like this. In enterprise space, trust is everything.
 
A terrible decision on AMD's part, if you ask me. One of the reasons why Nvidia managed to build such fervent fanbase loyalty is the fact that they support their hardware and it's features for a very long time, as this news post writes. If they want people to move from GCN to RDNA, they need to build their product perception and make sure people are happy with existing products. The main reason why I use AMD GPUs is Linux. Nvidia just doesn't care about Linux enough for me to bother with their cards on Manjaro. But if I needed HPC computing I'd seriously consider CUDA and Nvidia just because of stuff like this. In enterprise space, trust is everything.
More important than the fanbase, Nvidia has secured the professional stage. For every OpenCL or oneAPI application out there, there are probably 10 CUDA apps. Beyond our own preferences, that translates into revenue.

We'll probably get a decent open API for number crunching some day, but for the time being that's an uphill battle.
 
What are you talking about ? Polaris was released with support for OpenCL, which it continues to have, there is no "dropping GPU-accelerated computing support".
Which is not available on every Linux distro because AMD offers AMDGPU-PRO only for a very limited (three) number of distros. But I guess that nowdays AMD fanboys are like a cult, they just can't see when AMD does something wrong. They can kill support with no warning whatsoever and it's all fine and dandy.
 
I dunno, until we get actual confirmation, this sounds like a bug. From the GitHub readme:
1636682128457.png
 
Unlike before in the passed the newer driver do a check and will not install at all, used to be a time you could still update the software but not any more but this is going back some time.

Funny how shit works when they have your money.
 
Games use compute too. ROCm is needed for compute on linux, IIRC.
Games use compute shaders, you don't need ROCm support for that. So again, utterly irrelevant to consumers.

Which is not available on every Linux distro because AMD offers AMDGPU-PRO only for a very limited (three) number of distros.
AMD has no obligation to support a trillion Linux distros, neither does Nvidia. By the way you can continue to use the latest supported version with Polaris based cards, it's not like you expect new features and improvements from a 5 year old architecture, do you ?

And finally, ROCm was (still is in my opinion) a fairly experimental platform, expecting perfect and indefinite support from it is insane.

NVidia solved this problem by inventing PTX, a recompilable, portable assembly language that recompiles every time a new GPU comes out.

And their ISA is proprietary and undisclosed, which means only Nvidia can optimize something to the utmost level, creating a false impression that CUDA libraries made by them are faster because CUDA is faster.
 
Last edited:
Games use compute shaders, you don't need ROCm support for that. So again, utterly irrelevant to consumers.
It's not universally used, but it's far from "utterly irrelevant". Video and photo editors, even office suites (Open/LibreOffice iirc) use compute where available to speed things up.
 
Just FYI, I have not seen any sign that we disabled support.

All indications are that this is a bug which slipped in while we were reworking the build/packaging/install logic for 4.5 as part of unifying the ROCm and AMDGPU-PRO stacks.
 
Just FYI, I have not seen any sign that we disabled support.

All indications are that this is a bug which slipped in while we were reworking the build/packaging/install logic for 4.5 as part of unifying the ROCm and AMDGPU-PRO stacks.
Solid delivery process you got there :toast:
 
Solid delivery process you got there :toast:
What is wrong with it? If something is not officially supported, they don't do testing for it. Why should they? The process would be bad if GFX9 compatibility would be dropped and they wouldn't notice it ...
 
What is wrong with it? If something is not officially supported, they don't do testing for it. Why should they? The process would be bad if GFX9 compatibility would be dropped and they wouldn't notice it ...
Nothing wrong with losing an entire feature on the way :wtf:
 
Look at me talking about stuff I don't understand. I was just thinking it is.

I think you're right in general. I'd bet that AMD's plan is to move onto RDNA eventually (even their compute stack).

But CDNA seems like a "temporary" measure to me. Its an extension to the venerable GCN language, including some pretty nifty tricks (Tensors, Matrix Multiplication). But RDNA has other tricks (Raytracing) that the GPGPU crowd wants (aka: Visual Effects are slowly moving to GPU-raytracing for test footage... and maybe shorts, tv-shows and movies if the technology matures a bit more).

I'd have to imagine that the future is on RDNA. But I've been wrong in predicting the direction of AMD before.
 
I don’t get it folks. All signs point to a bug, not something being taken away. If you’ve ever used Linux, or any other complex software, it’s just the nature of the beast.
It's not universally used, but it's far from "utterly irrelevant". Video and photo editors, even office suites (Open/LibreOffice iirc) use compute where available to speed things up.
Darktable is another. It can really help substantially on some modules if you have a relatively powerful GPU (good memory bandwidth).
Just FYI, I have not seen any sign that we disabled support.

All indications are that this is a bug which slipped in while we were reworking the build/packaging/install logic for 4.5 as part of unifying the ROCm and AMDGPU-PRO stacks.
Thanks for the clarification. Are both going to remain developed in parallel, or are you headed to one path to install compute support?
 
Games use compute shaders, you don't need ROCm support for that. So again, utterly irrelevant to consumers.
I suppose I'd agree if you changed that to "gamers." But there are consumers that care about compute.
 
I don’t get it folks. All signs point to a bug, not something being taken away. If you’ve ever used Linux, or any other complex software, it’s just the nature of the beast.

I mean, the "bug" was from several versions ago. Again: anyone still using Polaris is stuck on like ROCm 3.3 and has been for at least a year now. If anything, this is just making publicly known what users have already known about ROCm moving forward: Polaris is not a platform AMD is planning to support seriously moving forward (code might still work as CDNA shares a lot of code with GCN 4.0 aka Polaris, but its on an unofficial basis)

ROCm 4.5 is saying that Vega10 support is being dropped soon.
 
1636746960214.png

RDNA is supported, Polaris has had limited support for some time and the current 4.5 install guide does not even list it.
Using the ROCk driver is with ROCm-openCL is not the same as being fully compatible with the framework and deep learning.

If you need OpenCL support... Just install the ROCm-OpenCL And make a sym link to bin for OpenCL as for some reason it doesn't do it (note in 4.4, not tried 4.5 yet)


AMD support will get better, but the documentation and current support is pretty frustrating. They have $200M from Frontier and El Capitan dedicated to software development.
 
Back
Top