My 780 is at stock with a build from the start of january as I havent botherd to compile a new one yet.

It is using 2.89gb of memory which is the main limiter

Win7 x64, 332.21, memory usage 2360MB from 6144MB


GTX 780 hits 4.4khash/s

post please parameters, gpu Mhz and build..incredible :-)

you want a lookup-gap of up to 6 on GTX 780 cards, specify it with the -L parameter.

Try with -L 2 first, let it autotune and increase the lookup gap one by one.
WARNING: autotuning may take long with enabled gap.

Stop when you find a power consumption vs kHash/s rate that suits you.

I find that a my 660Ti makes my GTX 780 card look poor in comparison. Not sure why that is, exactly (as the 780 has Compute 3.5 and way more SMX'es to work with).

Christian

Hi Christian,

I noticed some nice development on the Nvidia Developer Zone. When will you make this version available?
https://devtalk.nvidia.com/default/topic/643428/cuda-programming-and-performance/could-anyone-benchmark-this-for-me-on-a-780-ti-or-titan-/

Dennis

Alright, thank you.

Sounds reasonable enough for me

yes. right. there is one scratchpad but two streams. The scrypt_core kernels have to be serialized, or they would destroy each other's scratchpad. This is why I am using CUDA events.  

Some overlap of memcpy and kernels would be desired (not happening now due to issue order of commands), and possibly the SHA256/Keccak kernels of one stream could be executed concurrently with the scrypt_core kernels of the other stream. This is also not happening now because my CUDA events currently also serialize these (need to change when events are generated and synchronized upon).

I intend to get rid of memcpy alltogether by checking hashes on the GPU instead, so the memcpy/kernel overlap issue is moot.

Christian

3.7 kHash/s give or take.

but 6 or 7 would be nicer.

I have one optimization in mind that swaps the state of threads within the lookup_gap loop. The intention is to order threads by the loop trip count (some have to run for 0 loops, others a couple more up to the specified lookup_gap). By ordering them, some of the warps will terminate much earlier and not consume any computational resources.

This would (in theory) reduce the workload nearly by factor 2, but it introduces some overhead for sorting the threads, and for shuffling the state around. Whether a net speed gain remains ,  that is yet to be seen.

I will save that optimization for February (it would delay this release...)

Christian

I have Visual Studio 2012, but I can't load the solution file. So I probably have to wait a few more days.