Sure. First, the team number I quoted is from the opensuse wiki. Second, using the GPU is far preferable. Using the steps I posted, it’s possible to tinker to get it to work. It’s not all about mindlessly folding, no. I’d like to get it working more efficiently.
You can use GPU inside the docker as well. For example if you look at the docker file I posted it’s built on:
FROM nvidia/cuda:10.1-base-ubuntu16.04
And it installs cuda drivers:
RUN apt-get install -y --no-install-recommends apt-utils bzip2 nano cron rsync ocl-icd-opencl-dev=2.2.8-1 cuda-drivers=418.87.01-1
You just need to make sure that the drivers that are installed inside the docker image work with your GPU. For nvidia GPU verifying the output of the following command from inside the docker is usually enough:
nvidia-smi
There are other approaches as well where you mount the GPU device of your host OS inside the docker container. Some more information about this:
This is only for nvidia hardware (I have no idea how that works with AMD).
The link I posted includes vague instructions for AMD GPU (as well as nVidia) support.
Here it is again
https://foldingathome.org/support/faq/installation-guides/linux/requirements/
Summarizing the instructions which is not much more than what is on the page…
- Install GPU support in your distro following the instructions for your GPU.
- Download and install the FAH components appropriate for your GPU. Note that the components are generally written for a particular version “and later” which possibly suggests that earliest FAH components can be used for all current GPUs from that manufacturer but later versions might be optimized better.
The documentation goes on to accuse AMD of not supporting OpenCL well.
I have no experience with that (Maybe Malcolm can comment since his work creating packages that run on GPUs is based on his own personal equipment which is AMD) but had not heard that AMD is lacking… only that possibly the OpenCL approach generally does not likely try to take advantage of specific AMD GPU features.
It should be noted that the world’s fastest supercomputers a few years ago were built using off the shelf AMD GPUs (Yes, even rumored to be exactly the same you might find in a gaming PC). Of course, benchmark tests are not the same as real world apps, but still… It means that a substantial amount of supercomputer work in China is likely using the same OpenCL average hobbyists and researchers use.
TSU
Hi
From AMD perspective it’s only been with lc0 and seeing vulkan works, my dual AMD setup has been sequestered by my wife for work and is currently on winX… rest has been with nvidia (cheap cards GT710’s) for testing and running boinc/blender/qemu etc.
So, as I understand it the problem is that one needs to install amdgpu-pro because amdgpu lacks several files (and opencl 1.2 support) that software like F@H and Boinc search for during startup. Apparently there are ways around this in package form
https://aur.archlinux.org/packages/opencl-amd/
that installs the necessary components and keeps FOSS amdgpu intact. Seems they were successful at getting Boinc working with AMD GPU’s.
https://boinc.berkeley.edu/forum_thread.php?id=11417&sort_style=&start=20
Or, maybe, it’s possible to download amdgpu-pro for sles, untar it, and install using:
./amdgpu-pro-install --opencl=legacy,pal --headless
to get the same results…
Took a look at this.
For installing AMD GPU support (not including FAH)
Looks like available information from AMD was written by someone who only knew Linux generically, produced some steps and then people created SUSE/openSUSE documentation from the AMD info in a mechanical way.
In other words, I don’t think anyone really knew what they were doing, probably didn’t understand what they were writing but felt that reproducing what was supposed to be official was the safest way to go.
The following attempts to eliminate what I consider useless or unhelpful steps, for instance I don’t know of any reason to configure a repository for an archive file when it’s not a package.
My biggest gripe with AMD is that they seem to make their software and drivers very specific to individual GPUs and discoverable/downloadable only through their website, not by a configurable repository (there are many traditional types… ftp, http, git, svn, etc). This means that there is no means to automatically update, and any update is likely an upgrade (complete replacement which may require removing any prior install and setup).
There are SDB for amdgpu, amdgpu-pro, various SUSE/openSUSE wiki documentation and github documentation, the following is intended to be superior and should supersede all previous documentation… But at the moment this is initially published, all needs to be tested and verified.
Additionally, as of today the very latest installation documentation available is out of date, referring to drivers and software released July 2019, while I found drivers and software released Feb 2020.
Anyway, here we go…
Based on the AMD general recommendation to download and install SLES/SLED archives… Since LEAP 15, this should generally mean that the latest LEAP and likely Tumbleweed should be supported by installing SLED/SLES archives. You may have problems if you are running an older version of LEAP (and unsupported by openSUSE, so upgrade!)
- Using your web browser, go to the following AMD webpage and download the drivers and software appropriate for your GPU. If you don’t know your GPU, there is AMD software you can install that can detect your hardware for you. Be sure to download the archive for SLED/SLES, not Ubuntu or anything else. If you aren’t sure, post a question in the Forums and someone can recommend an alternative archive if necessary (likely Fedora if available. RHEL might work, but is more likely going to have issues)
https://www.amd.com/en/support
- Typically, most web browsers will download the files to ~/Downloads but can be different, particularly if you are for instance running only a Window Manager and not a full Desktop Environment in which you would then have to create a folder for your downloads which can be anything you specify. Extract the files using tar, the following command is recommended, just point to your downloaded archives (package_name)
tar -Jxvf *package_name *
- Install by executing the binary from the extracted archive as described below. If for some reason you’re installing an old package because you’re running an old, unsupported openSUSE/SLED/SLES(shame on you for not upgrading), the binary may be named something similar but different.
./amdgpu-install
That’s all!
Reboot and verify.
Some references in various SDB documentation which may be helpful if you run into issues…
https://en.opensuse.org/SDB:AMDGPU
Describes manually installing firmware. Hopefully nowadays that’s not necessary, should all be automated with every system update and reboot
https://en.opensuse.org/SDB:Configuring_graphics_cards
Typical boot configurations which can be tried, particular note is nomodeset to recover to the generic driver if your newly installed driver results in a black screen.
https://en.opensuse.org/SDB:AMD_graphics_troubleshooting
Don’t know how useful this info can be, assumes you’re not running Wayland.
If what I described proves to work,
Then either existing SDB can be updated or replaced (anyone can do that).
HTH,
TSU
At least according to the available documentation, the archive names and commands “amdgpu” and “amdgpu-pro” are without meaning… at various times archives have been named either way but one is not “more” than the other, so the important thing to do is download and install whatever is appropriate for your GPU regardless how it’s named exactly (currently all latest is supposed to be simply “amdgpu”).
TSU
It’s all very confusing…
Anyway, I tried the methods in the links I wrongly posted above with BOINC. I’m currently folding for COVID-19 and uploading completed and verified tasks. I don’t know what the GPU is doing, since I don’t know of a monitoring tool for the proprietary driver and i’m nowhere near the computer itself, but boinccmd --get_state reports total_gpu_active_duration: at 3367037.819194 and climbing. 
For AMD GPU use ROCm:
https://rocm-documentation.readthedocs.io/en/latest/Installation_Guide/Installation-Guide.html#sles-15-service-pack-1
You may use “OpenCL-only Installation of ROCm”:
Performing an OpenCL-only Installation of ROCm
Some users may want to install a subset of the full ROCm installation. If you are trying to install on a system with a limited amount of storage space, or which will only run a small collection of known applications, you may want to install only the packages that are required to run OpenCL applications. To do that, you can run the following installation command instead of the command to install rocm-dkms.
sudo yum install rock-dkms rocm-opencl-devel
“sudo yum install” -> “zypper in”.
With an old hardware you may install OpenCL part of an AMDGPU-PRO drivers.
Mesa 3D OpenCL drivers seems not working.
Interesting thread. Thanks Knurpht. This offers the most pragmatic option for many I would think. I’ve just set it up in about 2mins. 
I’ve created 3 packages for Tumbleweed. 2 of them download the RH-rpms from the FAH website, unpack and install the files just like fetchmsttfonts is doing. Moreover, I’ve created a decent service file. It runs the closed source binaries as restricted user. It’s running great on my PC with the Nvidia driver.
https://repo.bheld.de/fah-suse.repo
Feedback is welcome 
Have fun
Berny
Very cool. Sounds like it’s ideal for anyone with an nVidia GPU.
TSU
I would be happy if anyone with an AMD GPU could test as well.
Berny
I found a solution, created an account to post my solution.
What didn’t work for me:
- Downloading the rpm and opening it with the default program “Discover Software Center”
- Downloading the rpm and right click open with “YaST Software”
- Someone said snap worked for them, but I couldn’t figure out how to successfully get snap to successfully install on OpenSUSE TW 15.3
- Someone said docker worked for them, but I installed trivy the free vulnerability scanner from aquasec and decided against it due to the number of vulnerabilities, plus it didn’t look crazy straight forward.
What worked for me:
Download the official rpm and install it using zypper via cli
sudo zypper install fahclient-7.6.21-1.x86_64.rpm
It gave me useful error messages that the GUI installers didn’t mention, it complained that bzip2 was missing and bzip2 library were missing. I googled how to install both only to find that both were already installed. I then theorized that the rpm was optimized for RHEL and was trying to detect where bzip2 is installed on a RHEL OS, and theorized that maybe bzip2 is installed somewhere else on OpenSuse and the auto detection of dependency correctly installed was faulty.
When running the zypper install it gave me the option to install fahclient without the dependencies with the understanding that it might break, I said yes, it then mentioned my system didn’t have fah’s gpg key, so it didn’t recognize the rpm as signed, I said ignore the fact that it’s not signed (I downloaded it directly from their website so I trusted it.) I then went to https://client.foldingathome.org/ (which is a website to check your local folding, and it’s working perfectly.)
Update the solution that worked for me didn’t work for long / I don’t recommend it.
I mentioned in the post above that I found a working solution, that involved ignoring what looked like false error messages, and it worked.
I forget what exactly I did (maybe a reboot?), but eventually after verifying client.foldingathome.org was working, I checked it again a few days later and I saw it stopped working. I tried to soft reset it by zypper uninstall and reinstall, but because I ignored the error messages on install the uninstaller logic refused to run, and it ended up in a broken state that I didn’t know how to fix or reset.
(In the end I ended up uninstalling TW and reinstalling Ubuntu, which works well enough for me. Glad I looked at TW though, because I’m starting to check out Micro OS for server, so it was good I got familiar with the zypper install command syntax)