Radeon's ROCm 5.1 Released With CRIU Support, More RDNA Enablement

[boxerab]

Our main focus for OpenCL on Polaris uses the Orca back end. If you install the packaged drivers using --usecase=opencl and --opencl=legacy that should add Orca-based OpenCL on top of your existing driver stack.

Thanks - ROCm pre-4.5 did support Polaris boards for OpenCL. 4.5 removed support without warning. It would have been good to communicate these changes to the community, and also provide some sort of rationale for why ROCm dropped support.

[david-nk]

That is good news, although with current GPU prices I can't afford to buy a RDNA2 GPU without a guarantee that ROCm actually works now.
My last experience about 2 years ago was not very good to say the least. The only thing that worked well was ResNet50 (but even some custom ResNet variants did not), pretty much everything else either lead to internal errors in MIOpen or non-deterministic computation errors during inference and/or back-propagation, randomly leading to exploding gradients during training. Though, one good thing about ROCm compared to CUDA seems to be its memory management, it can handle much bigger nets with the same amount of VRAM.
I'm going to wait until I've heard reports of other users.

[oleid]

Thanks - ROCm pre-4.5 did support Polaris boards for OpenCL. 4.5 removed support without warning. It would have been good to communicate these changes to the community, and also provide some sort of rationale for why ROCm dropped support.

Is it only OpenCL support or ROCm support in general?

Also just wondering: what do you use OpenCL for?

[oleid]

That is good news, although with current GPU prices I can't afford to buy a RDNA2 GPU without a guarantee that ROCm actually works now.
My last experience about 2 years ago was not very good to say the least. The only thing that worked well was ResNet50 (but even some custom ResNet variants did not), pretty much everything else either lead to internal errors in MIOpen or non-deterministic computation errors during inference and/or back-propagation, randomly leading to exploding gradients during training. Though, one good thing about ROCm compared to CUDA seems to be its memory management, it can handle much bigger nets with the same amount of VRAM.
I'm going to wait until I've heard reports of other users.

Isn't ROCm mainlined to torch these days?
So I'd figure chances are good that it works fine.

[boxerab]

Is it only OpenCL support or ROCm support in general?

I'm only interested in OpenCL support

Also just wondering: what do you use OpenCL for?

I wrote a codec in OpenCL targeting GCN architecture : Polaris had an impressive amount of compute per dollar

[LumielGR]

I've pushed a couple of hours ago latest opencl-amd and opencl-amd-dev for OpenCL / HIP support for Arch Linux, any feedback is welcome.

[ping-wu]

If you just want opencl support, only installing the "rocm-opencl" debian package works very well on unsupported Ubuntu/Debian versions IMHO. Very few dependencies.

Thanks a whole lot for the info.

[Meteorhead]

Our main focus for OpenCL on Polaris uses the Orca back end. If you install the packaged drivers using --usecase=opencl and --opencl=legacy that should add Orca-based OpenCL on top of your existing driver stack.

That would be nice indeed, but when a student of mine asked for my help with his RX 570, I tried badly and could not get it working. (I can't recall if things crashed right at clinfo or when I tried interop, but it didn't fly. I was trying all types of install on my RX 580 box running Ubuntu. I mainly boot my Windows install on the same machine.) The solution was a custom build of ROCm.

I recently had to report a missing built-in from the device libraries on Windows using OpenCL. I know, it's gfx803, but mind you on this OS that is still prime-time supported HW. gfx802 Tonga has legacy driver support, but not gfx803. I don't know if it's a random but or the lack of testing on ROCm is creeping into Windows.

Regarding the news item at hand, I think ROCm just forced itself into an even tighter corner. The fact that all references to "partial support" (whatever that means) on consumer HW was removed means that ROCm for all intents and purposes became a datacenter-only solution. MI50/100/200 cards are as if they were ASICs, target HW end-users never meet. But what's troubling is that the entire driver stack focuses on serving these purposes only. You can't develop HIP on just about anything. Neither can you develop OpenCL, because even if you buy a top of the line Radeon 6800M laptop, Navi 22 to my best knowledge won't even budge under ROCm and there's no mobile pro HW either. PAL port of HIP's been arriving for... as long as HIP has existed. I wouldn't hold my breath for it to release next to Blender's HIP support either. Of course nobody knows if HIP on Windows will be similarly W6800 only or something more.

I'll likely be pulling HIP from the university curriculum, as no student is able to run HIP code on their devices, Windows & Linux alike. The university doesn't have MI100s lying around and it's becoming harder and harder to justify the time investment of fixing driver/runtime issues. And the lack of support on consumer HW is causing pain to OpenCL devs as well.

Trying to strike a less ranting tone: not that the general tone of the Phoronix forums, or this very post is anything to go by (well, definitely not near Microsoft-related news items), but I can't recall a single time when a ROCm release has received positive feedback. It's almost always people (like myself) sobbing over not having access to anything which runs anything ROCm. Maybe it's not consumer news, really. It's enterprise. It's nothing to get excited about. Maybe that's more a comment to Michael than Bridgman or AMD.

[boxerab]

I'll likely be pulling HIP from the university curriculum, as no student is able to run HIP code on their devices, Windows & Linux alike. The university doesn't have MI100s lying around and it's becoming harder and harder to justify the time investment of fixing driver/runtime issues. And the lack of support on consumer HW is causing pain to OpenCL devs as well.

.

I have to agree - the latest ROCm releases have been very disappointing for owners of consumer-grade cards. The current dominant player - nvidia + CUDA - runs on all nvidia hardware, going back ~10 years, on windows + Linux. AMD no longer has the excuse of teetering on the edge of bankruptcy - they are doing very well and can afford to put more effort into supporting compute on consumer cards.

[coder]

Our main focus for OpenCL on Polaris uses the Orca back end. If you install the packaged drivers using --usecase=opencl and --opencl=legacy that should add Orca-based OpenCL on top of your existing driver stack.

I don't want to beat up on you, because I appreciate how you take time out of your busy schedule to post on here & answer questions. However, it needs to be pointed out that for software developers who don't want a big support burden to embrace ROCm, it needs to work on installs as vanilla as possible.

With Nvidia, a user typically has to add their repo and manually install their driver packages. It'd be awesome if the out-of-the-box experience for AMD hardware <= 5 years old was to just work. And that should go for APUs, as well.

Now, I get that Polaris is at the edge of that 5-year window, but the RX 590 was only launched in Nov 2018, putting it at about 3.5 years. And lots of people are still running Polaris HW, due to the GPU shortage that's stretched back to the point when most of them would've contemplated upgrades.

So, I guess if AMD cares about supporting mainstream GPU compute, then try to stay mindful that app developers don't want to walk users through a detailed install & configuration procedure (especially one which needs continual updating).