Warning: Ethereum(ETH) will migrate to PoS(Proof of Stake) algorithm in near future, maybe in a year. So jumping into ETH mining now might not be profitable. Also, I encourage crypto mining with renewable energy sources and a Tesla PowerWall 2 is just a few RTX 3090s away :)
Note: This is a follow-up for my previous post on Ethereum mining with AMD 6600 XT on Ubuntu. If you haven’t got your 6600 XT mining on Ubuntu yet, please refer the post first.
I ordered 2 AMD 6600 XTs back in August and tried do Ethereum mining with them. I managed to mine with 1 of them even if both were visible in the system. I raised support ticket with AMD and the answer was far less than satisfying:
“yes, it is expected behavior although you use 2 RX 6600 XT cards clinfo you can use only 1 opencl available platform.”AMD Global Customer Care
I almost gave up on AMD, planned to sell those 6600 cards on eBay. However, huge thanks to Google search this Reddit thread was brought to my attention.
TL;DR: the ‘culprit’ is not AMD driver itself but the bundled OpenCL libraries and according to the thread bundled OpenCL from an older version(20.40) can support multiple 6600 XTs for mining. Thanks to the OP for this good news!
Definitely I would like to verify this grafting method but it does require a lot of steps:
- downgrade Linux kernel
- change grub settings to boot to the older kernel
- install amdgpu-pro driver version 20.40
- save the /opt/amdgpu-pro/lib/x86_64-linux-gnu directory
- uninstall driver 20.40
- boot back to latest kernel
- install driver 21.30
- point /opt/amdgpu-pro/lib/x86_64-linux-gnu directory to the 20.40 backup directory
- test with clinfo
Looking at my current driver library(version 21.30) directory:
lrwxrwxrwx 1 root root 21 Jul 28 11:02 libamd_comgr.so.2 -> libamd_comgr.so.2.1.0 -rw-r--r-- 1 root root 120M Jul 28 11:02 libamd_comgr.so.2.1.0 lrwxrwxrwx 1 root root 16 Jul 28 11:02 libamdhip64.so -> libamdhip64.so.4 lrwxrwxrwx 1 root root 25 Jul 28 11:02 libamdhip64.so.4 -> libamdhip64.so.4.2.21303- -rw-r--r-- 1 root root 2.8M Jul 28 11:02 libamdhip64.so.4.2.21303- -rw-r--r-- 1 root root 1.4M Jul 28 11:02 libamdocl64.so -rw-r--r-- 1 root root 93M Jul 28 11:02 libamdocl-orca64.so -rw-r--r-- 1 root root 216K Jul 28 11:02 libcltrace.so -rw-r--r-- 1 root root 1.8M Jul 28 11:02 libhiprtc-builtins.so.4.2 lrwxrwxrwx 1 root root 25 Jul 28 11:02 libhsa-runtime64.so.1 -> libhsa-runtime64.so.1.3.0 -rw-r--r-- 1 root root 2.5M Jul 28 11:02 libhsa-runtime64.so.1.3.0 lrwxrwxrwx 1 root root 16 Jul 28 11:02 libOpenCL.so.1 -> libOpenCL.so.1.2 -rw-r--r-- 1 root root 35K Jul 28 11:02 libOpenCL.so.1.2
“What are these .so files?” I can imagine someone might ask. The .so files are
shared objects in Linux systems, which are usually pre-compiled binaries. According to the OP swapping these out with the ones from version 20.40 fixed the issue, so I presume these binaries are not tightly coupled with AMD’s kernel modules. In that case if I can simply extract those relevant files from the 20.40 package I might not need to do all those kernel version switcheroos.
Here are my steps(bash commands):
# assuming version 20.40 has been downloaded to current directory tar xvf amdgpu-pro-20.40-1290604-ubuntu-20.04.tar.xz ... # get into the 20.40 directory cd amdgpu-pro-20.40-1147286-ubuntu-20.04 # there are dozens of .deb packages in a release, I simply extract all of them for i in *.deb; do dpkg-deb -xv $i ./deb-files; done ... # the relevent files are in ./deb-files/opt/amdgpu-pro/lib/x86_64-linux-gnu ls -lht ./deb-files/opt/amdgpu-pro/lib/x86_64-linux-gnu total 453M lrwxrwxrwx 1 root root 21 Oct 15 14:23 libamd_comgr.so.1 -> libamd_comgr.so.1.7.0 lrwxrwxrwx 1 root root 19 Oct 15 14:23 libamfrt64.so.1 -> libamfrt64.so.0.0.0 ... # I believe not all files are needed but saving a few hundred MBs is not the priority here # move this directory to amdgpu-pro installation directory sudo mv ./deb-files/opt/amdgpu-pro/lib/x86_64-linux-gnu /opt/amdgpu-pro/lib/x86_64-linux-gnu-20.40 # rename current 21.30 library directory cd /opt/amdgpu-pro/lib sudo mv x86_64-linux-gnu x86_64-linux-gnu-21.30 # use 20.40 as current library sudo ln -s /opt/amdgpu-pro/lib/x86_64-linux-gnu-20.40 /opt/amdgpu-pro/lib/x86_64-linux-gnu # refresh library cache sudo ldconfig # check links ls -lht /opt/amdgpu-pro/lib total 8.0K drwxr-xr-x 3 ray ray 4.0K Oct 15 14:23 x86_64-linux-gnu-20.40 lrwxrwxrwx 1 root root 42 Oct 15 14:22 x86_64-linux-gnu -> /opt/amdgpu-pro/lib/x86_64-linux-gnu-20.40 drwxr-xr-x 2 root root 4.0K Sep 12 22:07 x86_64-linux-gnu-21.30
Does this really work? Only need to find out with
clinfo -l Platform #0: AMD Accelerated Parallel Processing +-- Device #0: gfx1032 `-- Device #1: gfx1032
Success!! But to get the teamredminer working properly, I still did a reboot. Here’s the result(I didn’t OC, so laugh at my MHps please)
[2021-10-15 21:02:23] GPU 0 [62C, fan 30%] ethash: 28.44Mh/s, avg 28.42Mh/s, pool 25.68Mh/s a:122 r:0 hw:0 [2021-10-15 21:02:23] GPU 1 [57C, fan 20%] ethash: 28.45Mh/s, avg 28.40Mh/s, pool 32.63Mh/s a:155 r:0 hw:0 [2021-10-15 21:02:23] Total ethash: 56.89Mh/s, avg 56.82Mh/s, pool 58.32Mh/s a:277 r:0 hw:0
Strangely the rocm-smi command I used to limit power consumption to 55W doesn’t see the second card. So I have to change the power profile for the 2nd card to save some power
# this sets the 2nd card to 64W and same MHps as the 1st card echo "profile_standard"| sudo tee /sys/class/drm/card1/device/power_dpm_force_performance_level