cgminer - CPU/GPU miner in C for linux/windows - page 10.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

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.

kripz

full member

Activity: 182

Merit: 100

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

Naven

newbie

Activity: 22

Merit: 0

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

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

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.

figvam

newbie

Activity: 42

Merit: 0

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

Quote

./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

legendary

Activity: 4088

Merit: 1631

Ruu \o/

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.

burp

member

Activity: 98

Merit: 10

Quote from: -ck on June 25, 2011, 05:38:12 AM

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 Shocked

I will investigate …

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: burp on June 25, 2011, 05:31:11 AM

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=, argv=) 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

member

Activity: 98

Merit: 10

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=, argv=) at cpu-miner.c:1365

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: -ck on June 25, 2011, 01:28:22 AM

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)

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

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

figvam

newbie

Activity: 42

Merit: 0

Quote from: -ck on June 24, 2011, 03:43:49 AM

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

legendary

Activity: 4088

Merit: 1631

Ruu \o/

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.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Thanks very much!

burp

member

Activity: 98

Merit: 10

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

legendary

Activity: 4088

Merit: 1631

Ruu \o/

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.

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: m3ta on June 24, 2011, 05:00:48 AM

Any plans for MacOS capabilities? (either binary or compilation-wise)?

The intention is for the code to be portable. That said I'll need help to ensure it really is cause there are always surprises moving from one OS to another.

m3ta

sr. member

Activity: 435

Merit: 250

Any plans for MacOS capabilities? (either binary or compilation-wise)?

-ck

legendary

Activity: 4088

Merit: 1631

Ruu \o/

Quote from: figvam on June 24, 2011, 03:25:50 AM

Quote from: -ck on June 24, 2011, 01:26:06 AM

Further to that thought, I've committed a change to the tree which should prevent 32 bit overflows.

And looks like it fixed the drops in hashrate reporting. Thanks!

Great, thanks for testing. 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.

figvam

newbie

Activity: 42

Merit: 0

Quote from: -ck on June 24, 2011, 01:26:06 AM

Further to that thought, I've committed a change to the tree which should prevent 32 bit overflows.

And looks like it fixed the drops in hashrate reporting. Thanks!

Topic: cgminer - CPU/GPU miner in C for linux/windows - page 10. (Read 81956 times)