CCminer(SP-MOD) Modded GPU kernels.

[sp_]

Nice, you finally updated your fork

[djm34]

Nice, you finally updated your fork

the good thing with my complicated relationship with github is that I update only when necessary

[sp_]

I have merged all the files from tvpouvet (1.5.1git version)

New beta from github: Should support old cards as well. Compute 3.0 or newer.

http://www.filedropper.com/release19

x11 is down a bit, but hope that it is more stable

source

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

[Schleicher]

I have merged all the files from tvpouvet (1.5.1git version)
New beta from github: Should support old cards as well. Compute 3.0 or newer.

http://www.filedropper.com/release19

x11 is down a bit, but hope that it is more stable
source

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

I think you should check your files on github. There's some stuff missing.

[sp_]

I fixed it now. I am currently working with implementing uint2 into some of the hashingfunctions. (idea from DJM34 lyra implementation)

[sp_]

The uint2 keccak made x11 20-25 KHASH faster.  Checked in now.

[Amph]

Nice, you finally updated your fork

the good thing with my complicated relationship with github is that I update only when necessary

djm your version is the optimized one with 970-980?

[djm34]

Nice, you finally updated your fork

the good thing with my complicated relationship with github is that I update only when necessary

djm your version is the optimized one with 970-980?

actually, I think the main difference is in the compute 3.0 kernel which weren't there in that prelim. version.
It also add an adjustable throughput, which might be able to increase a little the hashrate over that version (in the limitation of memory bandwidt... ) or decrease it if it is plugged into a monitor (my gtx980 were causing some lag when they were plugged into a monitor)

The current implementation is already optimized for 9xx serie (that's the interest of the calculation using uint2 type actually) however because of the memory bandwidth limitation in the 9xx serie, the 780ti is doing better...

[Amph]

Nice, you finally updated your fork

the good thing with my complicated relationship with github is that I update only when necessary

djm your version is the optimized one with 970-980?

actually, I think the main difference is in the compute 3.0 kernel which weren't there in that prelim. version.
It also add an adjustable throughput, which might be able to increase a little the hashrate over that version (in the limitation of memory bandwidt... ) or decrease it if it is plugged into a monitor (my gtx980 were causing some lag when they were plugged into a monitor)

The current implementation is already optimized for 9xx serie (that's the interest of the calculation using uint2 type actually) however because of the memory bandwidth limitation in the 9xx serie, the 780ti is doing better...

what number your version is doing?

with sp version i'm currently at 7800 hash with one 970(1400 core)

[djm34]

Nice, you finally updated your fork

the good thing with my complicated relationship with github is that I update only when necessary

djm your version is the optimized one with 970-980?

actually, I think the main difference is in the compute 3.0 kernel which weren't there in that prelim. version.
It also add an adjustable throughput, which might be able to increase a little the hashrate over that version (in the limitation of memory bandwidt... ) or decrease it if it is plugged into a monitor (my gtx980 were causing some lag when they were plugged into a monitor)

The current implementation is already optimized for 9xx serie (that's the interest of the calculation using uint2 type actually) however because of the memory bandwidth limitation in the 9xx serie, the 780ti is doing better...

what number your version is doing?

with sp version i'm currently at 7800 hash with one 970(1400 core)

on x11 ? I don't know, but sp_ version should be better on x11, I haven't looked so far on x11 (the point of this version was Lyra2RE)

[Amph]

Nice, you finally updated your fork

the good thing with my complicated relationship with github is that I update only when necessary

djm your version is the optimized one with 970-980?

actually, I think the main difference is in the compute 3.0 kernel which weren't there in that prelim. version.
It also add an adjustable throughput, which might be able to increase a little the hashrate over that version (in the limitation of memory bandwidt... ) or decrease it if it is plugged into a monitor (my gtx980 were causing some lag when they were plugged into a monitor)

The current implementation is already optimized for 9xx serie (that's the interest of the calculation using uint2 type actually) however because of the memory bandwidth limitation in the 9xx serie, the 780ti is doing better...

what number your version is doing?

with sp version i'm currently at 7800 hash with one 970(1400 core)

on x11 ? I don't know, but sp_ version should be better on x11, I haven't looked so far on x11 (the point of this version was Lyra2RE)

oh that's a new algo, a fast google search tells me that is vertcoin releated, it's something anti-asic?

[K1773R]

HEAD@windows never submits any shares.

[djm34]

HEAD@windows never submits any shares.

you need to use --diff 128 (if it is related to lyra2re)

[djm34]

Nice, you finally updated your fork

the good thing with my complicated relationship with github is that I update only when necessary

djm your version is the optimized one with 970-980?

actually, I think the main difference is in the compute 3.0 kernel which weren't there in that prelim. version.
It also add an adjustable throughput, which might be able to increase a little the hashrate over that version (in the limitation of memory bandwidt... ) or decrease it if it is plugged into a monitor (my gtx980 were causing some lag when they were plugged into a monitor)

The current implementation is already optimized for 9xx serie (that's the interest of the calculation using uint2 type actually) however because of the memory bandwidth limitation in the 9xx serie, the 780ti is doing better...

what number your version is doing?

with sp version i'm currently at 7800 hash with one 970(1400 core)

on x11 ? I don't know, but sp_ version should be better on x11, I haven't looked so far on x11 (the point of this version was Lyra2RE)

oh that's a new algo, a fast google search tells me that is vertcoin releated, it's something anti-asic?

it is anti-asic for now...

[K1773R]

HEAD@windows never submits any shares.

you need to use --diff 128 (if it is related to lyra2re)

tested with x11 and x13. i see a big hashrate increase, tough never any submitted shares.

[sp_]

I just submitted an improved BMW rewrite.

32% faster. Using UINT2 instead of Uint64_t. Added new operators for uint2 operations. SHL2 and SHR2, and minus. (in cuda_helper.h)

Around +30-40 KHASH  on x11, x13 and x15

Now BMW is spilling 0 bytes to slow memory...

I also tried to use uint2 in blake, but it was slower.

[sp_]

HEAD@windows never submits any shares.

you need to use --diff 128 (if it is related to lyra2re)

tested with x11 and x13. i see a big hashrate increase, tough never any submitted shares.

Works here. Is this on linux? wich card?

[Epsylon3]

I had this while testing keccak uint2 changes with a sm30 only binary on the 750 ti... No errors but no found nonces neither.. So i commited the optimisation differently

[sp_]

Rewrote skein to use uint2. 10-20 KHASH on x11,x13,x15.  Added to github.

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

I see that this has also been done in the skein256 (lyra) but the code is different. Is the new implementation faster DJM34?

[sp_]

My version is probobly failing on sm30 cards.