It Looks Like AMD Is About To Post The Open-Source Radeon "Navi" Driver Code

[pete910]

To the experts: when can we expect the open source driver to support OpenCl? To me that is the only reason to still bother with amdgpu-pro, and if you're not using Ubuntu that is an issue.

????

On Antergos(Arch based) and using the oss driver with closed opencl stack fine, it's like 3 clicks !

Not tried the mesa opencl in a while tbh so no clue what state that's in

[andrei_me]

when you can make a random comment and get a response straight from the horse's mouth.

For me, that is what separates Phoronix from the rest, a couple days ago I asked something about Freedreno, tagged robclark and receive an answer from him.

You people from AMD, Intel, Valve, Feral and others here

[skeevy420]

????

On Antergos(Arch based) and using the oss driver with closed opencl stack fine, it's like 3 clicks !

Not tried the mesa opencl in a while tbh so no clue what state that's in

That's not even relevant since AMD only supports a handful of distros, people not using those distros don't have an official Pro\OpenCL package to use, and some people feel all warm and fuzzy inside when they're using properly supported software...coming from someone that uses random Pro components, including said OpenCL package, on an unsupported distribution (Manjaro).

With our current methods being either pick an OS that AMD supports or hack away at the Pro blobs until X feature is supported in the open world, it's a pretty fair question to ask.

[bridgman]

For many recent GPUs, you can run ROCm OpenCL over an upstream kernel...

EDIT... and the closed source OpenCL usually works with upstream kernels as well, although a few features (eg DirectGMA) will not be available without the non-upstreamable bits we ship in the DKMS kernel. I think that's what pete910 was talking about.

With our current methods being either pick an OS that AMD supports or hack away at the Pro blobs until X feature is supported in the open world, it's a pretty fair question to ask.

It's not about "hacking away at the Pro blobs"... the closed source components are designed to work on upstream kernels other than the few features that require non-upstreamable kernel code, and our package hierarchies are intended to support either userspace-only or user+kernel installs.

[pete910]

That's not even relevant since AMD only supports a handful of distros, people not using those distros don't have an official Pro\OpenCL package to use, and some people feel all warm and fuzzy inside when they're using properly supported software...coming from someone that uses random Pro components, including said OpenCL package, on an unsupported distribution (Manjaro).

With our current methods being either pick an OS that AMD supports or hack away at the Pro blobs until X feature is supported in the open world, it's a pretty fair question to ask.

Read the guys post again to which I replied , You seem to have miss understood what he/she was wanting/stating.

[skeevy420]

For many recent GPUs, you can run ROCm OpenCL over an upstream kernel...

EDIT... and the closed source OpenCL usually works with upstream kernels as well, although a few features (eg DirectGMA) will not be available without the non-upstreamable bits we ship in the DKMS kernel. I think that's what pete910 was talking about.

It's not about "hacking away at the Pro blobs"... the closed source components are designed to work on upstream kernels other than the few features that require non-upstreamable kernel code, and our package hierarchies are intended to support either userspace-only or user+kernel installs.

I wasn't sure if that user was talking about the opencl-amd package, the kernel bits, or what either. That EDIT you made begs the question -- Should the opencl-amd PKGBUILD need to depend on the hypothetical amdgpupro-dkms package I brought up on the previous page?

Maybe "hacking at the Pro blobs" wasn't the right term...what about "porting from the Pro blobs until it works"? Is that better? All I meant was we're left guessing in regards to what all is needed when porting from Supported to Unsupported Distribution and this OpenCL situation is a great example -- the ported one from Pro works on Arch, but it's apparently not feature complete since we don't have the Pro DKMS bits as a package to be built (we have them in the form of what y'all release in the DKMS Pro package, but not as an AUR package). We, some of us, me at least, may not have even known about needing the DKMS Pro bis to accompany the OpenCL package until yourself mentioned it in this thread.

I personally consider porting binaries from X to Y, whether it be random AMDGPU-Pro components from Ubuntu to Manjaro or Motorola's Circle Widget over to my LG phone, to be in the category of "hacking at it". FWIW, with you being a professional, I can see how that terminology and logic would grind your gears.

Read the guys post again to which I replied , You seem to have miss understood what he/she was wanting/stating.

They were curious when/if the open version would support the Pro OpenCL features and you suggested installing a PKGBUILD which only works if that user is on Arch or Arch-based. That suggestion, while helpful to Arch users, isn't relevant at all.

Granted, it works just fine on Manjaro, but we might as well be running an Ubuntu PPA on Debian Testing using methods like that since it really isn't that much different. That's why I then said pick one AMD supports if you actually need those features or "hack" away at it until it is supported on what you use.

There wasn't much to misinterpret there.

That said, read the question I asked above based on what bridgman and agd5f have posted here and you'll realize that the package you suggested isn't necessarily feature complete since it doesn't contain the DKMS kernel bits meaning that package may or may not work for that user's needs.

[pete910]

They were curious when/if the open version would support the Pro OpenCL features and you suggested installing a PKGBUILD which only works if that user is on Arch or Arch-based. That suggestion, while helpful to Arch users, isn't relevant at all.

Granted, it works just fine on Manjaro, but we might as well be running an Ubuntu PPA on Debian Testing using methods like that since it really isn't that much different. That's why I then said pick one AMD supports if you actually need those features or "hack" away at it until it is supported on what you use.

There wasn't much to misinterpret there.

That said, read the question I asked above based on what bridgman and agd5f have posted here and you'll realize that the package you suggested isn't necessarily feature complete since it doesn't contain the DKMS kernel bits meaning that package may or may not work for that user's needs.

I had highlighted the bit I was replying too, Pointing out that it easy on Antergos so you are not just having to use *buntu. It was merely a FYI

[skeevy420]

I had highlighted the bit I was replying too, Pointing out that it easy on Antergos so you are not just having to use *buntu. It was merely a FYI

I know. I tend to do that myself as a Manjaro user.

The other day I went to post a solution for an Ubuntu user when I realized that nothing I was posting would actually work there or help them since Ubuntu & Arch do Grub differently. I've since been on a bit of a generic information kick...stuff that isn't distribution specific...

My apologies for being an asshole about it.

[M@yeulC]

Nice to hear that ROCm can now work with the upstream kernel. I'm going to try this soon.

I wonder whether those new AMD GPUs will have HW AV1 support? I hope so.
Regarding power efficiency vs processing power, I've heard that lowering voltages could get you a long way without degrading performance too much on more recent architectures.

[FireBurn]

Nice to hear that ROCm can now work with the upstream kernel. I'm going to try this soon.

I wonder whether those new AMD GPUs will have HW AV1 support? I hope so.
Regarding power efficiency vs processing power, I've heard that lowering voltages could get you a long way without degrading performance too much on more recent architectures.

Apart from some SOCs video decoding hardware support generally legs behind, so usually it goes ARM, Intel, then AMD - I've no idea about nVidia