I'm still on it - with a different idea. As it turns out, doing Fermat tests on the GPU is not a no brainer and getting that fast requires too much effort for now, so I'll try to port something else to the GPU.
I'm still sure a GPU miner is possible, but right now I would say it's a lot harder than for the other coins. The other OpenCL miner project is (amusingly!) also having problems.
Topic: [XPM] CUDA enabled qt client miner for primecoins. Source code inside. WIP - page 3. (Read 31767 times)
July 31, 2013, 04:52:58 AM
July 30, 2013, 06:56:54 PM
has anyone tested this yet? is it working?
July 30, 2013, 05:40:30 PM
It's abandoned. Lol. Probably everyone figured out that this is too difficult. Heck even mlmrt was having trouble.
LIES! He's managed to have the same efficiency as an AMD multi-core.
With an AMD multi-core + a HD6990.
I WANT I WANT I WANT I WANT!
July 30, 2013, 05:26:10 PM
It's abandoned. Lol. Probably everyone figured out that this is too difficult. Heck even mlmrt was having trouble.
LIES! He's managed to have the same efficiency as an AMD multi-core.
With an AMD multi-core + a HD6990.
July 30, 2013, 04:55:06 PM
It's abandoned. Lol. Probably everyone figured out that this is too difficult. Heck even mlmrt was having trouble.
July 30, 2013, 10:55:19 AM
Is this project still active or has it been abandoned?
July 26, 2013, 07:20:14 AM
Please check that you're using the latest SDK. I also encountered memory problems with cuda 5.0 and I'm using 5.5 now which works for me.
Just curious, have you looked at the Mfaktc source code at all? While it is used for trial factoring Mersenne Primes, which may not be helpful, the writer did get it to sieve completely on the GPU, which may.I looked into it, yes. Code is not very understandable though...
July 26, 2013, 05:09:24 AM
I've updated to cuda-5.5 (and driver 319.21)
Running with cuda-gdb I get the following error:
Running with cuda-gdb I get the following error:
Code:
Have 2400 candidates after main loop
Cuda start!
[New Thread 0x7fffacc38700 (LWP 14248)]
[Context Create of context 0x7fff700234f0 on Device 0]
[Launch of CUDA Kernel 0 (runPrimeCandidateSearch<<<(25,1,1),(192,1,1)>>>) on Device 0]
Program received signal CUDA_EXCEPTION_10, Device Illegal Address.
[Switching focus to CUDA kernel 0, grid 1, block (15,0,0), thread (0,0,0), device 0, sm 3, warp 0, lane 0]
0x00007fff7091b760 in long_multiplication(unsigned int * @generic, unsigned int * @generic, unsigned int * @generic, unsigned int, unsigned int) (
product=0x3fff6b4, op1=0x3fff734, op2=0x3fff634, num_digits=17,
prod_capacity=1073741824)
at primecoin/src/cuda/digit.h:406
406 product[i] = 0;
July 25, 2013, 07:24:41 PM
Fascinating. This CUDA miner is already vaguely functional now? Now that's some community effort. I wonder what will be the eventual result of this. Will fast CPU's and GPU's working together be the new mining rigs?
July 25, 2013, 02:46:31 PM
Having the same problem as K1773R (GTX670 using CUDA 5.5 and the driver it includes). Tried it on mainnet as I still cannot connect to testnet for some reason.
from GDB
Edit: This may just be PEBKAC / RTFM issue on my part. Just saw your note about running with 1 cpu only.
Still crashed, managed to get a few rounds. Used to crash right away
Code:
Have 101 candidates after main loop
Cuda start!
{... some block messages i.e. getblocks -1 to blah, accept etc}
Have -1 candidates after main loop
Cuda+host test round finished with -1 candidates (0 host chain tests)
Cuda error: cudaMemcpy: cudaMemcpyDeviceToHost, unspecified launch failure
ERROR: PrimecoinMiner() : primorial minimum overflow
ERROR: PrimecoinMiner() : primorial minimum overflow
ERROR: PrimecoinMiner() : primorial minimum overflow
ERROR: PrimecoinMiner() : primorial minimum overflow
ERROR: PrimecoinMiner() : primorial minimum overflow
ERROR: PrimecoinMiner() : primorial minimum overflow
ERROR: PrimecoinMiner() : primorial minimum overflow
ERROR: PrimecoinMiner() : primorial minimum overflow
from GDB
Code:
[0] start!
sizeof(struct) = 400
mpz_print:mpz_capacity: 0
[0] string candidate is
[0] N is: mpz_capacity: 30 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
[0] E is: mpz_capacity: 30 fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe
Edit: This may just be PEBKAC / RTFM issue on my part. Just saw your note about running with 1 cpu only.
Still crashed, managed to get a few rounds. Used to crash right away
Code:
2013-07-25 19:51:56 primemeter 0 prime/h 498885 test/h 0 5-chains/h
2013-07-25 19:52:56 primemeter 0 prime/h 8404040 test/h 0 5-chains/h
2013-07-25 19:53:56 primemeter 0 prime/h 4184750 test/h 0 5-chains/h
July 25, 2013, 02:03:20 PM
Please check that you're using the latest SDK. I also encountered memory problems with cuda 5.0 and I'm using 5.5 now which works for me.
Just curious, have you looked at the Mfaktc source code at all? While it is used for trial factoring Mersenne Primes, which may not be helpful, the writer did get it to sieve completely on the GPU, which may. July 25, 2013, 11:57:51 AM
Just got this compiled (Talk about a mess, when my cuda sdk was installed the paths were completely different then they should of /nvidia-304 vs /nvidia-current etc, then some fun Qt conflicts).
Anyone have a working node for testnet they can post? Not having any luck connecting.
Anyone have a working node for testnet they can post? Not having any luck connecting.
July 25, 2013, 11:56:10 AM
Please check that you're using the latest SDK. I also encountered memory problems with cuda 5.0 and I'm using 5.5 now which works for me.
ACK, will do later and report back 
July 25, 2013, 11:14:24 AM
Would it make any difference if we use __restricted__ pointers in the CUDA code?
July 25, 2013, 10:27:25 AM
Please check that you're using the latest SDK. I also encountered memory problems with cuda 5.0 and I'm using 5.5 now which works for me.
July 25, 2013, 09:11:30 AM
More than wiling to help perform tests as instructed if a windows binary is posted. Got an old GTX 475 rattling around that I could out to work..
July 25, 2013, 08:48:56 AM
My 2 cents: mining entirely on GPU wont be easy and is impractical, but tandem mining with interleaved CPU+GPU computations may very well give good speed ups.
Some feedback from knowledgeable people indicates that mod_exp probably would not speed up as well on gpu. However I think if gpu can do the sieve much more efficiently it could generate a lot less candidates for the Fermat test, which could speed things up quite a bit.
There is indeed a problem with the speeds of Fermat tests on the GPU. GNU GMP uses the most sophisticated algorithms available, the student library I found and which I started to extend uses the most basic algorithms.
Mpz_powmod needs fast multiplications of big ints, GMP's algorithm is most likely in O(log(n)*n), school book multiplication which the GPU now uses is O(n^2). I hoped that for the ~400 bit numbers involved it wouldn't make such a difference. Currently, the new version in my repo does Fermat tests on the GPU (rate is 10 per second), but my CPU is still faster due to better algorithms and a better big num implementation.
But don't worry, I won't give up so fast! The current situation is that I either need to look into porting better algorithms to the GPU or to do something else than Fermat tests on the GPU to sieve candidates (e.g. trial division with most common primes).
Anybody with a better GPU than the Geforce 570 TI I own, please test this! My stats (base version is still hp4):
2013-07-24 21:53:38 primemeter 24303 prime/h 490729 test/h 47 5-chains/h
prime/h and test/h seem to fluctuate enormously and seem to be rather meaningless. As most tests are on the GPU, I have no idea if this is even measuring the tests right. 5-chains is accurate though.
You have to use setgenerate true 1, i.e. one CPU thread for mining.
EDIT:
Code:
2013-07-25 13:35:43 primemeter 0 prime/h 34261932 test/h 0 5-chains/h
EDIT2:
Code:
Have 2400 candidates after main loop
Cuda start!
Cuda error: cudaMemcpy: cudaMemcpyDeviceToHost, the launch timed out and was terminated
You can also run it with -printmining -printtoconsole to see that output directly. Could you compile the cuda portion with -G -g (change the qt project file where it invokes nvcc) and give me the output of cuda-memcheck?
You can also #define CUDA_DEBUG in the cu file, to see the GPU printfs from the console
EDIT: its up and running, waiting for the cuda init + crash
EDIT2: why does it take so long until the miner starts the cuda thread? that seems stupid :S
EDIT3: here we go, it crashed
debug.log
Code:
Have 2400 candidates after main loop
Cuda start!
Cuda error: cudaMemcpy: cudaMemcpyDeviceToHost, unspecified launch failure
Code:
[0] start!
sizeof(struct) = 400
mpz_print:mpz_capacity: 0
[0] string candidate is
[0] N is: mpz_capacity: 30 ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
[0] E is: mpz_capacity: 30 fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffe
July 25, 2013, 08:47:59 AM
If someone could give me some specific compilation directions (or a windows binary!) I can test on a 780.
July 25, 2013, 08:45:44 AM
My 2 cents: mining entirely on GPU wont be easy and is impractical, but tandem mining with interleaved CPU+GPU computations may very well give good speed ups.
Some feedback from knowledgeable people indicates that mod_exp probably would not speed up as well on gpu. However I think if gpu can do the sieve much more efficiently it could generate a lot less candidates for the Fermat test, which could speed things up quite a bit.
There is indeed a problem with the speeds of Fermat tests on the GPU. GNU GMP uses the most sophisticated algorithms available, the student library I found and which I started to extend uses the most basic algorithms.
Mpz_powmod needs fast multiplications of big ints, GMP's algorithm is most likely in O(log(n)*n), school book multiplication which the GPU now uses is O(n^2). I hoped that for the ~400 bit numbers involved it wouldn't make such a difference. Currently, the new version in my repo does Fermat tests on the GPU (rate is 10 per second), but my CPU is still faster due to better algorithms and a better big num implementation.
But don't worry, I won't give up so fast! The current situation is that I either need to look into porting better algorithms to the GPU or to do something else than Fermat tests on the GPU to sieve candidates (e.g. trial division with most common primes).
Anybody with a better GPU than the Geforce 570 TI I own, please test this! My stats (base version is still hp4):
2013-07-24 21:53:38 primemeter 24303 prime/h 490729 test/h 47 5-chains/h
prime/h and test/h seem to fluctuate enormously and seem to be rather meaningless. As most tests are on the GPU, I have no idea if this is even measuring the tests right. 5-chains is accurate though.
You have to use setgenerate true 1, i.e. one CPU thread for mining.
EDIT:
Code:
2013-07-25 13:35:43 primemeter 0 prime/h 34261932 test/h 0 5-chains/h
EDIT2:
Code:
Have 2400 candidates after main loop
Cuda start!
Cuda error: cudaMemcpy: cudaMemcpyDeviceToHost, the launch timed out and was terminated
You can also run it with -printmining -printtoconsole to see that output directly. Could you compile the cuda portion with -G -g (change the qt project file where it invokes nvcc) and give me the output of cuda-memcheck?
You can also #define CUDA_DEBUG in the cu file, to see the GPU printfs from the console
July 25, 2013, 08:31:53 AM
My 2 cents: mining entirely on GPU wont be easy and is impractical, but tandem mining with interleaved CPU+GPU computations may very well give good speed ups.
Some feedback from knowledgeable people indicates that mod_exp probably would not speed up as well on gpu. However I think if gpu can do the sieve much more efficiently it could generate a lot less candidates for the Fermat test, which could speed things up quite a bit.
There is indeed a problem with the speeds of Fermat tests on the GPU. GNU GMP uses the most sophisticated algorithms available, the student library I found and which I started to extend uses the most basic algorithms.
Mpz_powmod needs fast multiplications of big ints, GMP's algorithm is most likely in O(log(n)*n), school book multiplication which the GPU now uses is O(n^2). I hoped that for the ~400 bit numbers involved it wouldn't make such a difference. Currently, the new version in my repo does Fermat tests on the GPU (rate is 10 per second), but my CPU is still faster due to better algorithms and a better big num implementation.
But don't worry, I won't give up so fast! The current situation is that I either need to look into porting better algorithms to the GPU or to do something else than Fermat tests on the GPU to sieve candidates (e.g. trial division with most common primes).
Anybody with a better GPU than the Geforce 570 TI I own, please test this! My stats (base version is still hp4):
2013-07-24 21:53:38 primemeter 24303 prime/h 490729 test/h 47 5-chains/h
prime/h and test/h seem to fluctuate enormously and seem to be rather meaningless. As most tests are on the GPU, I have no idea if this is even measuring the tests right. 5-chains is accurate though.
You have to use setgenerate true 1, i.e. one CPU thread for mining.
EDIT:
Code:
2013-07-25 13:35:43 primemeter 0 prime/h 34261932 test/h 0 5-chains/h
EDIT2:
Code:
Have 2400 candidates after main loop
Cuda start!
Cuda error: cudaMemcpy: cudaMemcpyDeviceToHost, the launch timed out and was terminated
after the message it segfaults, going to debug with gdb
Jump to: