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.

2.2.1 would give you a lot more information than that with -n , like the very next poster:

[2012-01-31 21:54:21] CL Platform vendor: Advanced Micro Devices, Inc.
[2012-01-31 21:54:21] CL Platform name: AMD Accelerated Parallel Processing
[2012-01-31 21:54:21] CL Platform version: OpenCL 1.1 AMD-APP-SDK-v2.4 (595.10)
[2012-01-31 21:54:21] 6 GPU devices detected

I'd like to point out that as a benevolent dictator coordinating a project like cgminer, it is much easier for me to selectively take parts of Luke's code and selectively ignore things he tries to push that I disagree with. There is a lot of merit to the leader of a project having that kind of power. This is not a vote either way on this issue by the way. Nor am I suggesting that we should necessarily be giving that power to Gavin. However, it works for Linux Kernel with Linus at lead which is a much bigger project and complex codebase than bitcoin is, and it works for the various projects I work on which are much smaller.

Maybe because some of us in the bitcoin community still have a sense of humour.

Almost 24 hours has passed since 2.2.1 without massive death and destruction this time. Thank goodness. 

LOL AMD

Let's all get those facepalms out folks...

Goddamnit  

 

Love you all so far. Thanks!

I'm pretty sure the existing dual card code new in cgminer 2.2+ will be easy to extend to 7990 once it's out.

Don't forget it will install SDK2.6 and completely screw up your hashrates.

Make sure to add some fish oil for it to get some more omega 3 or the omega 6 rich nature of the vegetable oil will give it heart disease, cancer and all sorts of other awful diseases...  

Thanks a lot, but as I said, mine came back yesterday so assuming it stays up and running with the new motherboard, I will be fine 

Blame AMD for opencl and the ATI display library having no sure fire way of telling me so that I could tell you via cgminer.

And thank you

Okay so the GPU reorder saga brought up a few issues, lemme explain just for reassurance.

OpenCL and the ATI Display Library have completely different numbers for their devices - and there is no way to correlate the devices

- If they report exactly the same number of devices, and ADL was working properly (built in etc) then the last release worked fine.
- However OpenCL will report more devices than ADL if you have more than one display connected to one GPU.
- OpenCL will report less devices than ADL if you have a card that has no mining support.
- ADL will report only one device if you don't export DISPLAY on linux, or if you use some remote viewer on windows (I think).

On 2.2.0:
If you had less ADL devices than OpenCL, only the ADL devices would work, but the devices that worked on 2.2.0 would be different to the ones working on 2.1.2 because of the changed order.
->If you had less ADL devices, it would put all the mining threads on the one device.
If you had more ADL devices than OpenCL, hardware monitoring wouldn't work.
->If hardware monitoring didn't work, you often couldn't mine at all/crash whatnot.
On Linux the ordering was almost never out of order (unlike windows) but it was reversed. However it was not universally reversed...

On 2.2.1: Now I can cope with discrepancies in the number of devices and still have the option of trying to reorder by bus ID. So it's quite a safe option now, whereas previously it worked more often than not, but when it didn't work it would do weird and wonderful things.

It was getting impossible to debug this without a real mining rig and it was just fortuitous that my rig came back to me yesterday.

All in all, I was just dealing with more AMD facepalm...

New version: 2.2.1

So I'm really loathe to leaving a version out there that makes people adopt to massive change that may not have been a good idea, only to have to pull it again in the future. Today I had the luxury of my long-lost mining rig returning so I was finally able to actually do some meaningful debugging and testing of the code I was putting into cgminer and came up with the conclusion: 2.2.0 was a stinker. I spent most of today putting out all the spot fires under my feet and to release something a little more respectable as quickly as possible.

Here is 2.2.1, a mostly bugfix release.
Probably the most important fix is the fix for cgminer-generated midstate. This could cause massive rejects and is actually the main reason I put out a new release. This only affected pools that support the new work items which don't send midstate.
Bitforce support wouldn't actually build in 2.2.0 and the binaries I shipped didn't really have it built into it.
The whole GPU-reorder  saga caused massive damage, but we all learnt a lot from that one and there's much more useful verbose information of those issues in cgminer now, and that is useful even when GPU reordering is not enabled. When the number of devices doesn't match, cgminer will still continue to try to perform hardware monitoring.
There's more information now in --ndevs and we can use that to debug for real what SDK people are using
I've improved net-delay to not delay submission of shares since they're sporadic and any delays can be costly, especially for p2pool.
I also implemented something I've been meaning to do for a while: Only use one thread when dynamic mode is enabled on a GPU. It will make for even better interactivity of a desktop despite the miner running. The threads are re-enabled if you switch back to a static intensity.


Full changelog:

Version 2.2.1 - January 30, 2012

NOTE - The GPU Device reordering in 2.2.0 by default was considered a bad idea
so the original GPU ordering is used by default again unless reordering is
explicitly requested.

- Fix bitforce failing to build into cgminer.
- Add missing options to write config function.
- Add a --gpu-reorder option to only reorder devices according to PCI Bus ID
when requested.
- Fix for midstate support being broken on pools that supported no-midstate
work by ensuring numbers are 32 bits in sha2.c
- Set virtual GPUs to work when ADL is disabled or all mining will occur on GPU
0.
- Add information about paused threads in the menu status.
- Disable all but the first thread on GPUs in dynamic mode for better
interactivity.
- Set the latest network access time on share submission for --net-delay even if
we're not delaying that submission for further network access.
- Clear adl on exiting after probing values since it may attempt to overclock.
- As share submission is usually staggered, and delays can be costly, submit
shares without delay even when --net-delay is enabled.
- Display GPU number and device name when ADL is successfully enabled on it.
- Display GPU ordering remapping in verbose mode.
- Don't fail in the case the number of ADL and OpenCL devices do not match, and
do not attempt to reorder devices unless they match. Instead give a warning
about
- Display error codes should ADL not return ADL_OK in the more critical function
calls.
- Fix unused warning.
- Fix compile warnings in api.c
- Add extensive ADL based device info in debug mode.
- Make --ndevs display verbose opencl information as well to make debugging
version information easier.
- Display information about the opencl platform with verbose enabled.
- Explicitly check for nvidia in opencl platform strings as well.

This is tricky. It's very hard rolling back on such a big change. However I do think it was not the best idea to do it by default and the release has only been out one day. I suspect going to 2.2.0 will break far more people's configurations than going from 2.2.0 to 2.2.1, and then using the --gpu-reorder option will fix it (which is what I decided to call it). So, sorry, I've pretty much decided to make it default to off.

The git ride is about to get rather bumpy. Please be careful if you're pulling at random intervals.

With such a big update going to 2.2.0 it was inevitable some bugs would creep in. I'm trying to iron them all out and work on a bugfix-only 2.2.1 release as soon as is feasible. Having my mining rig AT LAST back will make it much much easier to test all this shit.

I know it's a bit late with having made the device reorder part of an official release but I was wondering if people would prefer it to be optional in the next release instead of mandatory? I know some of you have some complex set ups with config files and device specific setting and so on that will be broken on going to 2.2.0, and I'm not against changing it back to the old behaviour and making it optional with something like --dev-reorder .