A quick guide: How to install OpenCL for AMD GPUs on Linux Kubuntu 18.04 (and similar distro)

Thank you very much!!

The bit that is "built-in" (and it's the same for all Linux distros) is the amdgpu kernel module.  If you are using a particular kernel version, you should use the particular version of amdgpu (and all other kernel modules for that matter) built at the same time from the full kernel source tree.  The amdgpu kernel module is an open source contribution by AMD to the Linux kernel project and is part of the kernel source tree.  It is the basis on top of which you need to install further library components which supply OpenCL.

The OpenCL libraries are not "built-in".  There is a mixture of all sorts of bits and pieces, both open source and proprietary, in the "Radeon Software for Linux" - formerly officially known and currently unofficially still known as AMDGPU-PRO.  The actual OpenCL libs are just a small subset of the total of about 50 different packages that make up the full set.  There are around 5 or 6 packages only that are needed for OpenCL.  I had bought a Polaris GPU (RX 460) nearly 3 years ago and needed the OpenCL components from the 16.60 version of that package so was forced to work out what parts were needed.

I did that by carefully studying the amdgpu-pro-install script at the time.  If I remember correctly, there was a --compute option that pointed me in the right direction.  That option was later deprecated and replaced with --headless --opencl=....  I can remember reading a note about --headless being the way to NOT replace the already included OpenGL stuff from the original OS install with whatever other packages from -PRO that could also provide some different version of OpenGL.  Since the graphics side of things was working fine and I just wanted to add OpenCL, I felt that was probably the best policy.  It works absolutely fine for my very-much-non-supported distro situation :-).  For those with a supported distro, just do something along the lines that robl suggested, and perhaps add the --headless option to what he showed.  In fact, that's exactly what the OP of this thread posted.

It is permissible to have multiple OpenCL implementations installed.  For that reason, I always selected the packages that were pointed to by the --opencl=legacy,pal variant of that option.  My understanding is that the 'legacy' setting is used for GPUs prior to Vega (eg Polaris) whereas 'pal' is for vega or later.  I decided that by having both, it would be possible to just replace a Polaris GPU with Vega or later and have it work out of the box.  As yet, I don't own anything later than Polaris so haven't tested that.

Now to get to the actual 'meat' of your quote.  I have used many versions of the OpenCL components from AMDGPU-PRO from 16.60 to present.  The versions I have run are 16.60, 17.40, 17.50, 18.10, 18.20, 18.30, 18.50, and 19.10.  The short answer is that I have experienced very little difference in compute speed/efficiency/whatever between any of them.  I should hasten to add that the testing methodology used was extremely inadequate - on any reasonable standard.  So, if you want to do it more rigorously, please be our collective guest :-).

When I was testing for benefits of newer versions, I would select a test host or two and upgrade the full machine to the latest of everything (including the kernel and amdgpu module).  I would then use my script to apply the new version of the OpenCL bits from AMDGPU-PRO.  I would then start BOINC and make sure the GPU was still being detected.  I would take a pretty rough average of a page of crunch times for the previous version and compare that with the average for the next page of crunch times for the new version, making sure to avoid any possible 'gap' tasks.  The numbers always turned out to be quite similar so I wouldn't bother to upgrade any further hosts.  It continued that way until 18.30.  At that point most of the Polaris fleet was still on 16.60 and the test machines plus new installs were on 18.30.

The object of all this was NOT to test for better OpenCL performance, although that would have been a nice byproduct.  I was dealing with a different issue completely.   In late 2017 and on into 2018, I was having an issue with RX 460 GPUs stalling/locking up extremely regularly around the 25 day uptime mark.  If you're interested, I discussed the issue in some detail in this message and in a subsequent message, two messages later.  In 2018, the same thing was happening with RX 570/580 GPUs except it was on a much shorter timescale - around 12-15 days uptime.  I wasn't sure what was causing the issue but I suspected the amdgpu kernel module or perhaps the OpenCL bits.

For that reason, I was very keen to both upgrade the kernel+module as well as the OpenCL bits on test machines whenever there were new versions.  It was a tedious process because I wouldn't know if there had been a resolution of the problem until either the 15 day or 25 day 'limit' had been well and truly exceeded.  At the time I first became confident enough that there were longer uptimes and they were for real, the 18.X0 versions of AMDGPU-PRO were the current ones and when I had uptimes getting beyond the 60+ days mark, 18.30 was available.  I was just elated that somebody had finally fixed whatever it was that was causing the problem.  I regarded the task of upgrading every single host to the magical kernel+amdgpu+OpenCL combination as a true pleasure rather than as a chore :-).  I suspect it was the amdgpu module rather than OpenCL but I didn't actually spend time trying to prove one way or the other.

As a result, everything got upgraded to 18.30 and there was no urgency to go much further than that.  I have incorporated both 18.50 and 19.10 into my script as well.  Initially I had trouble getting those to work but solved that by discovering that I needed to add an extra component to the LD_LIBRARY_PATH environment variable.  I have casually run both of those versions on test machines and nothing much seems to have changed.  If someone happened to come up with some evidence that crunch times were improved for either 19.20 or 19.30 (or whatever comes next) I could probably get motivated to do a mass upgrade once again :-).

I'm very pleased to hear that!  The ability to do some basic scripting is a very useful skill to possess for someone who wants to use Linux to its full potential.

I looked at what Koschi was doing when he first mentioned it.  I haven't looked more recently so I'm not sure if it has changed in any significant way from what I saw at the time.  These things can quickly evolve over fairly short time scales :-).  The script is tailored to Ubuntu style distros (.deb packaging) and does things a bit differently to the way I approached the problem.

I do understand what he was doing and why so if there is anything that puzzles you, please ask and I'll try to explain.  You have a few hurdles to jump - it's not just a matter of understanding the syntax of the shell (bash).  You have to come to grips with some pretty powerful (and arcane) traditional Unix utilities like sed and awk, etc.

I'm quite keen to follow your progress so do remember to keep us all informed from time to time :-).