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

[LumielGR]

If Hashcat doesn´t work, MIOpen probably won´t as well, as MIOpen uses the same primitives probably used by HashCat (if it uses HIP / ROCM and not OpenCL)

Hashcat has been fixed some weeks ago - Blender is still broken for RDNA 1 but works for 6700xt. I'm not sure about MIOpen.

[Spacefish]

Can you give me an example on how to test MIOpen? At this point everything I have tried that uses my AMD GPU (Hashcat HIP, Blender, AMF) is not working, but I won't give up that easily

If Hashcat doesn´t work, MIOpen probably won´t as well, as MIOpen uses the same primitives probably used by HashCat (if it uses HIP / ROCM and not OpenCL)

[qarium]

Why not use Vega64? Well, maybe because it's been EOL for years now and you can't buy them. You can't even buy them used, the demand is so high they sell for 6800 XT prices on the used market.

well unlike the polaris topic thats a problem...

[LumielGR]

Yeay MIOpen on RDNA / gfx1010
Will check it out tommorow first thing in the morning. Have been waiting for this since forever.
Thanks a lot AMD!

Can you give me an example on how to test MIOpen? At this point everything I have tried that uses my AMD GPU (Hashcat HIP, Blender, AMF) is not working, but I won't give up that easily

[Meteorhead]

why not just use vega64 for the ROCm task ? Polaris for high performance compute is pain and simple to old.
you act like you need a MI50/100/20..,. but vega64/radeon7/vega56 and so on is also supported.

I had a RX 570 to with only 4GB vram... this GPU does not work for compute at all because vram is to low for any serious task.
even for ethereum mining you need a 6-87gb vram card.

Why not use Vega64? Well, maybe because it's been EOL for years now and you can't buy them. You can't even buy them used, the demand is so high they sell for 6800 XT prices on the used market.

[Spacefish]

Yeay MIOpen on RDNA / gfx1010
Will check it out tommorow first thing in the morning. Have been waiting for this since forever.
Thanks a lot AMD!

Had compiled MIOpen with gfx1010 support back then (ROCm 4.x), but things like the winograd convolution kernel where still missing for RDNA(2).

[qarium]

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.

why not just use vega64 for the ROCm task ? Polaris for high performance compute is pain and simple to old.
you act like you need a MI50/100/20..,. but vega64/radeon7/vega56 and so on is also supported.

I had a RX 570 to with only 4GB vram... this GPU does not work for compute at all because vram is to low for any serious task.
even for ethereum mining you need a 6-87gb vram card.

[Meteorhead]

I was referring to the bottom if this page: https://docs.amd.com/bundle/ROCm-Rel..._Document.html

And the GitHub landing page. Neither mention anything other than the pro cards.

[bridgman]

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.

This doesn't sound right - when I went through the most recent release notes I saw more consumer support than before. I thought there had been mention in 4.5 release notes about deprecating some Vega parts but when I looked in 5.1 release notes all of the consumer support seemed to be back.

https://docs.amd.com/bundle/Hardware...e_Support.html

Where did you see the statement about "removing references to partial support for consumer HW" ?

[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).