cgminer - CPU/GPU miner in C for linux/windows

[-ck]

Updated tree - I've modified work submission to spawn a separate thread of its own now which prevents miner threads from stalling when submitting work to slow pools.

[burp]

Here is my quick fix for multi gpu initialization:

Code:

-               clState->program = clCreateProgramWithBinary(clState->context, numDevices, &devices[gpu], binary_sizes, (const unsigned char **)binaries, &status, NULL);
+               clState->program = clCreateProgramWithBinary(clState->context, 1, &devices[gpu], &binary_sizes[gpu], (const unsigned char **)&binaries[gpu], NULL, &status);

[-ck]

Thanks very much!

[-ck]

Updated tree - I've made the getting of work more asynchronous by always having one work item extra in the queue. This means it is much less likely to get a drop in hash rates when connecting to a slow pool. This is particularly useful if you are on one side of the world and the pool you connect to is on the other side.

[figvam]

It would be interesting to see how the throughput on yours compares if you leave your machine idle for an hour or so. minerd is very sensitive to user activity.

It doesn't seem to make a difference for the GPU mining. The hash rate is at the very steady 17.39-17.40 Mh/sec. It still almost twice as slower as poclbm/phoenix.

[-ck]

Thanks. I'll implement the ability to override vectors and worksize to see if you can get good throughput by manually setting those.

[-ck]

Thanks. I'll implement the ability to override vectors and worksize to see if you can get good throughput by manually setting those.

Updated tree: Configurable vector width and worksize, more multi-gpu fixes and minor cleanups.

minerd now supports the following options:
--vectors N (where N is 1, 2 or 4)
--worksize N (where N is any number supported by the hardware up to max_work_size as reported when minerd is run with -D; usually up to 512)

[burp]

Newest version segfaults for me at 2nd GPU initialization:

[2011-06-25 12:28:26] Selected 1: Cypress
[2011-06-25 12:28:26] Initialising kernel with BFI_INT patching, 4 vectors and worksize 64

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff745189b in memchr () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x00007ffff745189b in memchr () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff7458b8a in memmem () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x0000000000405d07 in advance (area=0x7fffffffe940, remaining=0x7fffffffe948, marker=0x421919 ".text") at ocl.c:102
#3  0x0000000000406475 in initCl (gpu=1, name=0x1cb7080 "", nameSize=16) at ocl.c:405
#4  0x0000000000402822 in main (argc=<value optimized out>, argv=<value optimized out>) at cpu-miner.c:1365

[-ck]

Newest version segfaults for me at 2nd GPU initialization:

[2011-06-25 12:28:26] Selected 1: Cypress
[2011-06-25 12:28:26] Initialising kernel with BFI_INT patching, 4 vectors and worksize 64

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff745189b in memchr () from /lib/x86_64-linux-gnu/libc.so.6
(gdb) bt
#0  0x00007ffff745189b in memchr () from /lib/x86_64-linux-gnu/libc.so.6
#1  0x00007ffff7458b8a in memmem () from /lib/x86_64-linux-gnu/libc.so.6
#2  0x0000000000405d07 in advance (area=0x7fffffffe940, remaining=0x7fffffffe948, marker=0x421919 ".text") at ocl.c:102
#3  0x0000000000406475 in initCl (gpu=1, name=0x1cb7080 "", nameSize=16) at ocl.c:405
#4  0x0000000000402822 in main (argc=<value optimized out>, argv=<value optimized out>) at cpu-miner.c:1365

Thanks. Has it ever actually worked for you with the 2nd GPU? The fix you posted earlier did not help others (on IRC) who had more than one GPU, if BFI_INT patching was involved. I don't think I've quite got the right fix for that yet, but it's at the top of my bug list to fix :|

[burp]

Thanks. Has it ever actually worked for you with the 2nd GPU? The fix you posted earlier did not help others (on IRC) who had more than one GPU, if BFI_INT patching was involved. I don't think I've quite got the right fix for that yet, but it's at the top of my bug list to fix :|

Um, right now I can't make it work again  I will investigate …

[-ck]

Updated tree.

Thanks to burp, I now have a fix for building BFI_INT patched kernels on multi-gpu set ups. 32 bit machines don't get work with bfi int patching.

No CPU mining threads are now started if any GPUs are detected.

The CPU threads option has been changed to:
--cpu-threads

There is now a new option:
--gpu-threads N
(-g N) Number of threads per-GPU (1 - 10, default: 2)

By default it now spawns 2 threads per GPU to keep them slightly more busy for better throughput.

Numerous other cleanups have gone into it.

STILL TODO:
Performance for some GPUs is still well down that of other GPU mining software, and I'm still investigating why that is.
Implement BFI INT patching for 32 bit builds.
...
Profit.

[figvam]

Here's a new error (warning?) from the latest version:

./minerd  --intensity 2 --url http://mineco.in:3000 xxxxx
[2011-06-26 09:40:52] Init GPU thread 0
[2011-06-26 09:40:52] List of devices:
[2011-06-26 09:40:52]   0       ATI RV730
[2011-06-26 09:40:52] Selected 0: ATI RV730
[2011-06-26 09:40:52] Initialising kernel without BFI_INT patching, 4 vectors and worksize 32
[2011-06-26 09:41:24] initCl() finished. Found ATI RV730
[2011-06-26 09:41:24] Init GPU thread 1
[2011-06-26 09:41:24] List of devices:
[2011-06-26 09:41:24]   0       ATI RV730
[2011-06-26 09:41:24] Selected 0: ATI RV730
[2011-06-26 09:41:24] Initialising kernel without BFI_INT patching, 4 vectors and worksize 32
[2011-06-26 09:41:24] Long-polling activated for http://mineco.in:3000/LP
[2011-06-26 09:41:48] [0.02 | 0.02 Mhash/s] [0 Accepted] [0 Rejected]
[2011-06-26 09:41:53] [17.25 | 1.47 Mhash/s] [0 Accepted] [0 Rejected]
[2011-06-26 09:41:58] [17.07 | 2.68 Mhash/s] [0 Accepted] [0 Rejected]
[2011-06-26 09:42:03] [17.02 | 3.71 Mhash/s] [0 Accepted] [0 Rejected]
[2011-06-26 09:42:04] initCl() finished. Found ATI RV730
[2011-06-26 09:42:04] 2 gpu miner threads started
[2011-06-26 09:42:04] 0 cpu miner threads started, using SHA256 'c' algorithm.
[2011-06-26 09:42:04] GPU 0 found something?
[2011-06-26 09:42:04] No best_g found! Error in OpenCL code?
[2011-06-26 09:42:04] GPU 0 found something?
[2011-06-26 09:42:04] No best_g found! Error in OpenCL code?
[2011-06-26 09:42:04] GPU 0 found something?
[2011-06-26 09:42:04] No best_g found! Error in OpenCL code?
[2011-06-26 09:42:04] GPU 0 found something?
[2011-06-26 09:42:04] No best_g found! Error in OpenCL code?
[2011-06-26 09:42:04] GPU 0 found something?
[2011-06-26 09:42:04] No best_g found! Error in OpenCL code?
[2011-06-26 09:42:04] GPU 0 found something?
[2011-06-26 09:42:04] No best_g found! Error in OpenCL code?
[2011-06-26 09:42:04] GPU 0 found something?
[2011-06-26 09:42:04] No best_g found! Error in OpenCL code?
[2011-06-26 09:42:04] GPU 0 found something?
[2011-06-26 09:42:04] No best_g found! Error in OpenCL code?
[2011-06-26 09:42:09] [19.84 | 19.84 Mhash/s] [0 Accepted] [0 Rejected]
[2011-06-26 09:42:14] [17.30 | 18.60 Mhash/s] [0 Accepted] [0 Rejected]
[2011-06-26 09:42:19] [17.34 | 18.19 Mhash/s] [0 Accepted] [0 Rejected]
[2011-06-26 09:42:24] [17.61 | 18.04 Mhash/s] [0 Accepted] [0 Rejected]
[2011-06-26 09:42:29] [17.61 | 17.96 Mhash/s] [0 Accepted] [0 Rejected]
[2011-06-26 09:42:35] [17.62 | 17.90 Mhash/s] [0 Accepted] [0 Rejected]

and it continues from here normally.

[-ck]

Thanks, that's a bug on initialisation and is harmless. I'll see if I can avoid it in the future. I just wish I could figure out this 1/2 performance issue first.

[Naven]

@ckolivas, maby u should upload daily builds or something like that for more people to contribute (i see potencial in this minner)

[kripz]

Am i the only one having trouble compiling with debian 6? Will post logs when i get the chance.

[-ck]

Updated the tree:
Curl would crash if multiple instances are run at once from separate threads (seems to be a libcurl bug) so I've gone back to one instance of curl and pushed the threaded work submission / retrieval to a different place to still be non-blocking.
Updated the postcalc testing of nonces from GPUs to be done non-blocking in their own thread.
Further optimised the work loop.
Passed a fresh output buffer before the kernel is instantiated instead of after (could have led to stale blocks).
Patch source for BITALIGN separately from BFI_INT so that if bfi int binary patching fails, the kernel can be rebuilt without trying to BFI INT patch, but still benefit from bitalign on hardware that supports it. This means that 32 bit machines which were failing will at least work now with minerd, but with only part of the performance advantage available.

STILL TODO:
Performance for some GPUs is still well down that of other GPU mining software, and I'm still investigating why that is.
Implement BFI INT patching for 32 bit builds.
...
Profit.

[-ck]

Updated tree.

32 bits and BFI int patching is now working. For some reason on 64bit the opencl compiler builds an elf file within an elf file but not so on 32 bits. Go figure.

STILL TODO:
Testing and performance evaluation.
Windows builds (getting help from someone there hopefully it works).

[figvam]

This small mod to the poclbm OpenCL kernel gives about 3% more performance if BFI_INT is used:
https://forum.bitcoin.org/index.php?topic=22965.0;topicseen

  #define Ma(x, y, z) amd_bytealign((y), (x | z), (z & x))
and change it to this line
  #define Ma(x, y, z) amd_bytealign( (z^x), (y), (x) )

[-ck]

This small mod to the poclbm OpenCL kernel gives about 3% more performance if BFI_INT is used:
https://forum.bitcoin.org/index.php?topic=22965.0;topicseen

  #define Ma(x, y, z) amd_bytealign((y), (x | z), (z & x))
and change it to this line
  #define Ma(x, y, z) amd_bytealign( (z^x), (y), (x) )

For some reason that's greatly increased my reject rate.

[-ck]

This small mod to the poclbm OpenCL kernel gives about 3% more performance if BFI_INT is used:
https://forum.bitcoin.org/index.php?topic=22965.0;topicseen

  #define Ma(x, y, z) amd_bytealign((y), (x | z), (z & x))
and change it to this line
  #define Ma(x, y, z) amd_bytealign( (z^x), (y), (x) )

For some reason that's greatly increased my reject rate.

Actually that was sheer coincidence. I'll test this change some more, thanks!