Topic: CCminer(SP-MOD) Modded NVIDIA Maxwell / Pascal kernels. - page 1124. (Read 2347601 times)

1.5.46(sp-MOD) is available here: (25-april-2015)

https://github.com/sp-hash/ccminer/releases/tag/1.5.46

The sourcecode is available here:

https://github.com/sp-hash/ccminer


-Added scrypt and scrypt-n from the motherbranch/cudaminer
-Fixed the hash with the -g parameter (quark, x11,x13,x14,x15,x17)
-Optimized blake(faster quark, x11,x13,x14,x15,x17)

Big thanks to Klaus_t( who fixed the broken hash) https://github.com/KlausT/ccminer
Also thanks to tvpruvot who merged the scrypt kernals from cudaminer https://github.com/tpruvot/ccminer

and the betatesters at bitcointalk.org

After I added scrypt, building takes forever. The exefile is also much bigger. The scrypt kernals are too big. I think I need to shrink and optimize.

building release 46 now.. Thanks for testing guys.

BASELINE BUILD 730--

I cloned from git and compiled build 730.  I am currently running at baseline (no "-g" or "-i" or other performance flags set) and my 6x750ti FTW rig is mining Quark at 38.1Mh/s, with the 2x970 FTW+ rig running at 29.75Mh/s.  This is superior to the results obtained earlier today with build 729, both 2- threaded and 4-threaded.  There are no errors or fluctuations.

I curtailed any testing on build 729.  My copy is backed-up.  After 4 hours with build 730, I plan on finding the maximum "-i" parameter for a single thread, then testing 2-threaded and 4-threaded mining at maximum intensity.       --scryptr

P.S.  Both of my rigs are delivering "Found nonce $A1B2C3D4" messages in the thread hash reports.  The 8-digit string is any random hexadecimal number that satisfies the block, I suppose.  They don't seem to be errors...       --scryptr

P.P.S.  My poolside hashrate is currently 116Mh/s, more than is being indicated locally on my rigs (about 77.5Mh/s, total, and including the 960 SSC on my work computer).       --scryptr

P.P.P.S.  The rigs are still at 100% accepts after both have more than 250 accepts!       --scryptr

Y.A.P.S. The rigs are still at 100% accepts after more than 500 accepts each!         --scryptr

all I can say is WOW.
Just built and run quark without any parameters.
Hashrate goes from R43 record 5717 to stable 5810.
GPU memory usage raised from 112mb to 383mb
Power consumption is also raised up to 63% TDP from max 58% of release 43. (gtx 750@1480/1570)
Just need some time to check pool hashrate

Single-threaded I have been able to use "-i 23.5" for Quark.  Multi-threaded, "-g 2 -i 23" gives reasonable hash rates without crashing, this is with build 729.  The multi-threaded rates currently swing a bit at launch, and then settle in at a reasonable rate similar to single threaded performance.  In about 30 minutes, my rigs will have run for 4 hours with "-g 2 -i 23", and I will go to single-threaded for another 4 hours.  With build 729, I will have compared "-g 4 -i 23", "-g 2 -i 23", and "-i 23" (single threaded) about 4-5 hours from now.  

Currently, build 724 gives me the best overall hash rate, local and poolside, when run single-threaded with "-i 23.5" for the 750ti and "-i 23" for my 970s.  Different model 750ti cards have different capacities.  A few were made with 1 gig memory, most with 2 gigs, and there is a rumored 4 gig ASUS 750ti in the works.  The power and factory clocks vary, also.

--scryptr

p.s. build/commit 724 was v45, earlier yesterday, prior to the "...does not validate on CPU" fix based on KlausT's work.

--scryptr

submitted faster blake with one thread. Please test and report.

run quark with no launch parameters.

Do you mean Quark?
My guess is ccminer by sp_ release 43 (thai build ) without any -g or -i parameters. Or maximum -i that doesn't crash
I have no faith in multiple gpu threads ...


For other algos use Release 44 or 45 without -g with manually tuned -i or default -i

What the best settings -g and -i for single 750 ti?

Yes, with one thread the latest quark has dropped 1mhash. I am fixing it now.

COMMIT 729--

I cloned git on my two rigs, compiled, and began mining Quark about 4 hours ago.  The 6x750ti FTW rig continues to report 50-60Mh/s, and the 2x970 FTW+ rig reports 38-42Mh/s.  The acceptance rates are about 98% for the 750ti rig, and 97% for the 970 rig.  There are very few errors.  Long streams of card hash rates are interspersed with accepted hash (yay!!!) messages.  However, the pool reports slightly lower hash levels total.

Prior to the test of build 729, I was mining with build 724, single-threaded, with the intensities that I reported yesterday.  Currently, the high intensity setting, single threaded, is resulting in better hash reported poolside.  Mining with "-g 4", my machines report 90Mh/s+ total hash rate, the pool reports about 70-75Mh/s.  Mining single-threaded, my machines report 75-80Mh/s, the pool reports about 75Mh/s, sometimes less.

With 4 threads, the high hash rate accepts (yay!!!) messages are less frequent, a large amount of thread rate data is displayed between accepts.  The 750ti thread rate values range between 6-12Mh/s.  The 970 thread rate data ranges between 11-40Mh/s.      

The configuration string for the 2x970 FTW+ rig included "-g 4 -i 23" for performance.  The configuration string for the 6x750ti FTW rig included "-g 4 -i 22" for performance.  These were the highest working intensity values that I could quickly find for either rig.

 --scryptr

With the latest build hashrate is really high according to ccminer. (quark algo, yaamp, linux, 970/750ti rig, 50 and 52 capability)
Yaamp reports similar hashrate first but for a longer period the hashrate is lower compared to the eg. 43 version.
Hashrate reported by yaamp is lower even without -g parameter but with -g the difference is more significant. I tried with -g 3, -g 4, without intensity setting and with -i 22, I increased difficulty but the result was same.

SP, before you build 46. I tested and built the recent update and am getting really low values on quark, as I've only tested that with different -i values.

I will build release 46 later tonight.

Wow a big thanks for the hard works,
Is there a gentlemen who can post the compile version so we can try !!
Thanks to sp and all other who works for the community   

Probobly is. Let's enjoy the -g parameter and see what we can do with that.

The titan-x with 12gig ram might do good with settings like -i 28 -g 16

With default settings it does this: (980 reference non overclock)

http://cryptomining-blog.com/4639-nvidia-geforce-gtx-980-vs-gtx-titan-x-mining-performance/




Blake is slow on NVIDIA..

6.4GH/s - 6.9GH/s on a AMD Radeon R9 295X2
3.3GH/s - 3.5GH/s on a AMD Radeon R9 290X
2.9GH/s - 3.1GH/s on a AMD Radeon R9 290
2.6GH/s - 2.8GH/s on a AMD Radeon R9 280X
2.2GH/s - 2.4GH/s on a AMD Radeon R9 280
1.2GH/s - 1.5GH/s on a AMD Radeon R9 270
4.8GH/s - 5.1GH/s on a AMD ATI Radeon 7990
2.2GH/s - 2.8GH/s on a AMD ATI Radeon 7970
2.1GH/s - 2.4GH/s on a AMD ATI Radeon 7950
2.6GH/s - 2.9GH/s on a AMD ATI Radeon 6990
1.4GH/s - 1.5GH/s on a AMD ATI Radeon 6970
1.4GH/s on a AMD ATI Radeon 6950
900MH/s on a AMD ATI Radeon 6870
800MH/s on a AMD ATI Radeon 6850
1.3GH/s on a AMD ATI Radeon 5870
1.1GH/s on a AMD ATI Radeon 5850
1.6GH/s on a ZTEX USB-FPGA 1.15y Quad Spartan-6 LX150 Development Board
1.5GH/s on a Enterpoint Cairnsmore 1 Quad Spartan-6 LX150 Development Board
960MH/s on a Lancelot Dual Spartan-6 LX150 Development Board
360MH/s on a ZTEX USB-FPGA 1.15x Spartan-6 LX150 Development Board

ref:

https://bitcointalksearch.org/topic/annblc-blakecoin-blake-256-for-gpufpga-with-merged-mined-pools-stable-net-306894

that would be awesome ...

if that can be possible - and you have it all functional ... it will be just a matter of time and a weekend for a donation mining spree for you as a tanx for all your effort ...

it actually sounds too good to be true ...

...

#crysx

The most obvious next step is the --gpu-memclock and --gpu-memspeed parameter..

Commandline overclocking.

When I started to optimize this, my target is 100% faster x11 on the 750ti. I still think it is possible.

5-6MHASH x11 on the 750ti.

all good ...

i know this is probably just me thats continues to ask this ... but if there is more x11 optimization and speed to be had - we would be VERY appreciative of it ...

tanx again sp ...

#crysx

Thanks

There is more coming. First up is to fix the hash with the -g parameter in other algos, like skein, whirlpoolx, blake, qubit etc..

Hopefully 20-30% gain in the hashrate all over the place.

Go get those bitcoins guys

Happy hashing:)