Topic: CUDA Kernel for Phoenix - interest? Possible? (Read 3268 times)
+5 Bitcoins for a Cuda Kernel in Phoenix...
That cpu bug in opencl is driving me nuts. The rpcminer-cuda does not have the same problem.
which is what keeps me from running it on my laptop, which brings the CPU to full roar (Turbo Boost) when I run a miner that gobbles 100% CPU.
set phoenix.exe-affinity to Core 0 (via Task manager) and enjoy low CPU load...we know, homie, we know. It is still unacceptable that is uses 100% of one core. I've got 4 cards each in 2 different systems, one; 1 core out of 2(second core), and 1 core out of four respectivly(4th core). On the dual core there is more heat loss from the cpu than from the vid cards. its annoying....
which is what keeps me from running it on my laptop, which brings the CPU to full roar (Turbo Boost) when I run a miner that gobbles 100% CPU.
set phoenix.exe-affinity to Core 0 (via Task manager) and enjoy low CPU load... As for a name, that's easy. "falcudami" - as in FALcon's CUDA MIner? Catchy, silly, or shut up and get with the code?
I'd slap a Falcudami sticker on my box if you can make some code that will improve CUDA performance. I've got a shiney, new Gigabyte GTX 460 dual fan sitten' in the box I'd be happy to test it on too.
CUDA mining seems to be about as fast as OpenCL mining on CUDA (nVidia) hardware, but the difference is the unavoidable-at-nearly-any-aggression CPU usage - which is what keeps me from running it on my laptop, which brings the CPU to full roar (Turbo Boost) when I run a miner that gobbles 100% CPU. The laptop has Optimus, so mining CUDA at full speed doesn't affect my desktop responsiveness even one iota. I think using real CUDA would also enable the miner to be more efficient on the hardware, as many of the old miners were built on the premise of "OMG! It works! 3 million hashes a second, OMG!", and never got any love/attention when AMD GPUs started cranking out more like "OMG! 300 million hashes a second! I need new underwear!". I'm sure if we go back and dust the cobwebs off the old CUDA miner code, there could be a decent performance boost to be gained from tweaking a few lines and spending a few hours on it
As for a name, that's easy. "falcudami" - as in FALcon's CUDA MIner? Catchy, silly, or shut up and get with the code?
As for a name, that's easy. "falcudami" - as in FALcon's CUDA MIner? Catchy, silly, or shut up and get with the code?
I don't see any reason why native CUDA mining couldn't be done, but it wouldn't gain you much of any performance improvement.
Aye, it likely wouldn't. But I think Falcon, and many of us are more concerned with the 100% cpu bug that has existed in OpenCL for some time now. Would it fix that or is that more of an embedded bug in the ATI hardware that just isn't fixable at the software level?
I don't see any reason why native CUDA mining couldn't be done, but it wouldn't gain you much of any performance improvement.
So, I got to thinking... phatk or poclbm should be able to be ported to native CUDA (since OpenCL-over-CUDA gives us that 100% CPU problem), or at the very least, take what existed in rpcminer-cuda (or other binary-only miners) and make it work with Phoenix.
Seems that a lot of miner-users don't bother with downloading the whole Python+PyOpenCL (and its massive jumble of dependencies) thing, and Phoenix was started with the idea of modular kernels but not many people have taken it up on that offer. Seems like it should be possible... I just spent so much time trying to get a (native, non-MinGW) build of Phoenix working on Windows, and I kept running into irritating issues where the prebuilt versions of components (like Boost) were hardwired for older versions of Python and all needed to be recompiled! With all this recompiling, I may as well just start tweaking some things, right?
Anyone know of any particular limitations?
Seems that a lot of miner-users don't bother with downloading the whole Python+PyOpenCL (and its massive jumble of dependencies) thing, and Phoenix was started with the idea of modular kernels but not many people have taken it up on that offer. Seems like it should be possible... I just spent so much time trying to get a (native, non-MinGW) build of Phoenix working on Windows, and I kept running into irritating issues where the prebuilt versions of components (like Boost) were hardwired for older versions of Python and all needed to be recompiled! With all this recompiling, I may as well just start tweaking some things, right?
Anyone know of any particular limitations?
Jump to: