OpenCL miner written in C

[tcatm]

Does not work with pools. Added poolmode (-m). Works best on 5870/5970 and SDK 2.1. Early development state. Patches welcome

552 Mhash/s on 5970 @ 725 MHz

https://github.com/tcatm/oclminer

This miner checks *all* solutions and doesn't throw away nonces like poclbm and DiabloMiner do to save bandwidth.

[1714170188]

1714170188

[1714170188]

1714170188

[1714170188]

1714170188

[1714170188]

1714170188

[Luke-Jr]

Unpatched, this gets me 124.5 MH/s on my Radeon HD 5850. With a patch from tcatm on IRC, I got up to 259.5 MH/s. Still short of m0m's 265 MH/s, but getting closer.

[m0mchil]

tcatm, thank you for this miner.

Just wanted to mention that since yesterday (Feb 4) poclbm and Diablo miners changed the way of getting kernel results back to host, reducing lost results to below 0.03% (or even less).

[tcatm]

Here's a copy of my hacked SDK: http://dl.dropbox.com/u/10284953/sdk2.1-hacked.tbz2

[tcatm]

Added poolmode (-m). Submits all H==0 results instead of only the best one.

[tcatm]

update: miner now measures effective hashrate by inspecting actual results returned by GPU (instead of counting kernel runs). Returned hashrate is reliable after approx. 30 min runtime

[dingus]

This miner checks *all* solutions and doesn't throw away nonces like poclbm and DiabloMiner do to save bandwidth.

Could you explain this to a layman? What is significant about this? Thank you. 

[tcatm]

This miner checks *all* solutions and doesn't throw away nonces like poclbm and DiabloMiner do to save bandwidth.

Could you explain this to a layman? What is significant about this? Thank you. 

poclbm and DiabloMiner only check some of the returned results form GPU hoping that the GPU will not find too many possible solutions. They improved that in recent versions, though. So my miner is a little bit (about 0.015%) faster. It also features a special pool mode because of this, which is much more efficient when using a pool.

[dingus]

This miner checks *all* solutions and doesn't throw away nonces like poclbm and DiabloMiner do to save bandwidth.

Could you explain this to a layman? What is significant about this? Thank you. 

poclbm and DiabloMiner only check some of the returned results form GPU hoping that the GPU will not find too many possible solutions. They improved that in recent versions, though. So my miner is a little bit (about 0.015%) faster. It also features a special pool mode because of this, which is much more efficient when using a pool.

When you refer to "pool" does that include say the two gpus in a 5970 that are "pooled" together?

[cdb000]

This miner checks *all* solutions and doesn't throw away nonces like poclbm and DiabloMiner do to save bandwidth.

Could you explain this to a layman? What is significant about this? Thank you. 

poclbm and DiabloMiner only check some of the returned results form GPU hoping that the GPU will not find too many possible solutions. They improved that in recent versions, though. So my miner is a little bit (about 0.015%) faster. It also features a special pool mode because of this, which is much more efficient when using a pool.

When you refer to "pool" does that include say the two gpus in a 5970 that are "pooled" together?

When the miner handles a block of work in standalone mining mode you are only looking for one hash that meets the current target. Once you have found this hash you have generated the block and mined 50 Bitcoins. (Yippee!) There is no point continuing with the current work after one hash has been found as we are all now looking for the next block.

When the miner handles a block of work in pooled mode you are looking for as many low difficulty hashes as possible to gain as many shares in the pool as possible. When you run your HD5870 over a block of work you want to send ALL the valid hashes it generates to the pool, not just the first one - it makes sense to continue working on a block of work even though a valid hash has been found because finding another hash will gain you another share in the pool most of the time. (most of the time because you might have found the hash that generates the block rendering any further hashes of the same block useless)

So, when mining with a 5970 you want choose pool mode if you are in a pool such as Slush's pool, and not when you are mining for yourself.

Hope this makes sense!

[dingus]

Ok, I see. Thanks for the clarification. 

[martok]

Hi,
Just starting to look at this code. Finally a miner written in C so I can understand it.

Anyways question about this pool mode idea. So, when in solo mode, I'm guessing we submit a block followed immediately by another getwork. What is the point in doing it this way when we could simply submit blocks as we do in pooled mode and let long-polling tell us when another block is ready?

Also, what does that hacked SDK of yours actually do?

[jgarzik]

Anyways question about this pool mode idea. So, when in solo mode, I'm guessing we submit a block followed immediately by another getwork. What is the point in doing it this way when we could simply submit blocks as we do in pooled mode and let long-polling tell us when another block is ready?

If you submitted a block in solo mode, then you presumably solved that block, meaning that a brand new block is ready and waiting for your next 'getwork'.

[kindle]

Hi I am trying to compile this using Borland compile in win 7. Reading tru online compilation guides I seem to have errors. Any thing I should take note of?

[FnuGk]

i get this error on osx (using either makefiles).

Code:

Last login: Sat Apr  9 19:22:53 on ttys002
Jespers-MacBook-Pro:~ jepper_broge$ cd /Users/jepper_broge/Downloads/tcatm-oclminer-80b2d6f 
Jespers-MacBook-Pro:tcatm-oclminer-80b2d6f jepper_broge$ make
gcc -c -I/usr/local/include -O3 -Wformat   -o miner.o miner.c
gcc -c -I/usr/local/include -O3 -Wformat   -o ocl.o ocl.c
gcc -c -I/usr/local/include -O3 -Wformat   -o findnonce.o findnonce.c
gcc -c -I/usr/local/include -O3 -Wformat   -o util.o util.c
util.c: In function ‘json_rpc_call’:
util.c:132: warning: passing argument 2 of ‘json_loads’ makes integer from pointer without a cast
util.c:132: error: too few arguments to function ‘json_loads’
make: *** [util.o] Error 1
Jespers-MacBook-Pro:tcatm-oclminer-80b2d6f jepper_broge$ 

[jgarzik]

i get this error on osx (using either makefiles).

Code:

util.c: In function ‘json_rpc_call’:
util.c:132: warning: passing argument 2 of ‘json_loads’ makes integer from pointer without a cast
util.c:132: error: too few arguments to function ‘json_loads’

You are using a too-recent version of jansson.  Either downgrade to 1.x, or add a '0' for the new flags parameter in 2.0.

[kindle]

You are using a too-recent version of jansson.  Either downgrade to 1.x, or add a '0' for the new flags parameter in 2.0.

Hi jgarzik sorry its my 1st time compiling, how do I include the 0 flag in the cygwin shell? make -o gives the same error 1.

[jgarzik]

You are using a too-recent version of jansson.  Either downgrade to 1.x, or add a '0' for the new flags parameter in 2.0.

Hi jgarzik sorry its my 1st time compiling, how do I include the 0 flag in the cygwin shell? make -o gives the same error 1.

You must (a) edit the source code to add a flags parameter to json_loads() function call, or (b) you must downgrade your jansson library to 1.x.

[kindle]

Hi jgarzik

I just found this string in the util.c json_loads(all_data.buf, &err), how do i add the flag here? So sorry i have no background in prog. Thanks alot for the guide =)

[trentzb]

Hi jgarzik

I just found this string in the util.c json_loads(all_data.buf, &err), how do i add the flag here? So sorry i have no background in prog. Thanks alot for the guide =)

json_loads(all_data.buf, 0, &err)