AMD's GPU Performance API Library 3.5 Drops ROCm/HSA Support

[bridgman]

I expect this is because it was broken and didn't actually work. I reported this a while ago and didn't get any response from AMD.

AFAIK we concluded that trying to maintain one low-level perf API for both kernel-submit (PAL/graphics) and userspace-submit (ROCm) programming models wasn't going to work out well over time. I think there's a separate API for ROCm but will confirm.

[bridgman]

I still have no idea what AMD's Compute plan is, none of their open offerings are complete, wish they'd get their finger out and commit to one of them

We only have one open offering - the ROCm stack - and are building that up for all our recent parts, not just for datacenter.

We spent quite a while trying to establish clover (Mesa) as a cross-vendor standard but even after a few years it was still pretty much AMD-only, so we went back to opening up our own code instead. That was around 2015 IIRC.

[FireBurn]

We only have one open offering - the ROCm stack - and are building that up for all our recent parts, not just for datacenter.

We spent quite a while trying to establish clover (Mesa) as a cross-vendor standard but even after a few years it was still pretty much AMD-only, so we went back to opening up our own code instead. That was around 2015 IIRC.

Any idea when my Tonga (M395X) or Raven will be supported with the fully open stack?

[pegasus]

I still have no idea what AMD's Compute plan is

Let me guess ... whatever Oak Ridge sponsors them to develop for Frontier?

[duby229]

Check out the ROCm Github issues. A year ago or so you used to see AMD devs responding to almost every issue, definitely every valid one. Now they are nowhere to be seen. There are some big issues with ROCm, such as false advertising for many broken features, devices which are not supported etc. Only silence from AMD, it's a shame really.

Well, that is a shame. Problem with ROCm is that AMD is the sole contributor. It's not part of some upstream project. The biggest reason why radv was so quick to develop is because rasdeonsi already existed in the same upstream project, ROCm and amdvlk have no such benefit. If ROCm was part of say mesa upstream or LLVM upstream then it would most likely be a whole different story.

[duby229]

I'm kinda sorry for being blunt, but not too much so...

Bottom line is AMD's proprietary drivers -ALL- suck ass badly. Some of the worst drivers ever. Anybody else remember fglrx? I do.... AMD's attempts to develop their oss drivers the same way is just going to end up with oss drivers that suck ass just as badly. That's obviously what's currently happening.

[Marc Driftmeyer]

Please AMD fix OpenCL >= 1.2 implementation in Mesa and everyone is happy and buy more Radeon stuff. In the moment people who buying some navi based graphics cards (like me) instantly wish they had thrown their money on something that will provide them with Optix.

You just have to install certain packages of their 19.30 released AMDGPU-PRO and OpenCL works. Then install their LLVM-9 packages as well and build stuff like Blender using LLVM against those packages under /opt and the results are solid. Without it you get nothing.

[Marc Driftmeyer]

I'm kinda sorry for being blunt, but not too much so...

Bottom line is AMD's proprietary drivers -ALL- suck ass badly. Some of the worst drivers ever. Anybody else remember fglrx? I do.... AMD's attempts to develop their oss drivers the same way is just going to end up with oss drivers that suck ass just as badly. That's obviously what's currently happening.

The AMDGPU driver developed by them has my old RX 480 getting nearly 90fps on Unigine Heaven 1920x1080 with Tessellation moderate, Quality on High. Two years ago it was barely above 60fps. They're improving their stacks.

[Naquatis]

You just have to install certain packages of their 19.30 released AMDGPU-PRO and OpenCL works. Then install their LLVM-9 packages as well and build stuff like Blender using LLVM against those packages under /opt and the results are solid. Without it you get nothing.

Yep, I used Version 19.30.934563

OpenCL userspace driver as provided in the amdgpu-pro driver stack. This package is intended to work along with the free amdgpu stack.

Works nice for Polaris RX 480 but not for Navi based RX 5700 XT

[audir8]

... If ROCm was part of say mesa upstream or LLVM upstream then it would most likely be a whole different story.

The OpenCL/HIP compiler parts of ROCm are upstream in LLVM-..8/9/10: https://llvm.org/docs/AMDGPUUsage.html

ROCm has been and is headed in the right direction. It's not AMD's fault, but the reality of trying to focus on OpenCL/HIP/OpenMP on a variety of hardware would be easier if the upstream DL frameworks weren't all HIP-dependant currently. If you want to blame anyone, it would be CUDA's headstart in DL, but AMD's doing the best they can. The upstream DL frameworks could help a bit more though by moving to SYCL/OpenMP, though this might take some time but it is happening.