Updated git tree. (Thanks go to sveetsnelda for most of these fixes)

Update poclbm kernel for better performance on GCN and new SDKs with bitalign support when not BFI INT patching. Update phatk kernel to work properly for non BFI INT patched kernels, providing support for phatk to run on GCN and non-ATI cards.

If you're desperate to try these on windows, downloading the new files and using the old filenames will work

https://raw.github.com/ckolivas/cgminer/master/phatk120203.cl
https://raw.github.com/ckolivas/cgminer/master/poclbm120203.cl

use them to overwrite the existing
phatk110817.cl
poclbm110817.cl

This is not a magic performance enhancement. It might improve on nvidia if you can use the phatk kernel, and it will be significantly better on GCN (79xx cards) but will not match other kernels out there yet.

Windows applications have extra backdoors to the hardware to get around this. We have no cross platform->linux code that can do this, nor do I have access to how it's done on windows. So afterburner and others can work around this limitation.

Likely, based on what you've described, I'm guessing what you want is:
--auto-gpu --temp-cutoff 72 --gpu-engine 975

This will start it at gpu engine speed 975 and will not throttle it, and will enable the thermal cutoff feature if it his 72 degrees.

?

I expect that intensity 7-9 is optimal for just about every available card. Increasing intensity beyond this will likely make the displayed hashrate fluctuate more wildlly, but the average hashrate will be the same, and utility is unlikely to be affected positively or negatively. However, depending on which SDK/driver combination you use, CPU usage may rise quite dramatically when you get beyond the optimal value.

Luck plays too big a role in utility to make such a claim I'm afraid.

It means you're driving your card too hard, likely overclocking it too much for the available voltage and running temperature. cgminer tends to run GPUs extraordinarily hard at similar clocks compared to other mining software.

That is an awfully low cutoff, and cutoff doesn't throttle unless you set the overheat temp LOWER than it. However, if you specify --auto-gpu without ANY other parameters, like engine speed or memory speed, it will STILL turn off the GPU without adjusting GPU engine clock when it gets to temp cutoff.

So, summary:
--auto-gpu
by itself ends up enabling the cut off feature and nothing else, default is 95 degrees.

LOL 

This is a broken SDK installation.

There is no way on earth it only says 0 devices enabled. I'm trying to help you so I expect the courtesy of you actually using the goddamn command.

An -n output looks like this.
[2012-02-03 08:36:22] CL Platform vendor: Advanced Micro Devices, Inc.
[2012-02-03 08:36:22] CL Platform name: AMD Accelerated Parallel Processing
[2012-02-03 08:36:22] CL Platform version: OpenCL 1.1 AMD-APP (831.4)
[2012-02-03 08:36:22] Error: Getting Device IDs (num)
[2012-02-03 08:36:22] clDevicesNum returned error, no GPUs usable
[2012-02-03 08:36:22] 0 GPU devices detected

Setting the memory 125 below engine speed is a problem only on software that uses the ATI Display Library to adjust the speeds. There is windows software that has other means of poking the devices to adjust speeds that does not use the ADL. ATI have not made that information available, nor is it, I believe, crossplatform. Thus I can't use their approach since I don't have access to that information, and even if I could, it would probably only work on windows. Flashing the bios on these devices makes it respond via ADL to below 125 though.

Also, the ADL does allow me to try and set values outside the "safe range", and that's what cgminer does, but that doesn't mean the hardware will listen to you. Hence why it returns to you the now "reported" values after you try and set it from the menu so you can confirm for yourself if it has taken or not. I can set all sorts of things outside the safe range, but cannot set others.

More info would be good... hardware, driver versions, sdk version, and what "cgminer.exe -n" gives you from 2.2.1.

Thanks for the healthy discussion guys. The multiple input from various people makes it much easier to provide support if it doesn't all come from me.

Okay so on the temp-cutoff feature.

The theory behind the ADL usage in cgminer was that unless anything in GPU management was explicitly enabled, then cgminer should under no circumstances try and change settings itself. Thus auto-gpu must be enabled before temp-target, temp-overheat, or temp-cutoff are active. As ADL is unreliable in its ability to correlate which device is which from the mining, I was loathe to making it do anything unless the user had manually gone in and confirmed everything was working as anticipated. I really didn't want people to get "surprises".  Now having said that, since temp-cutoff doesn't actually adjust engine or memory clock speed, it may well be valid to have it enabled regardless. The default for temp-cutoff, as described in the readme  , is 95 degrees.

I had an absolutely massive rise in hashrate going from 0 to 5% (more than 5%). Going from 5 to 20, on the other hand, would make hashrates fluctuate wildly, but ultimately be the same average as 5%. So it seemed to be more of transient turbo boost  at levels above 5%, but since mining goes 24/7, it ended up being the same. There is no documentation about what powertune really does. Nevertheless, if you're well within good heat ranges, and powertune is available, it is *well* worth trying. To me it appears to increase hashrate proportional to the amount of power it it uses which is perfectly valid as far as I'm concerned. No, I don't have hard at-the-wall numbers to prove this.

cgminer is free software distributed under the GNU Public License.

opencl.dll is demon spawn distributed under the "sacrifice all your first born" license.

phatk110817.cl
Note the date on the kernel. It's unchanged since 17th August 2011. For static intensity hashing, it should be, for all intents and purposes, identical. Compare the .bin files generated and see if they're different. If so, something different is there in your setup making different  kernels (we already asceratained you're on the same sdk, unless you changed it up and then down again). If  not, then any difference just should not be there.

It's in these forums somewhere but I would just be searching for it too, sorry, since I haven't kept the link.

There's your answer. In 2.2.1, dynamic mode was made "lighter" on the desktop by using only one thread per GPU so that it is virtually not felt by the user. If you are on a dedicated mining rig, you need to give it a static intensity with something like -I 9 instead of leaving it dynamic.

Start the entire app the way you normally would and add "--verbose -D -T" and see what it says.