Quote from: madjihad on January 02, 2014, 06:07:06 PM

Quote from: reorder on January 01, 2014, 05:59:01 PM

Quote from: Calhil on January 01, 2014, 05:02:50 PM

I also noticed skein doesnt need high memory frequency so you can decrease it almost all the way down without any performance hit. Skein miner is probably not optimized yet and thats why it needs less power i guess.

The kernel does not use VRAM at all (save for tiny bit to pass back results to miner), so yes, you can downclock it to minimum. It is optimized, though, but for GCN. Chances are that if you replace rolhack functions with rotates, arrays with variables and unroll skein rounds, it will perform better on VLIW architectures.

Current sha256_res imlementation form skein.cl performs too slow. I've tried to test double SHA256 hashing on current kernel, and replaced skein call with one more sha256_res call:

Code:

if(sha256_res((sha256_res(as_uint16(state)))) & 0xf0ffffff)
return;
output[OUTPUT_SIZE] = output[nonce & OUTPUT_MASK] = nonce;

And I've got 125MH/s on single 5870. So probably it's the bottleneck of current Skein-SHA256 opencl implementation.

I have never worked with opencl before, so I can miss something (or even everything

)

Yes, that W[] array is moved (by compiler) to registers on GCN, but apparently on VLIW it is not and uses global memory, which is slow. This can be improved of course (and first of all it does not have to be 62 elements long, 16 elements is enough if you reuse them). Just wonder how have you managed to compile sha256_res(sha256_res()): it takes uint16 vector as parameter, but returns only one uint.