CCminer(SP-MOD) Modded GPU kernels.

[djm34]

sp_,

Is there some way to do "minimal rebuilds" of the CUDA kernels on Windows?

It's pretty lame sitting around for 10min while all that unchanged stuff rebuilds after I change one line.

I don't think it is possible or you would have to write different files for different kernel. But no matter what you will still need to recompile it (for what it is worth, it is a lot better than opencl)

[djm34]

I also submitted a 20% reduction in memory on the lyra2v2 algo so you can have higher intensities than before..

The default for the 750ti is -X 16. in release 63 it was -X 8
The default for the 970 is -X 26, in release 63 it was -X 16

not entirely a good idea, you are clearly sacrificing the 3.5 compute cards... (already noticed that in some previous change... I understand that you don't have these card, don't understand why you are removing the optimization done here) also it doesn't really matter how much memory you allocate if it isn't used, that's why I used that "#define memshift 3 (or 4")" to do that.
Don't really understand either why you are pushing the intensity so high, at some point it doesn't help anymore and create more bottleneck on mem access...

[djm34]

and a little more  (the 750ti is oc at +200 mem/core, actually core matters more than mem)

Nice, didn't take you too long

I'm thinking we agree on how it should be done, tried that one thing I hadn't had time to try yet

most likely  (however some variations around that are probably possible)

[t-nelson]

sp_,

Is there some way to do "minimal rebuilds" of the CUDA kernels on Windows?

It's pretty lame sitting around for 10min while all that unchanged stuff rebuilds after I change one line.

I don't think it is possible or you would have to write different files for different kernel. But no matter what you will still need to recompile it (for what it is worth, it is a lot better than opencl)

Actually this seems to be working.  I think the commit I reverted touched WAY more than I thought it did is all.

[sp_]

I also submitted a 20% reduction in memory on the lyra2v2 algo so you can have higher intensities than before..
The default for the 750ti is -X 16. in release 63 it was -X 8
The default for the 970 is -X 26, in release 63 it was -X 16

not entirely a good idea, you are clearly sacrificing the 3.5 compute cards... (already noticed that in some previous change... I understand that you don't have these card, don't understand why you are removing the optimization done here) also it doesn't really matter how much memory you allocate if it isn't used, that's why I used that "#define memshift 3 (or 4")" to do that.
Don't really understand either why you are pushing the intensity so high, at some point it doesn't help anymore and create more bottleneck on mem access...

Yes, this is the maxwell mod. Less memory is good on windows because the operating system have problems with allocation big blocks of gpu-mem. Windows 8/10. With -X 16 the 750ti is using 1.8 Gig of memory in lyra2v2 +30 khash.

[Slava_K]

Now testing lira2v2 on sm50 (750Ti).
Miner show good hashrate. On pool side (nicehash) every 2.5 minutes connection reseted (when diff go from 2 up to 4 and 40 seconds miner dont take any yay!!). Problem same.
Pool shows speed 3-6 Mh - my 2x750Ti make 8.4 Mh...

[djm34]

I also submitted a 20% reduction in memory on the lyra2v2 algo so you can have higher intensities than before..
The default for the 750ti is -X 16. in release 63 it was -X 8
The default for the 970 is -X 26, in release 63 it was -X 16

not entirely a good idea, you are clearly sacrificing the 3.5 compute cards... (already noticed that in some previous change... I understand that you don't have these card, don't understand why you are removing the optimization done here) also it doesn't really matter how much memory you allocate if it isn't used, that's why I used that "#define memshift 3 (or 4")" to do that.
Don't really understand either why you are pushing the intensity so high, at some point it doesn't help anymore and create more bottleneck on mem access...

Yes, this is the maxwell mod. Less memory is good on windows because the operating system have problems with allocation big blocks of gpu-mem. Windows 8/10. With -X 16 the 750ti is using 1.8 Gig of memory in lyra2v2 +30 khash.

no actually it doesn't have a problem allocating big-block, as long as it doesn't use it full (checked that with ethereum), I suspect the compiler knows what to really allocate at compile time and actually the memshift of 4 was to allow smoother accesses to global mem at least with the 780ti... (problem was reversed in classic lyra)

[Grim]

release 63 (different codebase) --> solomining works
any other release including 64  --> solomining wont work

[zTheWolfz]

I also submitted a 20% reduction in memory on the lyra2v2 algo so you can have higher intensities than before..
The default for the 750ti is -X 16. in release 63 it was -X 8
The default for the 970 is -X 26, in release 63 it was -X 16

not entirely a good idea, you are clearly sacrificing the 3.5 compute cards... (already noticed that in some previous change... I understand that you don't have these card, don't understand why you are removing the optimization done here) also it doesn't really matter how much memory you allocate if it isn't used, that's why I used that "#define memshift 3 (or 4")" to do that.
Don't really understand either why you are pushing the intensity so high, at some point it doesn't help anymore and create more bottleneck on mem access...

Yes, this is the maxwell mod. Less memory is good on windows because the operating system have problems with allocation big blocks of gpu-mem. Windows 8/10. With -X 16 the 750ti is using 1.8 Gig of memory in lyra2v2 +30 khash.

no actually it doesn't have a problem allocating big-block, as long as it doesn't use it full (checked that with ethereum), I suspect the compiler knows what to really allocate at compile time and actually the memshift of 4 was to allow smoother accesses to global mem at least with the 780ti... (problem was reversed in classic lyra)

Link to your latest release please, thanks.

[sp_]

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

number 64.

But there are some experimenting on github with multiple threads.

[zTheWolfz]

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

number 64.

But there are some experimenting on github with multiple threads.

Sorry my request was to djm34. I had already seen and downloaded your latest release. thanks.

[sp_]

Now testing lira2v2 on sm50 (750Ti).
Miner show good hashrate. On pool side (nicehash) every 2.5 minutes connection reseted (when diff go from 2 up to 4 and 40 seconds miner dont take any yay!!). Problem same.
Pool shows speed 3-6 Mh - my 2x750Ti make 8.4 Mh...

There seems to be a bug if you use the -q (quiet) mode. Don't use -g 2 yet it's not working.

[Grim]

- Regarding developer work -

We should simply have a trusted escrow BTC address where we donate money to for a CERTAIN algo.

Once the dev thinks the escrow is worth grabbing he makes his work/code available as open source.
If it never reaches the threshold the dev thinks it's worth, then the escrow guy will refund the donators.

I would bet that a few btc would come together for each release.



This escrow model should be in BTC !!!
For smaller coins a % fee is utterly devastating to the coin itself cuz one guy (the miner dev) can dump below market price forever.


- EXAMPLE -

eg. djm tells us that his lyra2v2 miner does 6 MH
public miner does 4.5 MH

We open up a unique BTC escrow address where everyone can "donate" to.
Everyone can follow the BTC amount in a block explorer.

Once the dev feels comfortable to release the code he will do so,
if not so be it, someone else will probably grab the escrow soon enough.

[Slava_K]

Lyra2REv2:

[2015-09-03 00:11:31] accepted: 65/66 (98.48%), 27603 kH/s (nooooo)
[2015-09-03 00:11:31] reject reason: Duplicate share.
[2015-09-03 00:11:31] enabling duplicates check feature
[2015-09-03 00:11:37] GPU #2: GeForce GTX 960, 5242
[2015-09-03 00:11:39] GPU #1: GeForce GTX 980, 11282
[2015-09-03 00:11:40] GPU #0: GeForce GTX 980, 10614
[2015-09-03 00:11:40] accepted: 66/67 (98.51%), 27332 kH/s (yes!!!)
[2015-09-03 00:11:41] accepted: 67/68 (98.53%), 27119 kH/s (yes!!!)
[2015-09-03 00:11:42] GPU #1: GeForce GTX 980, 11351
[2015-09-03 00:11:42] GPU #2: GeForce GTX 960, 6039
[2015-09-03 00:11:43] GPU #0: GeForce GTX 980, 10679
[2015-09-03 00:11:43] accepted: 68/69 (98.55%), 27335 kH/s (yes!!!)
[2015-09-03 00:11:44] accepted: 69/70 (98.57%), 27150 kH/s (yes!!!)
.......
[2015-09-03 00:13:45] GPU #1: GeForce GTX 980, 11442
[2015-09-03 00:13:46] accepted: 81/82 (98.78%), 27177 kH/s (yes!!!)
[2015-09-03 00:13:46] GPU #2: GeForce GTX 960, 6014
[2015-09-03 00:13:47] GPU #0: GeForce GTX 980, 10714
[2015-09-03 00:13:47] GPU #1: GeForce GTX 980, 11406
[2015-09-03 00:13:49] GPU #2: GeForce GTX 960, 6042
[2015-09-03 00:13:50] GPU #0: GeForce GTX 980, 10293
[2015-09-03 00:13:50] GPU #1: GeForce GTX 980, 11207
[2015-09-03 00:13:59] GPU #2: GeForce GTX 960, 6005
[2015-09-03 00:14:00] GPU #1: GeForce GTX 980, 11433
[2015-09-03 00:14:00] GPU #0: GeForce GTX 980, 10748
[2015-09-03 00:14:02] GPU #1: GeForce GTX 980, 11166
[2015-09-03 00:14:02] GPU #2: GeForce GTX 960, 5847
[2015-09-03 00:14:02] GPU #0: GeForce GTX 980, 10599
[2015-09-03 00:14:04] nonce 95ad2703 was already sent 44 seconds ago
[2015-09-03 00:14:05] GPU #1: GeForce GTX 980, 11408
[2015-09-03 00:14:05] GPU #0: GeForce GTX 980, 10748
[2015-09-03 00:14:05] GPU #2: GeForce GTX 960, 6025
[2015-09-03 00:14:08] GPU #0: GeForce GTX 980, 10376
[2015-09-03 00:14:08] GPU #1: GeForce GTX 980, 11395
[2015-09-03 00:14:08] GPU #2: GeForce GTX 960, 5952
[2015-09-03 00:14:10] GPU #0: GeForce GTX 980, 9597
[2015-09-03 00:14:10] GPU #1: GeForce GTX 980, 11207
[2015-09-03 00:14:12] GPU #2: GeForce GTX 960, 3660
[2015-09-03 00:14:13] GPU #0: GeForce GTX 980, 10680
[2015-09-03 00:14:13] GPU #1: GeForce GTX 980, 8560
[2015-09-03 00:14:15] GPU #2: GeForce GTX 960, 4690
[2015-09-03 00:14:16] GPU #1: GeForce GTX 980, 11357
[2015-09-03 00:14:16] GPU #0: GeForce GTX 980, 10782
[2015-09-03 00:14:17] nonce 88b38eb0 was already sent 45 seconds ago
[2015-09-03 00:14:18] GPU #2: GeForce GTX 960, 6019
[2015-09-03 00:14:18] GPU #1: GeForce GTX 980, 11363
[2015-09-03 00:14:18] GPU #0: GeForce GTX 980, 10519
[2015-09-03 00:14:21] GPU #2: GeForce GTX 960, 6006
[2015-09-03 00:14:21] GPU #1: GeForce GTX 980, 11376
[2015-09-03 00:14:21] GPU #0: GeForce GTX 980, 6173
[2015-09-03 00:14:23] GPU #1: GeForce GTX 980, 11357
[2015-09-03 00:14:23] GPU #2: GeForce GTX 960, 5990
[2015-09-03 00:14:24] GPU #0: GeForce GTX 980, 10731
[2015-09-03 00:14:26] GPU #1: GeForce GTX 980, 10816
[2015-09-03 00:14:26] GPU #2: GeForce GTX 960, 6019
[2015-09-03 00:14:27] GPU #0: GeForce GTX 980, 10667
[2015-09-03 00:14:28] GPU #1: GeForce GTX 980, 11357
[2015-09-03 00:14:29] GPU #2: GeForce GTX 960, 5574
[2015-09-03 00:14:29] GPU #0: GeForce GTX 980, 10581
[2015-09-03 00:14:30] GPU #1: GeForce GTX 980, 11403
[2015-09-03 00:14:31] nonce a60a4f13 was already sent 45 seconds ago
[2015-09-03 00:14:32] GPU #2: GeForce GTX 960, 6007
[2015-09-03 00:14:32] GPU #0: GeForce GTX 980, 10748
[2015-09-03 00:14:33] GPU #1: GeForce GTX 980, 11357
[2015-09-03 00:14:38] GPU #0: GeForce GTX 980, 10714
[2015-09-03 00:14:39] GPU #2: GeForce GTX 960, 6025
[2015-09-03 00:14:43] GPU #1: GeForce GTX 980, 11433
[2015-09-03 00:14:51] GPU #0: GeForce GTX 980, 10782
[2015-09-03 00:14:51] GPU #2: GeForce GTX 960, 5242
[2015-09-03 00:14:56] GPU #1: GeForce GTX 980, 11433
[2015-09-03 00:14:58] accepted: 82/83 (98.80%), 27761 kH/s (yes!!!)
[2015-09-03 00:14:58] stratum connection reset
[2015-09-03 00:14:59] Stratum difficulty set to 4

[sp_]

Lyra2REv2:
[2015-09-03 00:11:31] accepted: 65/66 (98.48%), 27603 kH/s (nooooo)
[2015-09-03 00:11:31] reject reason: Duplicate share.
[2015-09-03 00:11:31] enabling duplicates check feature

Yes. I think this is the same bug as the solomining bug. On nicehash no new blocks are comming and the diff is not changed, and then there is an overflow somewhere.

[djm34]

- Regarding developer work -

We should simply have a trusted escrow BTC address where we donate money to for a CERTAIN algo.

Once the dev thinks the escrow is worth grabbing he makes his work/code available as open source.
If it never reaches the threshold the dev thinks it's worth, then the escrow guy will refund the donators.

I would bet that a few btc would come together for each release.



This escrow model should be in BTC !!!
For smaller coins a % fee is utterly devastating to the coin itself cuz one guy (the miner dev) can dump below market price forever.


- EXAMPLE -

eg. djm tells us that his lyra2v2 miner does 6 MH
public miner does 4.5 MH

We open up a unique BTC escrow address where everyone can "donate" to.
Everyone can follow the BTC amount in a block explorer.

Once the dev feels comfortable to release the code he will do so,
if not so be it, someone else will probably grab the escrow soon enough.

you really don't trust the devs, you need an escrow and we might dump the fee below market
such a bad reputation.
well first for "new" coin/algo I clearly don't accept as payment some worthless new coin   (still have my doomcoin bounty, so you see I don't really dump and there is a lot more chances, that devs gets dumped on by many miners than the inverse...).
So the fee system is clearly only for reputable coins not every new coins.

And regarding the escrow, I did that (without escrow, although people were getting the miner before reaching the minimum) for neoscrypt.  
and it took quite a long time to get to a couple of btc.

also donating until a certain amount is reached is beneficial for a coin community not that much for the individual miners who wants to get an advantage over other miners. So basically unless it is a consensus from a coin community (meaning something faster is needed), you can't really expect much donation because if everybody gets the faster miner at the same time, it doesn't benefit to them hence no point donating... here the fee system is clearly a better solution.

[myagui]

@djm34:
I think the logic proposed was that some trusted party/escrow was holding the bounty, so that any dev could come up and claim it with a working faster version. Was not so much about trusting the dev, as it was about allowing multiple devs to compete for the collected funds.

Personally, I'm not sure it is a great idea, since it brings even more developer competition into the table, instead of focusing on collaboration. I dunno, maybe I'm just a dreamer...  

Edit: I stand by my suggestion from the other day. I thought it would at least garner some comments, but I take it that it was not interesting in other people's views. Oh well... 

[scryptr]

- Regarding developer work -

We should simply have a trusted escrow BTC address where we donate money to for a CERTAIN algo.

Once the dev thinks the escrow is worth grabbing he makes his work/code available as open source.
If it never reaches the threshold the dev thinks it's worth, then the escrow guy will refund the donators.

I would bet that a few btc would come together for each release.



This escrow model should be in BTC !!!
For smaller coins a % fee is utterly devastating to the coin itself cuz one guy (the miner dev) can dump below market price forever.


- EXAMPLE -

eg. djm tells us that his lyra2v2 miner does 6 MH
public miner does 4.5 MH

We open up a unique BTC escrow address where everyone can "donate" to.
Everyone can follow the BTC amount in a block explorer.

Once the dev feels comfortable to release the code he will do so,
if not so be it, someone else will probably grab the escrow soon enough.

INTERESTING--

Although DJM34 had a personal fund when he was developing Neoscrypt for Cuda.  Bottom line is, I donate when a coder does a good job and contributes to the code base.  I never left a coder out, even when the code was absorbed by another coder...

Donate when a good job is done, and make sure not to leave out a contributor.

The escrow fund is a good idea, but is less secure than a direct donation when the job is done.  DJM34's crowd funding effort seemed to work, the fund was near 2 BTC when he released his code.  If a coder out there has the talent to really increase CCminer capacity, a "prize pool" might be a good idea.

--scryptr

[Slava_K]

Commit 1004 - quark is broken... Lyra2v2 on pool side is stable! But hashrate is 2 times slower...

[scryptr]

RELEASE dot 64--

Quark mines at 10.7Mh/s on my Win 7 box with the GTX 960 SSC.  I've enabled "cpu-priority" of 5, and set "cpu-mining" as true.  I also increased the intensity to 24.3, which was too high for previous versions.

These are initial results, I haven't been mining for several hours yet.  The desktop is a little slow, there is noticable lag as I type this.  But CCminer started right up, the initial accepted hash was over 10.7Mh/s, an improvement of ~100kh/s.

I'll compile the release for Linux and try my other rigs out later.  I still haven't maxed out the intensity setting yet on my Win 7, GTX 960 SSC box.       --scryptr


EDIT:  I bumped the intensity up to 24.5, and went out to  the store.  I came home to ~500 accepts and a 95% accept rate at 10.85Mh/s.  I think I am at the intensity limit, but I haven't tried.  My other rigs are running release dot 62 and getting 99% plus acceptance rates.       --scryptr