Direct CUDA support is a lot of work and no one could afford to pay me enough to do it 

OpenCL implementation vary from driver to driver. When doing compute work, they can choose to "busy wait" on the CPU or sleep while waiting for the GPU to return its answers. Direct CUDA has a way to tell the device which mode to use, but OpenCL does not have any such command, thus it is entirely up to the driver/GPU/OS combination - and some GPUs you may never find a driver that doesn't busy wait. There is precious little experience with Nvidia drivers since their profitability is 1:4 compared to the electrical costs. You can try one of the new dedicated CUDA miners out there instead (although they will be primitive and buggy code since cgminer has been in heavy development for 2 years by comparison).

So I tried the current version of p2pool on a single 5.7GHz Jalapeño with cgminer connecting via stratum. This works out to about 80 diff1 shares per minute. It "works" in a sense of the word, without causing any weird errors or duplicating work that happen with the Avalon but there are huge lags between share submission and responses from p2pool after a while. Watching the CPU usage, I see a spike to 100% of one core whenever a block of transactions comes in and that coincides with the lag to respond to share submission, leading to more stale rejects if that occurs at the wrong time. The CPU in question is a 12 thread 3.4GHz CPU so it is clearly not underpowered. I suspect what happens on the Avalon is simply a grossly exaggerated form of this leading to misbehaviour.

My bad when I built it. Reuploaded now.

New release: Version 3.1.0, 28th April 2013

Lots of extra READMEs now.

EDIT: I was really tired when i posted this but really wanted to unleash it as soon as it was stable, and the BFL ASIC support really is the bulk of the change. Props to Kano for doing a large chunk of the driver work for this.

NOTE: If you are on windows and cannot get devices to initialise and they are on a USB 3 slot, try them on a USB 2 slot instead.

Human readable changelog:

BFL ASIC support.
(plus other stuff)

EDITS:
- The BFL ASIC driver uses direct USB instead of the serial USB interface, thus being much faster, more reliable, and using a lot less CPU. However as a consequence it needs a different driver installed on windows, and permissions set on linux. The ASIC-README has directions for all of these, and the zadig application which installs and configures the WinUSB driver for you is available from my download page.
- Updated READMEs, split up into GPU- and ASIC- as well.
- A fix for the corrupt display on exit on windows.


Full changelog:

- va_copy is meant to be matched by a va_end in log_generic.
- usbutils remove_in_use break
- usbutils remove_in_use missing prev
- usbutils missing add_in_use
- Clean up summary slightly better on exit.
- Make the scan sleep time after scanwork in bflsc dynamic to keep queues
between watermark levels.
- Remove unused temp counts in bflsc.
- Calculate a rolling 5 min average set of temperatures for bflsc.
- Damp the display of voltage for BFLSC devices.
- Damp the temperature display measurement for bflsc since it fluctuates so
wildly.
- bflsc add volt stats
- Handle failed tolines command in bflsc driver.
- Can use a read lock instead of a write lock in bflsc scanwork.
- Since we are filling a queue on the bflsc devices, there is no need to run
through scanwork frequently provided we use the restart_wait function to abort
early during a block change.
- Remove flushed work in bfl scanwork from the hash table.
- Set correct device in process_nonces in bflsc driver.
- bflsc add work reply INPROCESS: missing from the spec
- bflsc put in some error messages not yet written
- bflsc get completed hashes as late as possible
- Fix potential memory leak with unused work items in bflsc_queue_full
- Reverse bools in bflsc_queue_full
- Avoid recursive loop calling correct function instead.
- bflsc fix details identification
- Differentiate BFLSC device from regular bitforce and give warning if no
support is compiled in.
- util.c str_text make a fully text readable version of str
- BFLSC fix FPGA identity overlap
- Locking error in bflsc_send_work
- Use htobe32 function for converting nonce in bflsc.
- Replace deprecated bzero with memset in bflsc driver.
- Fix compilation of bflsc driver without opencl.
- Check for realloc failures in bflsc driver.
- Check for failure to calloc in bflsc driver.
- Trivial style change
- Use copy_time function in bflsc driver.
- Use cgtime in bflsc driver and update copyright notice.
- Use a separate function for bfl initialise that doesn't require locking.
- Fix BFLSC building.
- bflsc v0.1

EDIT:
Jalapeno hashing looks like this:


See also Kano's blog post:
http://www.kano-kun.net/?p=65

Nonsense that would have no effect on your hashrate. The reason it's larger is the exe is compiled with support for all the drivers.

Not my style, but I can take a photo if you like. However there are quite a few photos of them around now.

Just managed to get the first stable run of the new cgminer code for BFL ASICs on the Jalapeño with the early working code for it.

(5s):5.974G (avg):5.916Gh/s | A:748  R:4  HW:0  U:38.2/m  WU:86.6/m

Seems it's a bit faster than advertised which is nice. Not sure exactly why that is but perhaps the earlier ones were not the final boards they were going to release them with. More news as it comes to hand...

Kano and I got ours today. Since Kano took photos I didn't see any need to myself:
http://www.kano-kun.net/?p=56

Shhh! We're busy coding...

Fedex

Hackathon is underway. As soon as the code is in git master and working, I will inform the forum.

EDIT: I've received one too now.

Get to work on the driver then you lazy sod.

no

--shaders is just a hint to tune the program, it has no effect on the GPU. There is some advanced code to partition GPUs with OpenCL to do different tasks, but that is way beyond the scope of what we do with mining, and does not partition some shaders off as such. Mining both concurrently will likely produce lower results than the sum of each at half or at best, just equalling the sum of the halves. I suspect scrypt will kill the btc mining as well so you'll get very unbalanced work in favour of scrypt.

Summary, don't waste your time. Mine one or the other.

--remove-disabled

Well not all is lost. The tuning on those is just very different and is better with lower TCs, intensity and more gpu threads, but the hashrates are not better.

Assuming you are talking about the stock reference design, most of the cgminer GPU development of the last year was done with these cards. They are excellent. They vary in quality of course and my worst produced ~685MH and the best ~720MH on BTC. The best LTC miner produced ~745KH.

See here:
https://bitcointalk.org/index.php?topic=174036.0

I'm guessing the non-reference cards use a chipset design/layout/timing that simply does not work as well for this workload thanks to some exquisitely timing sensitive harmonics.

Ironically the overclock 7970 GPUs don't mine LTC as well as the stock reference design. It's (now) a well known issue.

You're most welcome