python OpenCL bitcoin miner

[farmer_boy]

I managed to get mine to "work" too. I get less hashes out of my graphics card (1400k/s) than from the CPUs (1800k/s). I am also running X, so maybe that matters (but I doubt that).

Why are the AMD GPUs so much faster for this kind of work? From the numbers I have seen in this thread they are truly crushing nvidia. Are the nvidia cards better at doing floating point computations (or at least _something_) or are they basically just obsolete? 

[LobsterMan]

LobsterMan what the hell kind of graphics card are you running to get those numbers? 

I run 2 GTX275's, but I think that for some reason, when I specify -v it displays the cumulative hashes as the rate/sec, which is obviously incorrect. It crashes within 10-15 seconds anyway, so I guess nvidia cards just don't play nice with vectors...

[laanwj]

You probably get the same result if you remove the GPU kernel call completely

I still remember when I was tweaking m0mchil's miner in the hope I could make it somewhat faster on NVidia, once I had that magnificent amount of hashes too I thought w000t. Then I saw the compile error at the top

Compilation fails with vectors...

[LobsterMan]

Just took the time to write up a long post on how to get this working in windows (complete step by step guide)

http://www.newslobster.com/random/how-to-get-started-using-your-gpu-to-mine-for-bitcoins-on-windows

Feel free to add it to the first post or tell your friends or spam this link all over the internet 

[btchris]

I've run into this using the latest (20101126) miner executable under windows. I've also seen it once before using an earlier version, I believe 20101102. The miner seems to run fine for a while, and then this error comes up, and the miner exits. Any thoughts? Anything about my setup I can provide to help?

sys:1: DeprecationWarning: struct integer overflow masking is deprecated
Traceback (most recent call last):
  File "poclbm.py", line 140, in <module>
  File "pyopencl\__init__.pyc", line 205, in kernel_call
OverflowError: long int too large to convert

P.S. m0mchil, I can't find a donation address for you... if you had one in your sig, it would be much easier to bribe you for support 

[m0mchil]

Thanks David. I forgot to remove that one and now I am unable to remove your quote of it 

btchris, please send me a personal message. Since your are using the 'compiled' version (and nobody reported such problem recently with it) I want to know what is your GPU and how do you start poclbm (what parameters you use).

[remyroy]

This is pretty nice and workly correctly for me.

With Bitcoin UI using my CPU (Intel Core 2 Quad Q6600: 4 cores at ~3GHz), I get about 5200 khash/s.
With my Radeon HD 5830 GPU (~800MHz - 1GiB of memory), I get about 200500 khash/s.

This is on Windows 7 64 bits with Bitcoin 0.3.17 and poclbm_py2exe_20101126.

Thanks and keep up the good work!

[mikegogulski]

Tried this out for fun on Amazon EC2, on a GPU instance described as:

Cluster GPU Quadruple Extra Large 22 GB memory, 33.5 EC2 Compute Units, 2 x NVIDIA Tesla “Fermi” M2050 GPUs, 1690 GB of local instance storage, 64-bit platform, 10 Gigabit Ethernet

For $2.10/hour. Fought like hell to finally get it working.

Code:

[root@ip-10-17-129-89 m0mchil-poclbm-db8597c]# python poclbm.py 
No device specified, you may use -d to specify ONLY ONE of the following

Choose device(s):
[0] <pyopencl.Device 'Tesla M2050' at 0x17927d90>
[1] <pyopencl.Device 'Tesla M2050' at 0x17927de0>
Choice, comma-separated [0]:0,1
53481 khash/s

With -v it runs at about 32Mhash/s.

http://www.alloscomp.com/bitcoin/calculator.php tells me that generating a block is going to cost about $378 at this rate, and take a week on average.

Needless to say, I shut it off If something 27x faster becomes available, that's breakeven.

Very nice work on the project, though, m0mchil.

[BitLex]

thanks for trying,
nice to know that it's worthless.

even a HD5570 is faster than that (mine does 64M) and can run a few years for $378. 

[m0mchil]

Thanks Mike!

Could you  please try to run it on a single device? Or use '-d 0' and '-d 1' in two separate processes. poclbm is not optimized to run on more than one device (needs to maintain different queues to avoid choking one or the other). Perhaps there's better way to do this, don't know.

Anyway, even if you manage to get more of them it won't be 27x.

[mikegogulski]

Thanks Mike!

Could you  please try to run it on a single device? Or use '-d 0' and '-d 1' in two separate processes. poclbm is not optimized to run on more than one device (needs to maintain different queues to avoid choking one or the other). Perhaps there's better way to do this, don't know.

Anyway, even if you manage to get more of them it won't be 27x.

Code:

[root@ip-10-17-144-204 m0mchil-poclbm-db8597c]# python poclbm.py -d 0
55981 khash/s
[root@ip-10-17-144-204 m0mchil-poclbm-db8597c]# python poclbm.py -d 0 -v
35398 khash/s

Okay, point proven. Similar performance when using a single device, so the payoff factor is more like 13.5x rather than 27x, at least on this hardware.

[mikegogulski]

Then could you run another instance on python poclbm.py -d 1 ?

Sure, and then the aggregate performance would be about 112Mhashes/sec.

[Kiv]

After downloading the latest drivers, I'm getting 15 Mhash/sec on a Geforce 9600 GT. Pretty cool, though I wish it worked with the pooled mining... I am too impatient to wait days for a result ^_^

Anyone know if there are plans to support GPU pooled mining? That would be fantastic.

[slush]

After downloading the latest drivers, I'm getting 15 Mhash/sec on a Geforce 9600 GT. Pretty cool, though I wish it worked with the pooled mining... I am too impatient to wait days for a result ^_^

Anyone know if there are plans to support GPU pooled mining? That would be fantastic.

Yes, I'm working on that: http://asktom.cf/index.php?topic=1976.40 . It is already working. Want to go live until Sunday. m0mchil's miner working well with that.

[DiabloD3]

Not to sound n00bish, but when I follow the instructions I get:

[mithrandir@fedora poclbm]$ python ./poclbm.py
Traceback (most recent call last):
  File "./poclbm.py", line 3, in <module>
    import pyopencl as cl
ImportError: No module named pyopencl

Funny thing is, I did install pyopencl with an rpm I got.   (I tried it with the src, and got errors. RPM install worked fine.)

My system is: Fedora 14, 32 bit, Python 2.7, ATI Radeon 3100 Graphics, AMD Sempron LE-1300

EDIT: GPUCap via Wine says I don't have OpenCL support, but it also says I don't even have a GPU.   Is there a way to find out if I have OpenCL support on GNU/Linux?

According to that python error, no you don't have pyopencl installed. Go figure.

Also, you need at least a Radeon 4xxx to use OpenCL, 3xxx isnt enough.

[ribuck]

According to that python error, no you don't have pyopencl installed. Go figure.

On Fedora 12, the standard pyopencl installation doesn't work properly. I got it to work by following the instructions here:
http://wiki.tiker.net/PyOpenCL/Installation/Linux
but I had to use the second (longer) procedure in section 3, with locations specified explicitly.

Also, in step 2 of that document, I couldn't get Numpy to install using that method. But it installed properly when I used the GUI rpm installer ("System | Administration | Add/Remove Software").

[teknohog]

The latest revision seems to have a problem with vectors. So far, I get about 59 Mhash/s without, and 60.7 with, on a HD5570. However, the latest version slows down to 53.7 with vectors, while it stays at 59 without them.

[m0mchil]

Please provide full information about your platform - driver, SDK, OS. Did you tried with different values for worksize, '-f'? With catalyst 10.11, SDK 2.2 on windows I actually see slight improvement with vectors against previous version.

[teknohog]

Please provide full information about your platform - driver, SDK, OS. Did you tried with different values for worksize, '-f'? With catalyst 10.11, SDK 2.2 on windows I actually see slight improvement with vectors against previous version.

First of all, going back to commit 99c57637ca0d1db70187 fixes the issue, so the problem seems to be isolated to the last revision.

The system is a Gentoo Linux, kernel 2.6.36.1, with catalyst 10.11 drivers and SDK 2.2. I have not tried any other performance options besides -v and -f 1.

Work size 256 seems to bring the performance back to the expected levels, or at least very close. I should probably keep trying more of these options

Edit: I chose 256 as it is the default/maximum for my card. Smaller powers of two seem to work better, -w 64 gives 63.0 Mhash/s.

Edit 2: It seems I had failed to update back to the latest version for these tests (I'm a complete newbie with git ). The issue with the latest version is not much improved by the -w options.

[kwukduck]

I'm trying gpu mining with my new gtx 470 on win7-64
but i get only 77 khash/s

i tried changing -w and -v, doesn't  change much on -w, changing -v crashes the process.

i'd estimate this card would generate about 300000khash

any idea what could be wrong?


[EDIT]

Issue resolved, seems nVidia just has realy bad OpenCL performance

[/EDIT]