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

[bridgman]

First of all, let me clear some points about SPIR support. We never supported SPIR-V.

I think the intent of that comment was in response to a statement that we had dropped SPIR-V support, which AFAIK was not the case. Far be it from me to tell people what to complain about, but IMO the real issue here is that we dropped SPIR support before adding SPIR-V support.

[Naquatis]

It really look like they want to translate opencl to spir-v to execute it on the target hardware:

https://github.com/KhronosGroup/SPIR/tree/spirv-1.1

So how far is that away from something that is useable for general purpose?

If you dig deeper into this crap you get that they do this whole spir-v stuff to obfuscate their holy code and hardware.

AMDs official comment you can find here:

https://community.amd.com/thread/232093

is:

First of all, let me clear some points about SPIR support. We never supported SPIR-V.

muahahahaha! You got owned by your Radeon hardware ..

[mibo]

No one want OpenCL compute anymore ... you can put all this shit into the garbage.

we want Vulkan-only based Compute.

crap!

Just today on the darktable mailing list: "...Will upgrading to a newer GFX give me a significant performance boost? Any GFX recommendations for that purpose?"

Why can't AMD provide an easy working OpenCL solution for their graphics cards?
Please!
How many more years do we need wait?
I'm also still using the RadeonPRO 19.30 solution besides of MESA for my RX580. What if my card breaks? Do I need to buy an old AMD card or Nvidia?

[Meteorhead]

No one want OpenCL compute anymore ... you can put all this shit into the garbage.

we want Vulkan-only based Compute.

Thank you for your insightful contributions to the discussion. Please, sit down.

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

[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

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

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

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

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