Updated tree:

I've imported the phatk kernel into minerd. The maximum possible throughput is slightly faster on machines that support amd media ops which is nice. However, even nicer is that on sane intensity levels (including the default value of 4), the throughput is significantly faster now as well. The phatk kernel unfortunately doesn't even work on hardware that doesn't have amd media ops (radeon 4x cards and nvidia) so for now it defaults back to the poclbm kernel.

I've also updated the cpu mining component. Now it tries to keep its work sizes within the log update interval instead of the scan interval so that the hash rate doesn't fluctuate all over the place. It is also possible now to set number of gpu threads to 0 to run minerd as just a cpu miner again.

TODO:
-I want to find ways of allowing even larger settings for intensity that would only be suitable for headless boxes. Currently the code ends up racing too much (with all the parallel processing) and generates far too many rejected blocks when the intensity is set to >10. Making the cl code synchronous would avoid that but it also slows it down, thereby making it pointless to push it further.
-Store binary versions of the kernels that could be loaded faster when restarting the app.
-Any bugfixing remaining.
-Profit.

Update tree:

I did incorporate that change into my kernel. It turns out that even though my hardware reports 4 as the preferred vector width, it's faster with 2. I assume many people have experienced the same. So I've made the default to be 2 when the hardware says its preferred vector width is anything larger than 1.

I found a little buglet that also would repeat some blocks, thereby artificially raising the hash rate, so the overall rate has dropped slightly (about the same amount it's increased with the other code!).

As for the daily builds, I assume the requester meant windows builds? Most people who have linux will likely be able to build it. It's not building on windows yet, but will in the near future I hope. If you really do want linux binaries, just say the word.

The problem with repeated blocks was my pool not sending me out longpoll information reliably.

linux only at this stage, sure I could do that.

Maybe it's just my pool. They're having a funky time so that would explain it.

I don't doubt it, and no one else is reporting this issue. The other machine I've tried it on it does give a speed up (with minerd) but this one 6770 I'm using it on reliably spits out tons of rejects when I make this change. It's not a heating issue, the card is at 64 degrees.

I can keep trying it on and off to see, but every time so far it has happened. It could well be my pool as they're experiencing technical difficulties, but it's always been the same time I enable it that I get the rejects.

2011-06-27 20:22:46] [173.08 | 191.67 Mhash/s] [81 Accepted] [40 Rejected]

Look at that reject rate. Normally it's <5%

With 4 vectors, this change actually slows down the hash rate. With 2 vectors it speeds it up, but then I get runs of rejected shares. Not sure why but this is consistent now so I'm reluctant to include it at this stage.

Thanks for your code. It's nice to see people get rewarded for their efforts (though it doesn't always happen). Well, I've tried it on my own miner (minerd) and have some very strange findings.

https://forum.bitcoin.org/index.php?topic=21275.0

First of all, minerd supports up to 4 vectors, and when I add this change to my kernel, it actually _slows down_ the 4 vector version. But when I override it to set 2 vectors, it speeds it up. However, once it's sped up, I then get runs of rejected shares. I tried it multiple times with and without and it does appear to be just this change that causes it, so I'm not sure what's going on.

Actually that was sheer coincidence. I'll test this change some more, thanks!

For some reason that's greatly increased my reject rate.

Don't forget cgminer:
https://bitcointalk.org/index.php?topic=28402.0
   
CGMINER ASIC, FPGA and GPU miner, GPU overclock+monitor+fanspeed in C for linux/windows/osx

Updated tree.

32 bits and BFI int patching is now working. For some reason on 64bit the opencl compiler builds an elf file within an elf file but not so on 32 bits. Go figure.

STILL TODO:
Testing and performance evaluation.
Windows builds (getting help from someone there hopefully it works).

Updated the tree:
Curl would crash if multiple instances are run at once from separate threads (seems to be a libcurl bug) so I've gone back to one instance of curl and pushed the threaded work submission / retrieval to a different place to still be non-blocking.
Updated the postcalc testing of nonces from GPUs to be done non-blocking in their own thread.
Further optimised the work loop.
Passed a fresh output buffer before the kernel is instantiated instead of after (could have led to stale blocks).
Patch source for BITALIGN separately from BFI_INT so that if bfi int binary patching fails, the kernel can be rebuilt without trying to BFI INT patch, but still benefit from bitalign on hardware that supports it. This means that 32 bit machines which were failing will at least work now with minerd, but with only part of the performance advantage available.

STILL TODO:
Performance for some GPUs is still well down that of other GPU mining software, and I'm still investigating why that is.
Implement BFI INT patching for 32 bit builds.
...
Profit.

Thanks, that's a bug on initialisation and is harmless. I'll see if I can avoid it in the future. I just wish I could figure out this 1/2 performance issue first.

Updated tree.

Thanks to burp, I now have a fix for building BFI_INT patched kernels on multi-gpu set ups. 32 bit machines don't get work with bfi int patching.

No CPU mining threads are now started if any GPUs are detected.

The CPU threads option has been changed to:
--cpu-threads

There is now a new option:
--gpu-threads N
(-g N) Number of threads per-GPU (1 - 10, default: 2)

By default it now spawns 2 threads per GPU to keep them slightly more busy for better throughput.

Numerous other cleanups have gone into it.

STILL TODO:
Performance for some GPUs is still well down that of other GPU mining software, and I'm still investigating why that is.
Implement BFI INT patching for 32 bit builds.
...
Profit.

Thanks. Has it ever actually worked for you with the 2nd GPU? The fix you posted earlier did not help others (on IRC) who had more than one GPU, if BFI_INT patching was involved. I don't think I've quite got the right fix for that yet, but it's at the top of my bug list to fix :|

Updated tree: Configurable vector width and worksize, more multi-gpu fixes and minor cleanups.

minerd now supports the following options:
--vectors N (where N is 1, 2 or 4)
--worksize N (where N is any number supported by the hardware up to max_work_size as reported when minerd is run with -D; usually up to 512)

Thanks. I'll implement the ability to override vectors and worksize to see if you can get good throughput by manually setting those.

Updated tree - I've made the getting of work more asynchronous by always having one work item extra in the queue. This means it is much less likely to get a drop in hash rates when connecting to a slow pool. This is particularly useful if you are on one side of the world and the pool you connect to is on the other side.

Thanks very much!