So, for the fun of it, and because I don't have any newer graphics cards, I've modified m0mchil's poclbm into something that works on R600 video cards. These are the Radeon HD 2000 and 3000 series. I never bothered to rename it.

64-bit Windows binary http://dl.dropbox.com/u/38079179/poclbm-ati-brook-x64.zip

Source code http://dl.dropbox.com/u/38079179/poclbm-ati-brook-src.zip

Some of the hints on how to build the source code are in the comments on the bottom of the C++ files. To use the Python source, you need some current version of Python 2, Numpy, and Boost::Python. To use the Brook+ source, you need ATI Stream SDK 1.4 beta and some C++ compiler, and some common sense.

Let's discuss the reasons not to mine on an R600.

• By now, they are fairly old. Not all of them were that fast, either. I think my HP notebook is thermally throttling the video card.
• They don't support the gather/scatter I/O operations that the OpenCL miners use to minimize memory and bandwidth use.
• They don't have the 1-instruction rotate operation, that makes the modern Radeons so much faster than the modern GeForces. Nor do they have the 1-instruction bitselect instruction that AMD strangely doesn't expose to any APIs.
• Shifting is extremely inefficient, only 1/5 the speed of normal operations. That's because the ATI design has 4 simple ALUs and 1 "Transcendental" ALU in each processor. In the R600, only the T-unit does integer multiplies and logical shifts. (All of them do floating-point multiplies.) With the number of shifts in SHA-256, most of the time the simple ALUs sit around waiting for the T-unit.
• As a result, my video card (Mobility Radeon HD 3410) crunches through fewer hashes than my CPU (AMD Turion Neo X2 L625). If I didn't mangle poclbm too badly, it estimates that it crunches at a rate of roughly 0.850 MH/s.
• This miner doesn't adjust its work size. That's because of point 2 above, so adjusting work size involves destroying and allocating buffers. For some reason, it's really slow on my computer, taking up to several seconds. This is not something that can be done several times per second.

The AMD KernelAnalyzer says this SHA-256 kernel should operate at a rate of 5M threads/sec on a Radeon HD 2900, or 57M threads/sec on a Radeon HD 6970. Clearly, this is less efficient than the OpenGL versions on the GPUs that can run OpenGL. I may also have made horrible mistakes in modifying the source code, especially in BitcoinMiner.py.

In retrospect, when I saw that Stream SDK was 64-bit, I should have installed the 32-bit Stream SDK, instead of installing the 64-bit Python. And, when I saw that Klöckner had used Boost::Python for PyOpenCL, I should have ignored that and used the raw Python C API.

Also, while destroying and creating buffers is extremely slow, I don't see why it won't work if I have it allocate several buffers and switch between them according to load. I expect that a dozen buffers should take only a few MB, and my video card has 512MB total. Something to do maybe later, if it didn't have such low payoff.

Anyway, I think I can be convinced to produce a 32-bit binary for the low, low price of 5 BTC.

You can send me tips if you feel like it, too.
19gShNE2sdo9NP7N3kTYPjkqQ6ukPCP8jH