Radeon Software for Linux 20.30 Released

[bp787]

We've all misread output. It happens.

The kernel-ls is based on Linux 4.4. You need something newer than 4.12 for decent AMD Polaris support. I suggest 4.15 or higher since that's when all the kinks in my RX 580 seemed to be worked out.

You should be good to go with the elrepo kernel-ml since it's a Linux 5.8 based kernel. And you assume correctly.

Good Luck.

I just tried the Kernel-ml. everything seems to work. I need to test it with my application to validate performance vs one of our similar systems with an nvidia card, but glxgears seems to report decent numbers with the amdgpu driver enabled.

Thanks again!

[skeevy420]

you know what, I misread the hwinfo output. you are correct that it is indeed an RX540. Big oops on me, thanks for pointing that out.

So, I have tried an elrepo kernel-lt, but it didn't have support for much of the other hardware in the laptop. I will try the kernel-ml next.

RHEL 8 isn't really an option for me, currently, but I will certainly try it. RHEL definitely backports a lot of the more modern hardware. I may put in a support request for this to see if there's anything that can be done in the near term, but they're not usually that fast on this type of update.

Ubuntu is not an option at all for me. all of our software is RPM based, and would take a significant amount of time to switch over.

So if I go with a 5.x kernel, I should be able to get amdgpu support without installing anything extra? I assume that I would then just use DRI_PRIME=1 to enable discrete graphics, yes?

Appreciate all the help!

We've all misread output. It happens.

The kernel-ls is based on Linux 4.4. You need something newer than 4.12 for decent AMD Polaris support. I suggest 4.15 or higher since that's when all the kinks in my RX 580 seemed to be worked out.

You should be good to go with the elrepo kernel-ml since it's a Linux 5.8 based kernel. And you assume correctly.

Good Luck.

[bp787]

Are you sure that GPU model is correct? All the Latitude 7424's that I looked up come with either the discreet Intel graphics or an AMD RX 540 and the RX 540 does not have a supported AMDGPU-Pro Linux driver on AMD's website which explains why it doesn't work after you install this article's driver.

If you can confirm that the GPU isn't an RX 550, your best bet is to update to RHEL 8.2 (if that's a possibility). I know for sure that RHEL 8.2 uses the 4.18 kernel which is new enough to have full open source driver support for your GPU. I'm not sure how much AMDGPU the Red Hat devs have backported to the Linux 3.10 kernel that RHEL 7.8 uses. Stock Linux 3.10 does not have AMDGPU period.

I'm not that keen on Red Hat, but upgrading to 8.2 is what I'd consider if I were in your position. Actually, I'd try out a CentOS live image based on RHEL 8.2 first to ensure it works and then upgrade .

I saw that the 7424 is sold with Ubuntu 18.04. It might not be your cup of tea, but any Ubuntu version or variant from then to now should work just fine for you if you aren't tied to RHEL for work reasons.

you know what, I misread the hwinfo output. you are correct that it is indeed an RX540. Big oops on me, thanks for pointing that out.

So, I have tried an elrepo kernel-lt, but it didn't have support for much of the other hardware in the laptop. I will try the kernel-ml next.

RHEL 8 isn't really an option for me, currently, but I will certainly try it. RHEL definitely backports a lot of the more modern hardware. I may put in a support request for this to see if there's anything that can be done in the near term, but they're not usually that fast on this type of update.

Ubuntu is not an option at all for me. all of our software is RPM based, and would take a significant amount of time to switch over.

So if I go with a 5.x kernel, I should be able to get amdgpu support without installing anything extra? I assume that I would then just use DRI_PRIME=1 to enable discrete graphics, yes?

Appreciate all the help!

[skeevy420]

i'm having some trouble with this driver. I have a dell latitude 7424 with an AMD RX550. upon installing onto a stock RHEL 7.8 os, the laptop locks up on the login screen. I can't Alt-FX, etc... The only way to fix is to blacklist AMDGPU, and then remove the driver. I've tried both the basic install and the pro and get the same results. Any suggestions?

Are you sure that GPU model is correct? All the Latitude 7424's that I looked up come with either the discreet Intel graphics or an AMD RX 540 and the RX 540 does not have a supported AMDGPU-Pro Linux driver on AMD's website which explains why it doesn't work after you install this article's driver.

If you can confirm that the GPU isn't an RX 550, your best bet is to update to RHEL 8.2 (if that's a possibility). I know for sure that RHEL 8.2 uses the 4.18 kernel which is new enough to have full open source driver support for your GPU. I'm not sure how much AMDGPU the Red Hat devs have backported to the Linux 3.10 kernel that RHEL 7.8 uses. Stock Linux 3.10 does not have AMDGPU period.

I'm not that keen on Red Hat, but upgrading to 8.2 is what I'd consider if I were in your position. Actually, I'd try out a CentOS live image based on RHEL 8.2 first to ensure it works and then upgrade .

I saw that the 7424 is sold with Ubuntu 18.04. It might not be your cup of tea, but any Ubuntu version or variant from then to now should work just fine for you if you aren't tied to RHEL for work reasons.

[bp787]

i'm having some trouble with this driver. I have a dell latitude 7424 with an AMD RX550. upon installing onto a stock RHEL 7.8 os, the laptop locks up on the login screen. I can't Alt-FX, etc... The only way to fix is to blacklist AMDGPU, and then remove the driver. I've tried both the basic install and the pro and get the same results. Any suggestions?

[agd5f]

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.

The goal is to get to a fully open source stack, but it takes time and customers usually want a full solution at launch time. We still ship the closed source OpenGL drivers for workstation because they still support a number of extensions and compatibility profile features which mesa does not support yet. In addition they are certified for certain workstation applications. Mesa is catching up, but still not there yet. Same thing for other features like peer to peer DMA support. It was like boiling the ocean to get basic peer to peer DMA support upstream due to lots of weird architectures and bikeshedding about APIs. It's imperative for good performance in a lot of datacenter use cases so you don't really have a product without it. Same thing on the ROCm side. We are constantly upstreaming our changes to LLVM, OpenMP, GDB, etc., but those projects all have their own release schedules which do not always align with product release schedules. Also all of the major RDMA drivers have out of tree drivers that support features like peer to peer DMA. If you don't support those, you don't have a viable product. Ideally they would work on upstreaming their changes as well, but most don't. You need some mechanism to provide solutions to customers. Packaged drivers is one way to achieve that.

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

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

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

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