Radeon ROCm Updates Documentation Reinforcing Focus On Headless, Non-GUI Workloads

[bridgman]

In reality it doesn't. Radeon R9 380, Radeon RX 5600, RX 5700 XT and an AMD Ryzen 5 4500U on Kernel 5.9, 5.10, 5.11 (on Arch Linux) suffer from the same thing. shortly after the OpenCL app is started to do compute work (F@H, Blender(cycles and radeon pro-render), sometimes even clinfo), the graphicscard seems to reset itself and the screen freezes. That's it. OpenSource ROCm stack that you build from the sources available is not usable at all for a desktop-users POV.

Sorry, what I was trying to say was that if you need a working (graphics plus compute) stack you can combine a working compute stack with a working graphics stack. I was not suggesting that if your hardware is not supported by the ROCM stack on its own that adding graphics components will change the compute behaviour.

Most of the devices you listed are not supported in the ROCm stack today. The R9 380 (Tonga) was launched before the HSA/ROCm stack was developed and AFAIK does not quite have the HW required to run the ROCm code paths. The legacy OpenCL code paths are still being maintained for your hardware, however.

RDNA parts are not supported in the current ROCm stack releases, although we have done a lot of work on 5600XT/5700XT up to OpenCL which will appear in upcoming ROCm stack releases, so you should be OK there. I don't have a timetable for support further up the stack but that is being worked on.

I would have expected the Ryzen 5 4500U to be supported, although I recommend you start with a supported distro kernel and install the dkms driver for initial testing. That is the combination we do our testing with. Sufficiently new upstream kernels will usually work with their built-in drivers (ie without the dkms driver) as well, but what we currently test is the userspace+dkms combination.

[coder]

The real problem is the message this sends out to the entire software development community "AMD doesn't care about consumer compute".

This. AMD's GPU-compute business really can't afford to lose any more developer mind-share.

Though widely-ridiculed for this pathetic act of supplication, I think at least Steve "Monkey Boy" Ballmer at least had the right idea:

Virtually every developer starts out as a kid with consumer hardware. Even as adults, that's what we use at home, if not also at work. Students are using mostly consumer hardware, and a lot of times they'll base their decisions on what hardware to support in their FOSS projects on whatever they're already using (or is easily/cheaply available). I'm pretty sure that's how Nvidia gained such a strong, early lead in machine learning (and then they went out of their way to cultivate it, further).

So, if AMD is content to have some HPC wins and maybe a few big machine learning customers, then fine for them. If not, then they should've learned by now that they can't afford to neglect the grass roots! In fact, it's literally their biggest potential advantage in competing with machine learning ASICs. Because, how many developers have dedicated machine learning ASICs (or are going to jump through hoops just to access them on some dedicated cloud service)? But everyone has a GPU!

[bridgman]

Is it possible, that at least then just now this time you guys could check up on Resolve/Blender and tell the devs what are they doing wrong, or how they should approach the components so the applications are working as they are supposed to? So at least both side could win in this situation?

We have Blender working pretty well (as far as I know) on the ROCm OpenCL code used in the 20.45 AMDGPU-PRO driver now, and those fixes should appear in regular ROCm releases soon. The ROCm releases and graphics releases have different branching models so it's not as quick as I would like.

I am trying to get Resolve on the list of apps that get regularly tested and fixed - we will need to get a dev taking a look at it.

[bridgman]

I am a bit confused with this news. In a recent article here it was mentioned that RDNA2 cards have support for Rocm 4.0 with the included linux driver: https://www.phoronix.com/scan.php?pa...0-opencl&num=1

<snip>

But now I am confused, is the Rocm supported on RDNA2 cards or not??

We did a lot of testing & fixing on the ROCm stack code for RDNA1 and RDNA2, but those fixes have not yet been picked up in the regular ROCm releases. So "yes" for the code in the 20.45 driver (at least up to OpenCL) but "not yet" for the code in the ROCm stack releases.

[coder]

Also, I don't mean to beat up on bridgman . I think he gets it, but the issue seems to be a couple levels above him, at AMD. They should be trying to do developer outreach and evangelism, in addition to making more engineering resources available to support non-professional compute users.

[bridgman]

I had already written a message which sounded just like yours. I have to say. Mine was angrier still, so I erased it, but I feel exactly like you do. I have this Radeon VII, i'm tired of watching it glow red while its 14 teraflops go unused. I get more Gflops out of my Jetson Nano! I'm thinking of selling the RVII, living on a crappy old 1030 card I have lying around until Intel brings their stuff to the party.

I'm very disappointed and my long, long support of AMD has taken a very serious beating.

Just checking, is your current issue the fact that Ubuntu bumped the kernel version in 20.04.1 and we don't have a driver to match it ?

[vegabook]

Just checking, is your current issue the fact that Ubuntu bumped the kernel version in 20.04.1 and we don't have a driver to match it ?

Essentially that's what started my list of rants. Upgraded to ROCm 4.0 and kaboom. I'm not a greybeard so recompiling kernels is not my thing (though I'm not a Linux newbie either - I consider myself "in the second quartile" if that makes sense). I just want Torch to work so I can use its GPU-based Numpy-like functionality in my work, and I'd like to have Elixir's new NX library work and for that I need XLA working. Neither will fly without the ROCm stack working as far as I can see. Turns out I also mess with Blender so getting GPU help on that is a bonus though RadeonTOP does seem to show the VII doing something when I render so maybe that's already done. But if you have explicit instructions on getting ROCm working on Fossa 20.04 clean install, much obliged. I'll also consider Fedora if you tell me that its newer kernel does not require the DKMS step. By way of background I am developing GPU-enhanced yield curve optimization algos for retail finance (prefers FP64 but FP32 will do), for wide distribution, so if it works on AMD, you'll have an advocate. The idea is to democratise the closed world of bond trading by pushing out smart algos, up to now only available in banks and hedge funds, to retail investors, and that's why I care about compute at the right price. Otherwise I'd happily ask a fund to pay 10 grand a pop for the top Nvidia stuff.

[coder]

I am developing GPU-enhanced yield curve optimization algos for retail finance (prefers FP64 but FP32 will do), for wide distribution, so if it works on AMD, you'll have an advocate. The idea is to democratise the closed world of bond trading by pushing out smart algos, up to now only available in banks and hedge funds, to retail investors, and that's why I care about compute at the right price. Otherwise I'd happily ask a fund to pay 10 grand a pop for the top Nvidia stuff.

Cool.

BTW, the RX 6800 XT can sustain > 1 TFLOPS of fp64, which is about twice what Nvidia's RTX 3090 will deliver!

[vegabook]

Cool.

BTW, the RX 6800 XT can sustain > 1 TFLOPS of fp64, which is about twice what Nvidia's RTX 3090 will deliver!

Yes cos Nvidia does 1/32 whereas AMD does 1/16. That said, my Radeon VII from 2 years ago does 3.5 teraflops of FP64 (1/4). Still that's not bad at all. Didn't realise that.

[VileLasagna]

Some people alluded to some of this stuff already but in my eyes, the problem with ROCm is mainly twofold:

1 -> Not supporting homegamer type hardware is just really bad. I DO think that yeah, this is how CUDA became a thing. Every kid in uni just had some sort of GeForce and "hey, want to run your homework on this? Check how cool!". Really being strong in the specialised field is great and all but where are the devs for that supposed to some from. If you want to check out HIP or whatnot and you just did not luck out enough to have a Vega on your machine, so sorry, you don't get to play. I fired up a 6900XT on the living room PC today (because my 5700XT is a paperweight and drivers are apparently never going to get fixed, which is some different fun). Absolute monster of a card, ran my OpenCL thing in it, makes my Radeon VII on the work machine look like a toy. But turns out if I want to have access to HIP (and SYCL since AMD is apparently trying to pretend that doesn't exist either so hipSYCL is the only option I know of) I can't upgrade my work machine. This is particularly bad when you consider that getting a hold of any Vega card was super difficult even when they were the current card. People are just locked out of most of ROCm by default.

2 -> Even if you do have it, just getting ROCm up is so difficult. Prebuilt packages are available for very few distros and building your own is really tricky. The difficulty starts with even figuring out what you need to build. I have no idea how many projects that is these days, how many of them are redundant... Just, no idea. If you go on gpuopen.com there is no mention of ROCm. There's even no mention of OpenCL. I had to install Windows for a work project and just couldn't find even the OpenCL dev stuff. With CUDA (which I keep bringing up because when AMD drops HC C++ and ignores SYCL in order to focus exclusively on HIP, it's what AMD cares about, apparently) you go to their website, get the package and done, you're going. With ROCm? I scream at CMake all day for work and even I have trouble getting that up. The one effort to bring this together that I saw happening was the old Experimental-ROC repository but that was abandoned (it was maintained by one dude, seemingly going on his own but he's in a different project now, apparently). So we're back to "good luck figuring even how many clangs you need".

vegabook said it and it's for sure the feeling: You look at how this is coming and can't help but feel that "no, AMD does not give a single care to end-user compute". I feel as if they're living off of the spite a lot of people have for nVidia ( I know I do. 5700XT is a paperweight that I'm convinced AMD isn't going to fix and STILL I just refuse to go nVidia if there's a chance 6-series will work). Availability is the central theme here, I guess. ROCm is just this unicorn that people get to hear about but can't really ever touch, so it's never real