No, I can't personally improve on the reaper kernel because it does funky shit to work around the fact you can't allocate memory properly to the extent required to do so much parallel work with scrypt. However CUDA does allow you to allocate ram in a reliable fashion in much greater quantities and in layouts you desire without resorting to tricks. What I lack is the motivation and the incentive to start investigating what that would yield. I'm currently busy preparing for ASICs for BTC... and as I said, I can't guarantee what magnitude of improvement it would offer. The thing is that sha256(sha256()) as used by bitcoin mining is very easy to predict the effects of and there is no way to work around the fact that nvidia's integer performance sucks 1st and has no rotate function 2nd (and even adding rotate in Kepler will not be enough to offset the 1st).

Extensively...

Who is/are the developers that currently represent litecoin development?

Actually I toyed with some native CUDA (i.e. NVIDIA only GPU code) recently and found it has scope for doing things with memory that can't be done with openCL. While the integer performance on Nvidia cards is significantly below that of the AMD cards, approximately 96% of the calculation time in scrypt, by my profiling measurements, is spent on memory operations. I think there is scope for a Nvidia only CUDA kernel that would perform quite well compared to the OpenCL kernel that is currently used by both AMD and Nvidia cards on cgminer+reaper. How well I can't say, but I can say it would be a lot of work, and funding me to code it would be very expensive since I don't really care much about LTC, but I do enjoy coding (especially when funded). I also can't guarantee that it would somehow magically make nvidia cards better LTC miners than AMD. However someone else might find the idea interesting to pursue.

Ok.

Hey Bitsyncom, could you please post the source to your modifications to the GPL licensed cgminer code?

Thanks,
Con.

The one thing I don't understand in all this flameage is why Jeff Garzik isn't championing the request for source from Avalon. Jeff?

client.get_version

Supported by cgminer.

Meh I'm not getting involved. Even as a flamewar this got derailed to the point where I'm not even sure who's debating what 

I really have no idea. The GF count at the top tells you how many real disconnects you get. On a local machine it should pretty much never drop out, and on a local network it should only exceedingly rarely do so. On a remote pool with my fairly reliable connection (even through wifi!) I only get disconnects when the pool restarts their server or my  ISP has an outage, and that's something like 1 dropout a month.

Like I said, I didn't take that part out. Your card reports it wont take it, the function returns an error and then just generates even more crap than usual.

It's not enough to warrant a new release but here is a 2.10.5 win32 build with that one change:
http://ck.kolivas.org/apps/cgminer/temp/cgminer.exe

I'm well aware of the need for higher memory clocks but it makes no difference since I was already setting clock speeds high and getting 575kh.

I am unable to go beyond 12288 without the padbuffer being completely broken, and ignoring the return message that it fails to set the padbuffer just generates garbage if I disable it (which I haven't in this binary). Could have something to do with me having 4 GPUs in that rig as well, but I'm not taking it down from mining BTC to work on scrypt. This was a coincidental finding and I have admitted many times I don't understand how opencl scrypt really works and am not inclined to study it any further.

Intensities over 13 continue to generate garbage instead of more hashes. YMMV.

Please do not place any value whatsoever on the efficiency figure as it's virtually meaningless with stratum, and expected to be lower with frequent block updates of p2pool - and does NOT correlate with luck, performance, payment, value, btc, or anything.

If you do get disconnects and restarts, though, that is a totally different issue.

Actually I laughed for a bit and then I had to close it because it was too painful to watch 

Thanks to K1773R I was able to debug this crash. What's more interesting is this was also responsible for scrypt not being able to set thread concurrencies higher than 9999 on cgminer. So there is a fix for this bug in git now, and I have also confirmed I can now set thread concurrencies as high as 12288 on my 7970s... though it did not improve their hashrate at all. However at least it solves that mystery.

I understand the generic desire for 64 bit builds, but this is one application that does not in any way benefit from the 64 bit builds and it just adds yet another step to making releases, and there is no reason for it. A lot of the windows world is still 32 bit so 32bit binaries work everywhere. Hardly any of the linux world is 32 bit so 32bit binaries are the opposite there (and building it on linux is trivial anyway).

What for? It provides precisely zero performance benefit and just uses more memory.

Can't debug something unless it's with -g as well. -g shouldn't change the risk of crashing, but going from no optimisations to -O2 might.

He will stand unarmed in front of Kano's cold satanic blade and allow the lord to protect him.

It's a damn shame because the memory leak was very real and trivial to fix and fixed in the next release of cgminer. I'd suggest just using ozcoin (or a pool like it that supports setting high static diffs) to mine with, and set difficulty to 10,000. Then the number of shares submitted will be miniscule and it will take much longer to run out of memory. The only cost of doing that would be some more variance.

--gpu-engine 1070 --gpu-memclock 1365 --thread-concurrency 8192 -g 5
gives me about 575 khash on my 7970s