Hi AMD team,
I just updated to the new WHQL-certified Catalyst 11.10
The 100% CPU load bug (for more than one GPU) is still there!
@AMD: Do you seriously give a damn about your users?
While on the topic of stuff missing from 10.10, bfi is again not present...I suddenly have found a crapload of use for that particular instruction...I knew it had value in my code previously, but it has become a performance hinge here with some extensions to my current usage of my implemented algorithm.
Well, I should say, I ran strings against aticaldd.dll again, and found it to be not present...
Yeah, still here. You guys said you'd fix GPU_USE_SYNC_OBJECTS. Argh :(
Updated to 11.10 under Linux x86_64. I can only see a single GPU and OpenCL still uses 100% of one core. The second Radeon 6950 is nowhere to be found... I'll go back to the outdated 11.5... :(
I can confirm that: 2 x 6970. 100% CPU load per core.
AMD is just one big joke!
[Edit]: I am just reading about the "AMD OpenCL™ Coding Competition with $50,000 in Prizes". Maybe AMD developers should enter this competition and try to get the prize for writing proper drivers. Obsiously they are not getting enough money - or time - to do their jobs properly. Or they are just plain stupid ...
What exactly is the issue with GPU_USE_SYNC_OBJECTS? I'm not sure if it is the same, but I'm trying to use SDK 2.5 with 3xHD5970, and the shell simply becomes unresposive from which I launched a multi-gpu application. I have already found, that if I have another terminal open in ssh, and I issue reboot, it does manage to reboot after a mintute or so, but since I'm 700Km from the server room, it is somewhat risky to experiment with graphics drivers, as updating linux graphics drivers is... unstable, to put it nicely.
It is kind of funny to read forums after this driver update. The first 3-4 topics are all about dising the new drivers.
I really don't want to go about swearing and all of that, but I have stated before, and will do it again: AMD should allocate MUCH more resources into driver development. I always read about features of new drivers, how they bring about 5% update in game A, and 25% in game B... etc. This is all nice and I know it is mandatory to stay competitive on the market. NV releases drivers every 3-4 months, but when they do, they are working (although they do have ENORMOUS mistakes from time to time too). It is a somewhat better practice of AMD to release drivers on a monthly basis, but... they lack the features (even in scopes of 3-4 months). I do play games also, but to be honest I give a lot more credit for functional additions, rather than performance in games. (For example it would be nice if I could create my own profiles to handle fan speed of GPU, or query fan RPM in association with GPUObserver gadget)
Linux drivers still a part of Xorg... that is one dire issue. Come on, we've been bitching about this one for years now. The CPU 100% bug... I don't feel it to be so crucial, but I do understand the concerns. Multi-GPU rendering the machine heavily unresponsive... one DIRE mistake yet again.
My point is, competition has solved being able to use multi-GPU from single thread. Single-thread, single-context multi-GPU working with CUDA 4.0. This is FEATURE. And on AMD side? Multi-thread, multi-context multi-GPU, still buggy. If I wasn't a fan of AMD, I would just laugh and turn my back. This way, I'm kind of disappointed.
I know it must be a pain to make drivers thread safe, but it seems it's about damned time to redesign the entire linux drivers as they are, because they are bleeding from so many wounds, it might just be better to put a mercy bullet in it's head and just create a new one.
Please, give this some thought, because people are getting delusioned from AMD due to the major lack of software support.
Originally posted by: Meteorhead Please, give this some thought, because people are getting delusioned from AMD due to the major lack of software support.
There is this old saying: "AMD/ATI has the hardware - NVIDIA has the software". Some things never change I guess ...
I can confirm, too. 100% CPU bug still exists on both Linux and Windows on all AMD cards i have.
Originally posted by: MicahVillmow The only work-around I can say right now is that windows is believed to not be affected by this issue.
You are joking, right?!?!
There are countless reports here in this forum that this bug does affect Windows platforms as well!
What's next? Are you going to ask me: "I can not reproduce this bug please send logs/programs?"?
I'll tell you what to do:
1) Take any two of your graphics cards.
2) Take any windows system (I tested XP32 bit, Win7 32 and 64 bit)
3) Use any Catalyst > 11.4.
4) Run any Open CL program
And you will be able to reproduce the 100% CPU load bug.
Seriously guys - it's not funny any more. You (AMD) are obviously f***ing us over.
Well multi-gpu never worked properly, at least not on linux. Since SDK 2.3 GPU_USE_SYNC_OBJECTS was introduced and it solved that problem perfectly. However with 11.5/SDK2.5 it stopped working. Setting that variable practically has no effect with any catalyst driver version using APP SDK 2.5.
On Windows, this environment variable never had any effect and it has exactly the same problem now.
Some people are trying to minimize energy consumption, using single-core low-power CPUs like Sempron for example and that's exactly where that 100% CPU utilization becomes a huge problem. It just kills performance.
I'm using Ubuntu 11.04-x86_64, drivers 11.6, in I do not have a problem with multi-gpu and 100% CPU utilizationMy system: Asus M4A79 Deluxe, AMD Phenom II X6 1055T, 3x AMD Radeon HD 6950
And which SDK are you using?
Since he is using Catalyst 11.6 it must be SDK 2.4. SDK 2.5 requires Catalyst 11.7.
It is exactly what is stated here: http://hashcat.net/wiki/oclhashcat_catalyst_forceware
Catalyst 11.4 - 11.6 do not have the 100% CPU issue
Quite frankly, I could live with the 100% CPU issue, if it weren't for the system crash on multi-GPU. The biggest benefit of SDK 2.5 is cached __global access by default ,and cl_khr_fp64. These two are the major updates of SDK 2.5 (at least for me). Only problem is: I can't make use of it. Clearly a lot of work put into it, but alltogether unusable for me.
Let me quote a classic: Much Ado About Nothing.
If damned linux drivers would finally install without GUI, we could use the entire VRAM, plus the same major driver redesign might also help solve the forementioned timing issues also.
If these would be done in say 2-4 months time, and SDK 2.6 expected sometime in February could introduce GWS (and maybe GDS) into OpenCL as an extension, that would be enough for me to forget these bunch of useless releases in SDK and drivers on linux part. Windows laptop works perfectly, but linux GPU cluster node...
Edit: oh, and sry, single-thread, single-context, multi-gpu would also kick@ss, but yet again I know it's not a matter of making me happy, but everyone else too. In fact that would be the entire idea behind contexts, is that multiple resources can be associated with them, and memory coherency is ensured inside a context. I know it is extremely complex to program, but hey... I'm an applied physicist, and not a programmer. My job is to develop for myself, and not for others.
I love how BOTH the current Nvidia and AMD drivers both have this same problem with OpenCL.
Originally posted by: arsenm I love how BOTH the current Nvidia and AMD drivers both have this same problem with OpenCL.
You sure? I heard that nVidia doesn't have this problem at all with the latest 280 drivers on Linux.
I'm seeing it in 285.05 Linux
Meteorhead: Does SDK support cached __global access by default on GPUs now? I didn't see anything of that in the release notes, but it rings a bell. Is this definite?
...I did notice some performance improvements from 2.4 to 2.5, but I would have expected more from my app assuming global cache were introduced at this point. Shame..I was looking forward to that speed bump..
It is sure, this is the corresponding part of release notes:
It is no longer necessary to use the -fno-alias compiler command line option.
-fno-alias was required to enable cached reads, with all the corresponding restrictions of no-alias. Now, those not apply. Or let me ask: do we still have to apply the restrict keyword to get cached reads?
Retrieving data ...