Radeon ROCm 3.1 Released With RAS For Vega 7nm, SLURM Support

[bridgman]

AMDGPU Pro OpenCL worked fine with Mesa 19.3.0:

https://aur.archlinux.org/pkgbase/amdgpu-pro-installer/

Every Mesa version after that we are now at Mesa 19.3.4 broke the OpenCL functionality. But I think I was wrong with

https://aur.archlinux.org/packages/amf-amdgpu-pro/

.. never worked for me because you need to add a seperate plugin for OBS and then amf would use PAL or ORCA.

Sorry, still don't understand where Mesa fits into this. If you are using AMF then you aren't using Mesa for anything video-related AFAIK, it's an either-or.

[bridgman]

ROCm is fine and all, but i wish AMD hadn't abandoned Clover. ROCm does not support every architecture and it typically requires pcie 3.0 atomics, plus it is a whole software ecosystem that goes beyond mere OpenCL support. What about simple OpenCL support for all of us out of the box in MESA?

We worked on Clover in the hope that other vendors would pick it up as well, but even after years it ended up being pretty much AMD only. That didn't make sense because we already had an OpenCL implementation and had already open sourced it along with the ROCm back end.

If other vendors were to pick up Clover and make significant contributions to the common code I think we would be more likely to help again, but asking us to divide our limited resources across two AMD-only implementations doesn't seem like a great idea. CLover may have been "so close" for you and one specific application but I didn't get the impression it was anywhere near close for other users with other applications.

[Naquatis]

Sorry, still don't understand where Mesa fits into this. If you are using AMF then you aren't using Mesa for anything video-related AFAIK, it's an either-or.

Maybe I am wrong but I thought AMF is used for video decode and encoding like nvenc on NVidia. So if Mesa broke OpenCL and AMF need OpenCL for encoding then it has a relation.

[TemplarGR]

We worked on Clover in the hope that other vendors would pick it up as well, but even after years it ended up being pretty much AMD only. That didn't make sense because we already had an OpenCL implementation and had already open sourced it along with the ROCm back end.

If other vendors were to pick up Clover and make significant contributions to the common code I think we would be more likely to help again, but asking us to divide our limited resources across two AMD-only implementations doesn't seem like a great idea. CLover may have been "so close" for you and one specific application but I didn't get the impression it was anywhere near close for other users with other applications.

Yeah, i know and i understand. For profit companies don't want to help their competitors with their investments and this goes for all major gpu vendors. Intel wanted to have their own open source solution outside MESA, Nvidia doesn't care for OpenCL at all even in their binary drivers, so why AMD has to invest everything to help others for free? I get that, i really do, i would probably had made the same choice if i was the one making the call at AMD. I understand why it happened, i just think it was stupid (on account of every company involved in this situation) and in the end hurt everybody.

The reason for this is that having a proper MESA OpenCL implementation would lead to more Opensource projects actually using OpenCL for solving problems. This would lead to an overall better OpenCL software ecosystem and a higher adoption for it. Not many developers care about OpenCL when it does not work out of the box in distros and there are differences in the implementations. It is a wasted opportunity, at least in the Linux world.

At least now that Intel will be using Gallium 3D for their Broadwell hardware and later, perhaps they could change their minds about Clover as well. I am no MESA developer but i think Gallium drivers shouldn't need a ton of work to support Clover, no? So Intel Iris driver could support Clover? Red Hat cares about Nouveau and does some work around Clover, so that is my secret wish, for Clover to become supported by all of you contributors in the future. One can dream.

[Naquatis]

We worked on Clover in the hope that other vendors would pick it up as well, but even after years it ended up being pretty much AMD only. That didn't make sense because we already had an OpenCL implementation and had already open sourced it along with the ROCm back end.

If other vendors were to pick up Clover and make significant contributions to the common code I think we would be more likely to help again, but asking us to divide our limited resources across two AMD-only implementations doesn't seem like a great idea. CLover may have been "so close" for you and one specific application but I didn't get the impression it was anywhere near close for other users with other applications.

But opencl-mesa is a package everyone can simply install without thinking on any distribution while ROCm never made it because package maintainer don't know how to cope with this beast. Did it finally work for Blender?

Read what rsa wrote about: https://aur.archlinux.org/packages/rocm-opencl-runtime/

AMD repository chain is a complete mess and the documentation is outdated as far as 2.7.0 so I blindly need to change parameters and arguments until something happens. I am trying to correctly build it but no luck so far.

[bridgman]

Maybe I am wrong but I thought AMF is used for video decode and encoding like nvenc on NVidia. So if Mesa broke OpenCL and AMF need OpenCL for encoding then it has a relation.

Nope - the primary video encode/decode APIs are implemented in Mesa and used by both all-open and AMDGPU-PRO stacks. AMF is an alternative video encode/decode implementation ported from Windows and released in closed-source form.

You keep saying "Mesa broke OpenCL" but they are not related other than the CLover OpenCL implementation in Mesa. Best guess is that if you run AMF with a full AMDGPU-PRO packaged driver installation then assuming AMF uses OpenCL (I didn't think it did) re-installing Mesa might replace the AMDGPU-PRO OpenCL implementation with the partial OpenCL implementation in Mesa.

[bridgman]

Yeah, i know and i understand. For profit companies don't want to help their competitors with their investments and this goes for all major gpu vendors.

Actually we would have been happy if our competitors had picked up CLover and started using it, and we would have continued to contribute to it. The problem was that our competitors did *not* pick it up, and so it became effectively a second AMD-only implementation.

I would like to see us do a bit more in terms of open source OpenCL for consumer products - over the last year or two we have had to focus pretty hard on datacenter in order to get those products out into the market, but we are trying to get people back onto consumer products as well.

[aufkrawall]

I wasn't aware it was ever planned... did we make some kind of statement about opening it ?

I think for some reason, this has become the general expectation.

Anyhow, that's bad news. VAAPI encoding support is notoriously buggy on AMD GPUs and it's questionable if programs like Handbrake or obs-studio will ever support AMF on Linux if it's not easily deployable. Handbrake devs btw. even refuse VAAPI support (for dumb reasons, but still).

[oleid]

Just wondering... Is there really use for OpenCL these days when you could also do your compute stuff with Vulkan? At least every vendor should support that.

Edit: makes sense to enhance the OpenCL situation to support existing apps. That for sure. I'm more interested, however, in the developer's point of view.

[bridgman]

I think for some reason, this has become the general expectation.

Uh-oh. Any idea why that might be ? I don't think we have even hinted at the possibility, particularly since we already have open source video encode/decode support in mesa and the kernel drivers.

Anyhow, that's bad news. VAAPI encoding support is notoriously buggy on AMD GPUs and it's questionable if programs like Handbrake or obs-studio will ever support AMF on Linux if it's not easily deployable. Handbrake devs btw. even refuse VAAPI support (for dumb reasons, but still).

Bleah... yeah, looks like the Handbrake developers designed around the -PRO drivers and are using AMF rather than the Mesa drivers.

I don't remember what we are recommending in terms of APIs for encoding, but I didn't think it was VAAPI either, more likely OpenMax.