This post is a follow-up to a question posted by Anton on my earlier article about setting up the ODROID-XU4 as a Burstcoin mining rig. Anton asked if the ODROID-XU4 could handle running creepMiner with OpenCL, and as it turns out, yes it can!
If you look at the ODROID specs on the Hardkernel site, you’ll see that it supports OpenCL 1.2 Full profile. This means I should be able to run creepMiner in that configuration. You can see in the creepMiner documentation that it supports SSE4, AVX, AVX2, CUDA and OPENCL (and also SSE2 as a default).
What is OpenCL? According to the Khronos Group, “OpenCL™ (Open Computing Language) is the open, royalty-free standard for cross-platform, parallel programming of diverse processors found in personal computers, servers, mobile devices and embedded platforms.”
On the ODROID, this means that it’s GPU (Mali-T628) is capable of running OpenCL, which should be a good improvement over the CPU capabilities.
Enough about that! On with the testing!
To verify that the GPU is actually OpenCL compatible, open up a terminal window and install clinfo. This gives information on the compatible devices on the machine.
Switch over to the root user “su root” and enter the password (odroid is the default). Now install clinfo.
apt install clinfo
After that installs, run the command.
clinfo
Running clinfo for the first time
Wait a second, that doesn’t seem right! Running clinfo returns “Number of platforms 0”.
As it turns out, the libraries to use aren’t installed. I found a great forum post that explains the problem and solution: https://forum.odroid.com/viewtopic.php?f=95&t=30141
To bottle it down, here are the steps:
apt-get install mali-fbdev clinfo mkdir /etc/OpenCL mkdir /etc/OpenCL/vendors echo "/usr/lib/arm-linux-gnueabihf/mali-egl/libOpenCL.so" > /etc/OpenCL/vendors/armocl.icd
This will install the mali-fbdev library for the Mali-T628 that the ODROID uses, and set it up in a folder that OpenCL can see.
Now, running clinfo I can successfully see the compatible device. Now we’re making progress!
Platform Name ARM Platform Number of devices 2 Device Name Mali-T628 ...
The next step is to get creepMiner working in OPENCL mode. For this test I’m going to be using a slightly older version because 1.8 has some extra features that slow the lil ol ODROID down. It also needs to be manually compiled since creepsky doesn’t release 32 bit versions.
If you need a refresher on how to compile creepMiner, check out the documentation, or my older post on setting up the ODROID-XU4 as a Burstcoin miner.
The options to use in the Make process are:
cmake CMakeLists.txt -DCMAKE_BUILD_TYPE=RELEASE -DUSE_SSE4=OFF -DUSE_AVX=OFF -DUSE_AVX2=OFF -DUSE_CUDA=OFF DUSE_OPENCL=ON
This should compile just fine and give you an OpenCL version to use! You’ll notice that it actually names the file creepMiner-opencl for you.
Next, the configuration file needs to change a little from the previous version. In your mining.conf file, find the line for “processorType” and set it to “OPENCL”. The “gpuDevice” and “gpuPlatform” settings can remain 0 and the “cpuInstructionSet” can stay “AUTO” since we’re not changing any CPU settings.
Save that and start her(him?) up!
./creepMiner-opencl
Errors Will Robinson!
At this point, I was running the correct version of the program, with the correct settings, but it wasn’t working! creepMiner gives the error:
Could not initialize OpenCL - the kernel file is missing!
Miner Without OpenCL
As it turns out, this is a pretty simple fix. Grab the mining.cl file from src/shabal/opencl/mining.cl and drop it in the same folder that has the executable.
Now run it again.
Miner With OpenCL
It’s working now! You can see creepMiner successfully initialized OpenCL!
The Results
At this point, I was expecting some sort of lightspeed processing times… but that just did NOT happen. My normal read times for the 22.28TB is around 70 seconds with the CPUs. OpenCL is consistently getting a time in the 85 second range.
My OpenCL results
Aaand it crashes as well. Apparently the memory limits don’t apply for this configuration. Looking at the System Monitor in Ubuntu, I can see the memory top out and the process is killed.
System Monitor Mining With GPU – note the drop off when it crashes
Compare this with the CPU version. Even though my memory max is set at 1536 MB, it doesn’t really use all of that.
Mining with CPU pegs out the processors, but not the memory
My Conclusion
Based on these initial results (and a few tests tweaking the settings), I don’t see any solid improvements in using the GPU on the ODROID over the 8 CPUs. If there were less CPUs it would probably make sense, but I don’t think the GPU can keep up with all 8.
If anyone else has better results or suggestions, feel free to post a comment below.
The POCC just released their own miner, which they state is the fastest miner ever, so I’ll be giving that a try next. Unfortunately they don’t have 32bit compatible code.. so it might take some work to actually get that one running. Stay tuned!
Nice! Did you play with “intensity” value? Right now I am working on NEON support of creepMiner (look at Pull Requests), but for some reason still see no difference with generic CPU version. My timing is 30 sec for reading 1/4096 of 8TB and 37 sec for processing it with intensity=8.
Hi Anton, thanks for reading! I would love to see any results you have with the NEON instructions. I tried a version of creepMiner with NEON added in, but so far it either just errors out or doesn’t compile for me. I’ve tried simple compile flags and a header file that supposedly ports some SSE functions over: https://github.com/jratcliff63367/sse2neon (I’m actually trying this on the new Scavenger miner as well.) No good results so far. I just haven’t had the time to fully debug.
For creepMiner, I’ve tried all sorts of combinations of plot readers & intensity. What works the best for me is intensity: 8, max readers: 0 (auto) with a max buffer size of 1536. With OpenCL, I wasn’t able to find a setting that performed better than the CPUs, but if I do, I’ll update the post.