Radeon Software for Linux 20.30 Released

[GraysonPeddie]

Okay guys. I've had enough of quoting me. It's not like I didn't read the first post and ignored it.

[eydee]

Linux 20.30? What? Are we time traveling or has Linux been taken over by Mozilla?

[user1]

AMD should simply offer amdvlk-pro and opencl as standalone packages/archives. It's just throwing user space drivers into file system and that's it, no need for weird obstacles like distribution restrictions etc. amdvlk-pro driver is highly underrated, I consider it much better than the Nvidia crap.

Completely agree. I extracted amdvlk-pro and its json vulkan loader to my home directory and just changed the path to amdvlk64.so in the vulkan loader. This way it works on virtually any distribution. I personally have much better experience with amdvlk-pro than amdvlk-open. amdvlk-pro has absolutely no issues on my end, while amdvlk-open I remember had graphical glitches in some versions and when I tried one of the latest versions, I had hangs and garbage on screen. Not to mention amdvlk-pro has much faster compile time performance because the proprietary compiler is still way ahead of LLVM and the general performance is also a bit faster than amdvlk-open. I mean at this point I don't understand what is AMD's goal with amdvlk-open when RADV+ACO is now clearly the superior open source option. While amdvlk-open is technically open source, its development is not transparent like the development of mesa drivers and it seems to recieve low amount of external contributions unlike mesa. I think AMD should just release amdvlk-pro as standalone packages like it currently does with amdvlk-open. These days most games on Linux will probably run the best with RADV+ACO (at least on Polaris), but some Windows Vulkan games like DOOM run the best with amdvlk-pro so that's why I think it'll be useful to release it as a standalone package like amdvlk-open.

[aufkrawall]

I think the main purpose of amdvlk-open is that it can serve as a guidance for game and Mesa developer if it makes sense to do so. So I'd say it's good that it exists, but unless AMD doesn't improve shader compile times, it's not a good choice for consumers while there are much better suited amdvlk-pro and RADV ACO drivers.
I'd communicate that accordingly if I was AMD, including making amdvlk-pro more accessible to more users.

[bridgman]

AMD should simply offer amdvlk-pro and opencl as standalone packages/archives. It's just throwing user space drivers into file system and that's it, no need for weird obstacles like distribution restrictions etc. amdvlk-pro driver is highly underrated, I consider it much better than the Nvidia crap.

Agree. The ROCm stack includes instructions for installing user space packages on top of a distro kernel and the packaging hierarchy supports it with a single package that drags in everything required. I thought the graphics stack was set up the same way but apparently that is not the case today.

There are still a couple of package formats we need to get covered as well.

[OneTimeShot]

I assume that AMD are just repackaging the Open Source drivers for older distributions. I can't imagine that they bother writing an open and a closed source driver for their chips...

[finalzone]

...even though I agree that the proprietary OpenCL stack is much faster (Clover does not work on Vega, and ROCm somehow likes to stutter the rendering therefore making it slow)

Same applied to AMD Ryzen APU which seems neglected for years. amdgpu-pro opencl runs fine despite the unknown GPU part detected on mobile Raven Ridge (not sure it it is the same for Picasson and Renoir). It seems the database of GPU part of AMD Ryzen APU is a mess in term of name which wasn't the case for the Streamroller series like Kaveri.

[bridgman]

I assume that AMD are just repackaging the Open Source drivers for older distributions. I can't imagine that they bother writing an open and a closed source driver for their chips...

Yes and no... we do still have separate closed source OpenGL and Vulkan drivers but everything else is open source as you suggest. Think about it as three graphics stacks plus optional OpenCL:

#1 - upstream, where we do all of our development and developer testing - we have internal-only trees for development work on products we aren't going to release for a long time yet, but those trees are periodically rebased on upstream code

#2 - hybrid open/closed packaged drivers with two goals, supporting enterprise distro kernels with newer drivers and providing workstation-specific closed source OpenGL and Vulkan drivers.

Most of the code is open source with minor changes, primarily adding a Kernel Compatibility Layer (KCL) with build-time and run-time logic to support a range of kernel versions used by enterprise distros via DKMS builds. The other change is adding code for a couple of non-upstreamable features such as DirectGMA and RDMA NIC support, both of which require pinning physical memory and exposing physical addresses outside the driver. This is usually called AMDGPU-PRO.

#3 - all-open packaged drivers, similar to #2 but with Mesa OpenGL from upstream plus the open source version of AMD Vulkan, usually called AMDVLK. Uses the same kernel code as #2, partly for convenience and partly to support OpenCL with DirectGMA.

In addition to the above 3 stacks, each driver release includes OpenCL compiler and runtime which can be used with any of the three stacks.

[billyswong]

First Post here.

I am using the closed source amd driver for my 2200G PC. The original reason of trying the closed source driver is for testing OpenCL, but the major reason of staying closed source after testing back and forth is the stability issue.

When I use the closed source driver, sometimes the GPU-enabled Firefox will hang with a bunch of graphic glitch, but I can either wait till it recover or force close the Firefox. But when I use the open source driver, not only that the hang still happen, it hang the whole OS (running Linux Mint + Mate Desktop + Compiz Compositor here) and the only way out is hard reset the whole computer. Even Ctrl-Alt-F1 to out-of-GUI terminal does not respond.

(Another minor reason is ROCm does not handle the user right properly and I fail to get OpenCL to run without sudo.)

Therefore, if someone really drop the closed source amd driver support for OpenGL, that would be a bad news for me.

[MadeUpName]

The whole thing is just such a mess. How is a normal end user supposed to know which drivers they are supposed to use? This needs to get paired down to one channel then AMD needs to commit to that. I was a dedicated Linux admin for 20+ years and now own a video production company and deal with this stuff on a fairly regular basis. But the whole AMD approach to their graphics compute stacks make my eyes glaze over in a way nothing else in Linux ever has including the kernel it's self. There is just no way your average end user is going to be able to cope at all and that is a failure. AMD pick one option and run with it.

I'm hoping with the new dedicated compute cards coming out of AMD I will be able to run the pure graphics on one card with the open source driver and then put compute on the other card and still be able to get into the system when the compute side invariably fucks up because the proprietary stuff doesn't match up with the open source stuff. It is insane that you have to reinstall to patch with the AMD proprietary drivers.