Topic: CCminer(SP-MOD) Modded NVIDIA Maxwell / Pascal kernels. - page 1130. (Read 2347601 times)
With the last build from git also a lot of does not validate on cpu with -g 3 on 750 ti on quark and other algos too.
hehe. sorry, I corrected it now. The makefile was including an old file
UNDEFINED REFERENCE --
Another error exists:
Thanks for your attention to this.
--scryptr
hehe. sorry, I corrected it now. The makefile was including an old file
Just submitted commit number 6 today. you have the wrong version of the file ccminer.cpp. Get this file from the head and build
SP_ --
I must be misunderstanding. I did a clean git clone into an empty direcory and ran build.sh. I see your most recent comments. However, the "type conflict" is still there, the build fails. Here is my command line for the git, executed in an empty build directory:
"git clone https://github.com/sp-hash/ccminer ."
If you mean "pull it from your head", I am afraid you are out of reach. Any use of pliers or suction would likely cause irrepairable damage, and your golden eggs would cease. --scryptr
Just submitted commit number 6 today. you have the wrong version of the file ccminer.cpp. Get this file from the head and build
LINUX COMPILE ERROR --
I also get a compile error:
Something about conflicting types in line 696 of scrypt.c and line 354 of miner.h?
I can hardly wait to try it, sp_ . Thanks for your work! --scryptr
I also get a compile error:
Something about conflicting types in line 696 of scrypt.c and line 354 of miner.h?
I can hardly wait to try it, sp_ . Thanks for your work! --scryptr
Getting the same build error (linux, CUDA 6.5)
JUST NOW --
SP_ just finished depositing a newer build on GitHub, but I still get the same conflict error when attempting to build it. I do have Cuda 6.5. --scryptr
You are not building the latest source... Submitted a fix for the intensity parameter.
With -g 3 quark can run -i 22 without any problems. This is because the memory is fragmented, so the gpu doesn't need to allocate a big continuous block.
I get higher rates on the pool now
SAME ERROR --
I just pulled from Git and attempted to compile, and the "type conflict" is still there. I did see your Intensity fix comments. That is 3 commits today? --scryptr
LINUX COMPILE ERROR --
I also get a compile error:
Something about conflicting types in line 696 of scrypt.c and line 354 of miner.h?
I can hardly wait to try it, sp_ . Thanks for your work! --scryptr
I also get a compile error:
Something about conflicting types in line 696 of scrypt.c and line 354 of miner.h?
I can hardly wait to try it, sp_ . Thanks for your work! --scryptr
Getting the same build error (linux, CUDA 6.5)
JUST NOW --
SP_ just finished depositing a newer build on GitHub, but I still get the same conflict error when attempting to build it. I do have Cuda 6.5. --scryptr
You are not building the latest source... Submitted a fix for the intensity parameter.
With -g 3 quark can run -i 22 without any problems. This is because the memory is fragmented, so the gpu doesn't need to allocate a big continuous block.
I get higher rates on the pool now
LINUX COMPILE ERROR --
I also get a compile error:
Something about conflicting types in line 696 of scrypt.c and line 354 of miner.h?
I can hardly wait to try it, sp_ . Thanks for your work! --scryptr
I also get a compile error:
Something about conflicting types in line 696 of scrypt.c and line 354 of miner.h?
I can hardly wait to try it, sp_ . Thanks for your work! --scryptr
Getting the same build error (linux, CUDA 6.5)
JUST NOW --
SP_ just finished depositing a newer build on GitHub, but I still get the same conflict error when attempting to build it. I do have Cuda 6.5. --scryptr
LINUX COMPILE ERROR --
I also get a compile error:
http://s1.postimg.org/basdqn6cv/error.png
Something about conflicting types in line 696 of scrypt.c and line 354 of miner.h?
I can hardly wait to try it, sp_ . Thanks for your work! --scryptr
I also get a compile error:
http://s1.postimg.org/basdqn6cv/error.png
Something about conflicting types in line 696 of scrypt.c and line 354 of miner.h?
I can hardly wait to try it, sp_ . Thanks for your work! --scryptr
Getting the same build error (linux, CUDA 6.5)
The autotune function in scrypt needs cuda compute 2.1 to work. I think this is removed in the latest cuda kit. Downlad cuda 6.5.
I added more mulitthreading tweaking to all the kernals. quark with -g 3 is 6-8MHASH on the 750ti standard clocked in benchmark mode. with no cpu validation errors.
On the pool the hashrate is lower, but the cpu is near 100%, so I think I need to add some cpu sleeping
I added more mulitthreading tweaking to all the kernals. quark with -g 3 is 6-8MHASH on the 750ti standard clocked in benchmark mode. with no cpu validation errors.
On the pool the hashrate is lower, but the cpu is near 100%, so I think I need to add some cpu sleeping
Using 6.5 here... but getting build error
Delete compute_52,sm_52 in ccminer.vcxproj if you have gtx 750 ti
The autotune function in scrypt needs cuda compute 2.1 to work. I think this is removed in the latest cuda kit. Downlad cuda 6.5.
I added more mulitthreading tweaking to all the kernals. quark with -g 3 is 6-8MHASH on the 750ti standard clocked in benchmark mode. with no cpu validation errors.
On the pool the hashrate is lower, but the cpu is near 100%, so I think I need to add some cpu sleeping
I added more mulitthreading tweaking to all the kernals. quark with -g 3 is 6-8MHASH on the 750ti standard clocked in benchmark mode. with no cpu validation errors.
On the pool the hashrate is lower, but the cpu is near 100%, so I think I need to add some cpu sleeping
Using 6.5 here... but getting build error
The autotune function in scrypt needs cuda compute 2.1 to work. I think this is removed in the latest cuda kit. Downlad cuda 6.5.
I added more mulitthreading tweaking to all the kernals. quark with -g 3 is 6-8MHASH on the 750ti standard clocked in benchmark mode. with no cpu validation errors.
On the pool the hashrate is lower, but the cpu is near 100%, so I think I need to add some cpu sleeping
Looks like I have managed to remove the does not validate on the cpu..
edit: got one does not validate after 5 minutes of hashing on the pool
(quark)
I added more mulitthreading tweaking to all the kernals. quark with -g 3 is 6-8MHASH on the 750ti standard clocked in benchmark mode. with no cpu validation errors.
On the pool the hashrate is lower, but the cpu is near 100%, so I think I need to add some cpu sleeping
Looks like I have managed to remove the does not validate on the cpu..
edit: got one does not validate after 5 minutes of hashing on the pool
(quark)
LINUX COMPILE ERROR --
I also get a compile error:
Something about conflicting types in line 696 of scrypt.c and line 354 of miner.h?
I can hardly wait to try it, sp_ . Thanks for your work! --scryptr
I also get a compile error:
Something about conflicting types in line 696 of scrypt.c and line 354 of miner.h?
I can hardly wait to try it, sp_ . Thanks for your work! --scryptr
Question - I have been building right along with VS Express 2013, but now I get this?
Edit - just noticed this, I'm building for maxwell though?: Release\fermi_kernel.cu.obj "C:\Users\Linux\Desktop\ccminer-windows\scrypt\fermi_kernel.cu
Code:
Error 3 error MSB3721: The command ""C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v6.5\bin\nvcc.exe" -gencode=arch=compute_20,code=\"sm_21,compute_20\" -gencode=arch=compute_30,code=\"sm_30,compute_30\" -gencode=arch=compute_35,code=\"sm_35,compute_35\" -gencode=arch=compute_50,code=\"sm_50,compute_50\" -gencode=arch=compute_52,code=\"sm_52,compute_52\" --use-local-env --cl-version 2013 -ccbin "C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\bin" -I. -Icompat -I"compat\curl-for-windows\curl\include" -Icompat\jansson -Icompat\getopt -Icompat\pthreads -I"compat\curl-for-windows\openssl\openssl\include" -I"compat\curl-for-windows\zlib" -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v6.5\include" -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v6.5\include" -I"C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v6.5\include" --keep --keep-dir Release -maxrregcount=80 --ptxas-options=-v --machine 32 --compile -cudart static --ptxas-options="-O2" -DWIN32 -DNDEBUG -D_CONSOLE -D_CRT_SECURE_NO_WARNINGS -DCURL_STATICLIB -DUSE_WRAPNVML -DSCRYPT_KECCAK512 -DSCRYPT_CHACHA -DSCRYPT_CHOOSE_COMPILETIME -D_MBCS -Xcompiler "/EHsc /W3 /nologo /Ox /Zi /MT " -o Release\fermi_kernel.cu.obj "C:\Users\Linux\Desktop\ccminer-windows\scrypt\fermi_kernel.cu"" exited with code 1. C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\BuildCustomizations\CUDA 6.5.targets 593 9 ccminer
Edit - just noticed this, I'm building for maxwell though?: Release\fermi_kernel.cu.obj "C:\Users\Linux\Desktop\ccminer-windows\scrypt\fermi_kernel.cu
I have submitted fixes to the -g parameter. It now supports the -d parameter. I have also remove cudadevicereset, and corrected the stats. (total sum for each gpu)
So
ccminer -d 1,2 -g 2
is the same as
ccminer -d 1,1,2,2
but the stats will give the total hash of the each gpu
So
ccminer -d 1,2 -g 2
is the same as
ccminer -d 1,1,2,2
but the stats will give the total hash of the each gpu
The only reason I see for running more threads then physical C(G)PUs is to fill the gaps between tasks. You can easily see that gaps on GPU-Z load graph. In other cases it is useless I think. There is a case in some memory intensive applications when running multiple threads on single CPU gives boost over single thread. But this is a case when single-threaded app is bad coded not fitting data in cache.
HASH RATE --
I always get a little more hash. It only takes a command line switch, no real effort. The real trick is tuning the code to make good use of it.
I am now mining Quark at close to 37Mh/s on my 750ti FTW rig, and that is 400kh/s better than yesterday with the same v45 code. My 960 SSC is getting up to 10Mh/s now:
960 SSC nearing max performance mining Quark, v45 sp_hash
The hash rate fluctuates. --scryptr
Code:
[2015-04-21 20:23:02] GPU #0: GeForce GTX 750, 4110 kH/s
[2015-04-21 20:23:02] GPU #0: GeForce GTX 750, 555.39 kH/s
[2015-04-21 20:23:03] yaamp.com:4733 qubit block 485
[2015-04-21 20:23:03] GPU #0: GeForce GTX 750, 4178 kH/s
[2015-04-21 20:23:03] GPU #0: GeForce GTX 750, 357.77 kH/s
[2015-04-21 20:23:07] GPU #0: GeForce GTX 750, 4145 kH/s
[2015-04-21 20:23:07] accepted: 13/13 (100.00%), 5792 khash/s yay!!!
[2015-04-21 20:23:08] yaamp.com:4733 qubit block 486
[2015-04-21 20:23:08] GPU #0: GeForce GTX 750, 404.75 kH/s
[2015-04-21 20:23:08] GPU #0: GeForce GTX 750, 4067 kH/s
[2015-04-21 20:23:12] GPU #0: GeForce GTX 750, 4105 kH/s
[2015-04-21 20:23:12] accepted: 14/14 (100.00%), 5799 khash/s yay!!!
[2015-04-21 20:23:22] GPU #0: GeForce GTX 750, 4120 kH/s
[2015-04-21 20:23:23] accepted: 15/15 (100.00%), 5802 khash/s yay!!!
[2015-04-21 20:23:25] GPU #0: GeForce GTX 750, 4114 kH/s
[2015-04-21 20:23:25] accepted: 16/16 (100.00%), 5801 khash/s yay!!!
[2015-04-21 20:23:27] yaamp.com:4733 qubit block 486
[2015-04-21 20:23:27] GPU #0: GeForce GTX 750, 679.92 kH/s
[2015-04-21 20:23:27] GPU #0: GeForce GTX 750, 4084 kH/s
[2015-04-21 20:23:34] yaamp.com:4733 qubit block 487
[2015-04-21 20:23:34] GPU #0: GeForce GTX 750, 4114 kH/s
[2015-04-21 20:23:34] GPU #0: GeForce GTX 750, 417.11 kH/s
[2015-04-21 20:23:38] GPU #0: GeForce GTX 750, 4142 kH/s
[2015-04-21 20:23:39] accepted: 17/17 (100.00%), 5806 khash/s yay!!!
[2015-04-21 20:23:02] GPU #0: GeForce GTX 750, 555.39 kH/s
[2015-04-21 20:23:03] yaamp.com:4733 qubit block 485
[2015-04-21 20:23:03] GPU #0: GeForce GTX 750, 4178 kH/s
[2015-04-21 20:23:03] GPU #0: GeForce GTX 750, 357.77 kH/s
[2015-04-21 20:23:07] GPU #0: GeForce GTX 750, 4145 kH/s
[2015-04-21 20:23:07] accepted: 13/13 (100.00%), 5792 khash/s yay!!!
[2015-04-21 20:23:08] yaamp.com:4733 qubit block 486
[2015-04-21 20:23:08] GPU #0: GeForce GTX 750, 404.75 kH/s
[2015-04-21 20:23:08] GPU #0: GeForce GTX 750, 4067 kH/s
[2015-04-21 20:23:12] GPU #0: GeForce GTX 750, 4105 kH/s
[2015-04-21 20:23:12] accepted: 14/14 (100.00%), 5799 khash/s yay!!!
[2015-04-21 20:23:22] GPU #0: GeForce GTX 750, 4120 kH/s
[2015-04-21 20:23:23] accepted: 15/15 (100.00%), 5802 khash/s yay!!!
[2015-04-21 20:23:25] GPU #0: GeForce GTX 750, 4114 kH/s
[2015-04-21 20:23:25] accepted: 16/16 (100.00%), 5801 khash/s yay!!!
[2015-04-21 20:23:27] yaamp.com:4733 qubit block 486
[2015-04-21 20:23:27] GPU #0: GeForce GTX 750, 679.92 kH/s
[2015-04-21 20:23:27] GPU #0: GeForce GTX 750, 4084 kH/s
[2015-04-21 20:23:34] yaamp.com:4733 qubit block 487
[2015-04-21 20:23:34] GPU #0: GeForce GTX 750, 4114 kH/s
[2015-04-21 20:23:34] GPU #0: GeForce GTX 750, 417.11 kH/s
[2015-04-21 20:23:38] GPU #0: GeForce GTX 750, 4142 kH/s
[2015-04-21 20:23:39] accepted: 17/17 (100.00%), 5806 khash/s yay!!!
this is qubit on my single gtx750 with release 45
ccminer.exe --cpu-priority 5 -d 0,0 -i 16 -a qubit
But I'm not sure that this numbers are real performance ...
The only reason I see for running more threads then physical C(G)PUs is to fill the gaps between tasks. You can easily see that gaps on GPU-Z load graph. In other cases it is useless I think. There is a case in some memory intensive applications when running multiple threads on single CPU gives boost over single thread. But this is a case when single-threaded app is bad coded not fitting data in cache.
The anomalous "GPU #11" represents one of the threads, but generally the output only displays GPUs #0-5. As you can see, the acceptance rate while mining Quark with v45 is still good. --scryptr
did the pool confirm the numbers that miner shows? I mean hashrate ...
I tried with my single card with -d 0,0 option and it gives 'does not validate on CPU' for non-existing GPU1.
Also higher hashrate the miner shows is not confirmed by the pool.
The pool rates fluctuate between 30-40Mh/s. I never know when they are accurate. It is like an "ebb and flow" phenomenon to me.
If you have ever done any CPU mining, multiple threads can be used with the "--threads 16" command. If you use that on an i7, you'll get 2 threads per virtual CPU on the Quad-Core. --scryptr
The anomalous "GPU #11" represents one of the threads, but generally the output only displays GPUs #0-5. As you can see, the acceptance rate, while mining Quark with v45, is still good. --scryptr
did the pool confirm the numbers that miner shows? I mean hashrate ...
I tried with my single card with -d 0,0 option and it gives (sometimes but rather often) 'does not validate on CPU' for non-existing GPU1.
Also higher hashrate the miner shows is not confirmed by the pool.
Jump to: