Topic: A slightly more open approach to bitcoin on the GPU (Read 18947 times)

Our strength is in the diversity of solutions. Sometimes your miner is the optimal solution.

Not right now, no, I lack the time. But I'm curious, why not use one of the much more optimized by now OpenCL implementations?

nelisky, can you make r205 patch?

It's been a while since I last worked on this, but I have compiled on OSX, against revision 156 and the osx makefile changes are on the patch a few messages above. You will probably need to change the paths to the libs, but should be fairly simple to do so.

Nelisky (or anyone else), could you provide the makefile and what system you compiled this on.  I'm really having trouble compiling this.  I have Ubuntu 10.04 with a GFX 9800 Gx2 with the latest Nvidia CUDA drivers installed (and I verified that my CUDA test programs do work). 

If no one wants to provide the makefile, could someone explains how I would go about modifying the existing unix makefile to compile the cuda version?

Also, what specific SVN reversion are we patching against?

Has anyone built this for windows?

I'm sure puddinpop has good reasons to not reply to my questions, but it feels weird. It's almost like he has something against me. Do you, puddinpop? Can't we just be friends?

Anyhow, no joke, I have generated my first real block using the CUDA miner! Woohoo, 50 coins accounted for, *now* it was all worth it, the sleepless nights, the complaining family due to my lack of attention, everything!

If I get another block I may start developing an opencl version, while I'm in profit! That is, if puddinpop didn't make one first and sold it for 20k coins

Hey puddinpop, I'm curious. On what OS are you compiling this? If it's not OSX, care to share the makefile? Also, what is you graphics card and how does my patch compare to your version on it? I got about 20% increase on mine compared to yours, but then again some things like the threads per block or the total number of blocks have a huge impact on the overal performance, and I didn't try to optimize your version.

Thanks for trying it out, finally some feedback

You are correct about the revision number being wrong. It was actually against r154. The fact I did a hacky job at including the miner means that problems do exist. I find that using all the cores + the GPU actually slows everything, and that reducing the number of mining threads on the fly doesn't do the right thing. One has to, as best as I can understand, start with 1 and up to 2 or more, but reducing threads leaves the system in unexpected states.

As for using a limit of -1 slowing things down, it makes some sense, as the CPU still is at 100% when using the GPU, doing memcpy's and finding nonces that are potential winners.

I'm attaching a new version that unrolls pretty much everything and nets me an extra 1MH/s, but this is finely tuned for my own system. This comes from a slightly more patched code base, so I hope I didn't leave any extra stuff.

I just tried your latest patch.  I noticed a few things:

• Your post, and the patch name, makes it seem like the patch is against revision 157, which does not yet exist.  Upon looking at the content of the patch, it is obvious the patch is against revision 155.
• You have an extraneous curly brace on line ~3077 when FOURWAYSSE2 is not defined
• I get about 6200 khash/s with your patch using the GPU only (limit set to 1 CPU).  However without the CPU limit, and using 2 CPUs, I only get 6500 khash/s according to the counter.  That can't be right.

Maybe noagendamarket should do it! ^_^

nelisky, I'll provide a card. Check your PMs.

This patch is done against the latest SVN, r157, where satoshi made it so much easier to hook up a custom miner in a clean way, including a no nonsense hash per sec calculation. Great work there, satoshi! I have tested it on a test network and at difficulty 1, doing ~6MHs I was generating a block every couple of minutes, with a standard client accepting it.

This patch does a much better job than the previous one because the hashes are no longer taken out of the GPU, only the number of 0's in them. That makes parsing a few thousand hashes that were calculated in parallel by the GPU a breeze. And then the nonce is passed to the Crypto++ hasher if one is found, which makes it double sure the hash is valid.

Also I cleaned up the makefile (still only for OSX 64bit) to make it easier for people to port to whatever system they have. Now, if any of you has a CUDA or ATI Stream enabled card, PCI-e that is gathering dust, consider donating it to me and I'll make it work on linux. It can be oldy, slowish, don't care. I just need it to be compatible so I can test.

Have fun, and keep the code open!

PS: the first miner generating is always the GPU, and I don't check if you have a compatible card, I just assume. When I have the time, I'll change that. I'm pretty much giving up on hoping for someone else to pick up where I left it Everyone developing this GPU thing seems to have an agenda.

I can give you mine BUT it's not statically linking cuda, so you need the SDK installed AND it's 64bits. Assuming both these things are good for you, and you don't mind using the terminal instead of the GUI, give it a try. This is the latest version that does ~6.2MHs on my system (assuming I'm calculating correctly ) and you should try it with just one mining thread (although it works with 5, the speed actually decreases from 3 up, and if you generate, you can't be sure it was the GPU miner).

Grab it at www.datlatec.com/bitcoind.zip and let me know how it goes.

Anyone have a working OS X binary they wouldn't mind posting? I am still trying to get my build tools figured out on OSX as it is not my primary OS currently.

IMHO, this would be a far better method of it than simply failing. Although, there should be some type of warning that it is failing over to CPU from GPU.

It is not silent at all when it fails. The result is that the hash calculated is all zeros, thus passing the difficulty check. Then the client double checks the hash and dies on an assert. Still, I could just not start the cuda miner and allow the client to still use the CPU

From what I've read, you can use the -emu to emulate GPU code on your CPU. No idea if that's it or it actually works but it's definitely worth a shot.

Oh, I completely understand wanting to understand your tools. I just felt because I am so used to working with the IDE and strapping it all together it would be easier for me to write on there to work on my linux and windows boxes.

BAHAHAHAHA!!! NICE! Might wanna get that checked out instead of silently failing or imploding ;-)

Thanks for the link! I'll be sure to try and follow as soon as I have a moment. The only thing is I don't have any linux with a cuda enabled gpu, but I can still try and build things up so others can test.

I don't use IDEs at all, I try very hard to avoid them. It pays in the long run to know and understand your tools.

As for helping in compiling, I've taken a very shortcut approach in my system, just copying the calls from the nvidia SDK template. There's a variable (is it debug or verbose?) that you set to 1 in your makefile and you'll get the calls it makes to compile printed out, so I just copied the switches over to the bitcoin makefile. That is one place I really need to improve, but didn't have time to. I don't even check if the gpu is cuda capable, for crying out load

Are you planning on using an IDE? If so, what is it? I prefer Netbeans and have it set up and running on Fedora 13 64bit. It's a bit of a pain to get setup, but works quite well once you do have it done.

After a quick search this pops up and looks very promising for you:
http://lifeofaprogrammergeek.blogspot.com/2008/05/cuda-development-in-ubuntu.html


I ran out of time this weekend to get any work done and fried my PSU last week due to overusage. New 850W will get to me tomorrow night.