Great, will expect doom and hell-fire. :D

Ok, so here as well, something breaks the signature. Enigma has the same problem.
____________
Jord.

BOINC FAQ Service

They say most of your brain shuts down in cryo-sleep. All but the primitive side, the animal side. No wonder I'm still awake.

Albert@home is still an unofficial, non-public test project. Don't expect anything to work here. The only type of work Albert@home is currently sending out is for a highly experimental BRP4 OpenCL application.

Nah, that doesn't fix it but as you said, it's not a priority. The infinite work duration tasks that are sent... now that's another thing. ;-)

Although I think due to the way this setting is handled internally you shouldn't be able to opt-out of ATI 'work' right now.

Nothing but Computation errors so far on the OpenCL Wu's after just a few seconds. Tried 11.6 & 11.9 Drivers 5850 & 5870 Cards ...
____________
STE\/E

[20:05:56][5684][INFO ] Starting data processing...
[20:05:56][5684][ERROR] Failed to get OpenCL platform/device info from BOINC (error: -31)!
[20:05:56][5684][ERROR] Demodulation failed (error: -31)!

http://albert.phys.uwm.edu/result.php?resultid=35469

FWIW the App works when running standalone, it crashes only when running under the BOINC Client.

BM

D:\ProgramData\BOINC\projects\albert.phys.uwm.edu\einsteinbinary_BRP4_1.09_windows_intelx86__ATIOpenCL caused an Access Violation at location 007b481c in module D:\ProgramData\BOINC\projects\albert.phys.uwm.edu\einsteinbinary_BRP4_1.09_windows_intelx86__ATIOpenCL Writing to location 00000003.

OK, I got the new AtiOpenCL app 1.11, got a bucket load of work for it as well, but it doesn't start. I even suspended all my other work and still the OpenCL tasks didn't start.

So I have reset my preferences, set them back to use both CPU & GPU. Doesn't matter. I took out the <exclude_gpu/> option from cc_config.xml as it clearly didn't work yet, but that doesn't matter either.

Now I am confused. :)

For the doubters:
03/11/2011 23:32:02 | | ATI GPU 0: ATI Radeon HD 4700/4800 (RV740/RV770) (CAL version 1.4.1417, 1024MB, 992MB available, 2000 GFLOPS peak)
03/11/2011 23:32:02 | | OpenCL: ATI GPU 0: ATI RV770 (driver version CAL 1.4.1417, device version OpenCL 1.0 AMD-APP-SDK-v2.5 (775.2), 1024MB)
03/11/2011 23:32:02 | | No NVIDIA library found
03/11/2011 23:32:02 | | ATI GPU is OpenCL-capable
Catalysts 11.6 installed.

Edit: tried running the app stand-alone.
Activated exception handling...
00:24:28 (4688): Can't open init data file - running in standalone mode
00:24:28 (4688): Can't open init data file - running in standalone mode
[00:24:28][4688][WARN ] User/host details unavailable...
00:24:28 (4688): called boinc_finish
____________
Jord.

BOINC FAQ Service

They say most of your brain shuts down in cryo-sleep. All but the primitive side, the animal side. No wonder I'm still awake.

successfully received work for 2011 iMac/10.7.2 (Darwin 11.2)/ATI Radeon HD 6770M/

Start-up messages:

Wed Nov 2 23:05:55 2011 | | OpenCL: ATI GPU 0: ATI Radeon HD 6770M (driver version 1.0, device version OpenCL 1.1, 512MB)
Wed Nov 2 23:05:55 2011 | | ATI GPU is OpenCL-capable

Work Unit Start messages:

Thu Nov 3 20:27:03 2011 | Albert@Home | Starting task p2030.20100913.G48.73+01.03.S.b5s0g0.00000_1968_3 using einsteinbinary_BRP4 version 110 (ATIOpenCL)


WU started with an estimated remaining time of ~ 1:20:00. It has been processing for 2:10:00 and now estimates 3:46:00 remaining. Status reports: (0.20 CPUs and 1.00 ATI GPUs).

Jon

I'll post updates as processing continues/aborts/etc.

____________

Hmm, OK, so all that work mysteriously ran and erred within seconds. Th error is still the same as with 1.09

D:\ProgramData\BOINC\projects\albert.phys.uwm.edu\einsteinbinary_BRP4_1.11_windows_intelx86__atiOpenCL.exe caused an Access Violation at location 007b481c in module D:\ProgramData\BOINC\projects\albert.phys.uwm.edu\einsteinbinary_BRP4_1.11_windows_intelx86__atiOpenCL.exe Writing to location 00000003.

Appear to have completed the first WU successfully:

Fri Nov 4 04:59:49 2011 | Albert@Home | Computation for task p2030.20100913.G48.73+01.03.S.b5s0g0.00000_1968_3 finished

~8:20:00 of elapsed time. A second work request was made for ATI work and received 47 WUs (more than I really wanted but I'll let it run out as long as there are no major issues).

Jon

____________

[21:26:46][3292][INFO ] Starting data processing...
GPU type not found in init_data.xml
[21:26:46][3292][ERROR] Failed to get OpenCL platform/device info from BOINC (error: -161)!
[21:26:46][3292][ERROR] Demodulation failed (error: -161)!
[21:26:46][3292][DEBUG] Shutting down BOINC... Bye!
21:26:46 (3292): called boinc_finish

http://albert.phys.uwm.edu/result.php?resultid=37885

I got the infamous "GPU type not found in init_data.xml" errror with the recommended BOINC client version 6.12.34. Then I decided to update my BOINC client to version 6.13.10 (pre-release).

Now the "GPU type not found in init_data.xml" error is gone, but the computation ends with an access violation, see here.

I wouldn't expect OpenCL to work with clients older than 6.13.

Reminds me: we should probably add a client version restriction for these apps.

BM

OpenCL platform detected: NVIDIA Corporation
OpenCL platform detected: Advanced Micro Devices, Inc.

So? Just because Lunatics built a 3rd party application for Seti only that does the OpenCL detection, does not mean that the BOINC you're running does the OpenCL detection. This project uses the OpenCL detection built into the 6.13 clients to determine all OpenCL capable co-processors.

Added to that, as far as I know, the application here does not require an SSE3 capable CPU. The Lunatics app does.


10/11/2011 00:32:01 | | ATI GPU 0: ATI Radeon HD 4700/4800 (RV740/RV770) (CAL version 1.4.1417, 1024MB, 992MB available, 2000 GFLOPS peak)
10/11/2011 00:32:01 | | OpenCL: ATI GPU 0: ATI RV770 (driver version CAL 1.4.1417, device version OpenCL 1.0 AMD-APP-SDK-v2.5 (775.2), 1024MB)
10/11/2011 00:32:01 | | ATI GPU is OpenCL-capable

____________
Jord.

BOINC FAQ Service

They say most of your brain shuts down in cryo-sleep. All but the primitive side, the animal side. No wonder I'm still awake.

So? Just because Lunatics built a 3rd party application for Seti only that does the OpenCL detection, does not mean that the BOINC you're running does the OpenCL detection. This project uses the OpenCL detection built into the 6.13 clients to determine all OpenCL capable co-processors.

Then keep the boincmgr.exe and boinc.dll from your present installation. You can run a newer client with an older BOINC Manager.

But the messages aren't gone, they are just in a window of their own, reachable by clicking advanced->Event Log, or pressing CTRL+SHIFT+E.

As for 6.13, do know that even the latest client, 6.13.10 is highly unstable. I have managed to get it to crash 3 times already by just running this project. The 6.13s aren't available for long time use, they're test versions on the way to BOINC 7.
____________
Jord.

BOINC FAQ Service

They say most of your brain shuts down in cryo-sleep. All but the primitive side, the animal side. No wonder I'm still awake.

But the messages aren't gone, they are just in a window of their own, reachable by clicking advanced->Event Log, or pressing CTRL+SHIFT+E.

Current status:
* Windows: finally works, no known issues

I rebooted, just to make sure it wasn't something stuck in my GPU.
After reboot, I first started GPU-Z, then BOINC. No load on the GPU. Tasks don't run longer than a minute so far.

In comparison, running Furmark will do this:

The same result as Ageless already has showed:
http://albert.phys.uwm.edu/result.php?resultid=38235

After Upgrading to v6.13.10 on my ATI Box I now have 2 Wu's running, 1 on a 5870 & 1 on a 5850 ... Very inefficient though, using only 29% & 25% Of the GPU ... Need a App File to possibly run 2 or maybe 3 @ a time if possible ...
____________
STE\/E

FYI, we just updated the AMD OpenCL binaries for Windows, Mac OS 10.7 and Linux (all OpenCL 1.0, minimum BOINC version: 6.13.x).

Current status:
* Mac OS X: no known issues (10.7 support only!)

Greetings

Running a Win 7 x64 box with an HD 5850 on Catalyst 11.9, Boinc 6.13.10 x64, rxing ATI OpenCL work (done so via my preferences), completed my first work unit

http://albert.phys.uwm.edu/result.php?resultid=38178 (Computer ID 1323) Pending

So far no errors, have still 47 tasks that I am working my way through,

Am glad to jump onboard and help out

Keep the work coming and Happy Crunching

Regards
Tazzduke

*Finger's crossed*

Date , GPU Core Clock [MHz] , GPU Memory Clock [MHz] , GPU Temperature [°C] , Fan Speed (%) [%] , Fan Speed (RPM) [RPM] , GPU Load [%] , GPU Temp.(DISPIO) [°C] , GPU Temp.(MEMIO) [°C] , GPU Temp.(SHADERCORE) [°C] , Memory Usage (Dedicated) [MB] , Memory Usage (Dynamic) [MB] , VDDC [V] ,
2011-11-14 16:22:02 , 625.0 , 950.0 , 42.0 , 27 , - , 40 , 42.5 , 42.0 , 38.0 , 495 , 45 , 1.120 ,
2011-11-14 16:22:03 , 625.0 , 950.0 , 43.0 , 27 , - , 41 , 43.0 , 42.0 , 38.5 , 495 , 45 , 1.120 ,
2011-11-14 16:22:04 , 625.0 , 950.0 , 43.0 , 27 , - , 50 , 42.5 , 41.5 , 38.0 , 495 , 45 , 1.120 ,
2011-11-14 16:22:05 , 625.0 , 950.0 , 43.0 , 27 , - , 49 , 43.0 , 42.5 , 38.5 , 495 , 45 , 1.120 ,
2011-11-14 16:22:06 , 625.0 , 950.0 , 44.0 , 27 , - , 49 , 44.5 , 42.5 , 38.5 , 495 , 45 , 1.120 ,
2011-11-14 16:22:07 , 625.0 , 950.0 , 43.0 , 27 , - , 47 , 43.5 , 42.0 , 38.0 , 495 , 45 , 1.120 ,
2011-11-14 16:22:08 , 625.0 , 950.0 , 43.0 , 27 , - , 45 , 43.5 , 43.0 , 39.5 , 495 , 61 , 1.120 ,
2011-11-14 16:22:09 , 625.0 , 950.0 , 44.0 , 27 , - , 44 , 43.5 , 42.5 , 39.5 , 495 , 45 , 1.120 ,
2011-11-14 16:22:10 , 625.0 , 950.0 , 43.0 , 27 , - , 43 , 43.5 , 42.0 , 39.0 , 495 , 45 , 1.120 ,
2011-11-14 16:22:11 , 625.0 , 950.0 , 43.0 , 27 , - , 42 , 43.0 , 42.0 , 38.0 , 495 , 45 , 1.120 ,
2011-11-14 16:22:12 , 625.0 , 950.0 , 42.0 , 27 , - , 44 , 43.0 , 42.0 , 38.0 , 495 , 45 , 1.120 ,
2011-11-14 16:22:13 , 625.0 , 950.0 , 43.0 , 27 , - , 47 , 43.0 , 42.5 , 38.0 , 495 , 45 , 1.120 ,
2011-11-14 16:22:14 , 625.0 , 950.0 , 43.0 , 27 , - , 49 , 43.5 , 42.5 , 38.5 , 495 , 45 , 1.120 ,
2011-11-14 16:22:15 , 625.0 , 950.0 , 43.0 , 27 , - , 50 , 43.0 , 42.0 , 38.5 , 495 , 45 , 1.120 ,

<avg_ncpus>0.150000</avg_ncpus>
<max_ncpus>1.000000</max_ncpus>

The task is running, but going slowly. At present rate, with it taking 2 hours to do 22%, it'll take ~9 hours to do the whole 100%. A tad slow, when compared to a similar task at Einstein done on my CPU takes ~10 hours.

I've set BOINC to use 3 CPUs, leaving one open for the GPU and everything else non-BOINC.
____________
Jord.

BOINC FAQ Service

They say most of your brain shuts down in cryo-sleep. All but the primitive side, the animal side. No wonder I'm still awake.

So? Just because Lunatics built a 3rd party application for Seti only that does the OpenCL detection, does not mean that the BOINC you're running does the OpenCL detection. This project uses the OpenCL detection built into the 6.13 clients to determine all OpenCL capable co-processors.

Ok. Fine. Clear.
I'll try 6.13 some later, despite the fact that I don't like > 6.10 interface without Messages tab.

I am now using ATI5850 Driver11.9 and SDK2.5
Boinc version 6.13.12 and app 1.19
Progress 38% in 4hours ; hopefully completed in the morning...
GPU load is rarely above 0% sometimes it uses 100% for half a second
Running on win Vista 32bit

Now I will sleep. Goodnite all
____________

Could you mention a little more about what GPUs are suitable for the current A@H application? What I've seen so far suggests that it may require AMD/ATI GPUs, and is not ready for Nvidia GPUs yet.

For example, must the GPU have hardware support for double precision?

Also, is the current CPU application compiled from OpenCL, somewhat similar the the way the current POEM@HOME application is?

I've seen rumors that the 7.0 version of BOINC will be available soon, with at least some support for OpenCL GPU workunits, but almost nothing more on just how much OpenCL GPU support.

For example, must the GPU have hardware support for double precision?

I've seen rumors that the 7.0 version of BOINC will be available soon, with at least some support for OpenCL GPU workunits, but almost nothing more on just how much OpenCL GPU support.

Apart from that, we do have a dedicated CUDA app so we don't focus on running our OpenCL app on NVIDIA devices for the time being.

1 task completed!!!

:)

http://albert.phys.uwm.edu/results.php?hostid=1353&offset=0&show_names=0&state=2&appid=

http://albert.phys.uwm.edu/result.php?resultid=34526


____________

Not just that. On my travels, I've seen that due to ATI's different approach to GPGPU, from Close-to-Metal through BrookGPU to OpenCL, that their drivers are mature enough to support OpenCL on their hardware.

However, for you as a project engineer to be able to make it work on all the different hardware, you need a different API, SDK, IDE, debugger and probably compiler for each different piece of hardware by vendor. So one of each for ATI, one of each for nVidia, one of each for Intel, etc.

Hence why I ended the previous comment with "In a perfect world..." :-)
____________
Jord.

BOINC FAQ Service

They say most of your brain shuts down in cryo-sleep. All but the primitive side, the animal side. No wonder I'm still awake.

Looks like the OpenCL app for ATI can't validate against the CPU app: http://albert.phys.uwm.edu/workunit.php?wuid=11889

Oh and thanks for making the initial replication 3, but leaving the third one unsent. ;-)
____________
Jord.

BOINC FAQ Service

They say most of your brain shuts down in cryo-sleep. All but the primitive side, the animal side. No wonder I'm still awake.

Separate post for this, can you stop sending ATI OpenCL work to non-6.13 clients?
I see one of my other tasks is waiting for a wingman, because two people got "Failed to get OpenCL platform/device info from BOINC (error: -161)!" (6.12.34 and 6.10.60), the third had it running on the failed CUDA app.

Since you're checking for the information from the client, you may just as well make the client mandatory.
____________
Jord.

BOINC FAQ Service

They say most of your brain shuts down in cryo-sleep. All but the primitive side, the animal side. No wonder I'm still awake.

Oh and thanks for making the initial replication 3, but leaving the third one unsent. ;-)

Hm?

Guess what we do already? :-)
We're aware of that problem but there's no fix right now... Still investigating...

I've seen rumors that the 7.0 version of BOINC will be available soon, with at least some support for OpenCL GPU workunits, but almost nothing more on just how much OpenCL GPU support.

BOINC 7 (being tested as BOINC 6.13) will support both ATI and nVidia GPUs, with a possibility for Intel GPUs to follow once Intel gets an API out. But really, BOINC doesn't need to support OpenCL, as it doesn't do any of the work. The science application will need to do OpenCL.

All that BOINC will do is detect if your GPU is OpenCL capable and if so, which version it is compliant to. Just as it already did detect if the nVidia GPU is CUDA capable and the ATI GPU CAL/Brook+ capable.

Albert@home is still an unofficial, non-public test project. Don't expect anything to work here. The only type of work Albert@home is currently sending out is for a highly experimental BRP4 OpenCL application.

ATI OpenCL and CUDA32 don't validate together either.
http://albert.phys.uwm.edu/workunit.php?wuid=12465
____________
Jord.

BOINC FAQ Service

They say most of your brain shuts down in cryo-sleep. All but the primitive side, the animal side. No wonder I'm still awake.

Another one then, http://albert.phys.uwm.edu/workunit.php?wuid=11889.
That's one OpenCL vs two CPU, guess whose work was deemed invalid? ;-)
____________
Jord.

BOINC FAQ Service

They say most of your brain shuts down in cryo-sleep. All but the primitive side, the animal side. No wonder I'm still awake.

Also looks like you need more stringent GPU capability detection.
this host has an OpenCL capable GPU, but for some reason on has 384MB memory. Thus all its tasks err.

As far as I know you can set up the scheduler to check for OpenCL capability, memory on the GPU, BOINC client used, etc. GPUs like this need to be locked out, before they're sent work as else it's using unnecessary bandwidth and confuses the user to no end.
____________
Jord.

BOINC FAQ Service

They say most of your brain shuts down in cryo-sleep. All but the primitive side, the animal side. No wonder I'm still awake.

HD4890: 1WU = 62,806.60 sec = 17.5 hours and... 500.00 credits only, I guess? )
I understand, that A@H is a test project, but for my opinion it's a waste of time for HD4890.
Don't say me that HD4890 is a low-end GPU )
HD4890 brought me 1Ms in Collatz, MilkyWay, Moo! Wrapper.
In these projects HD4890 is more effective than GTX460, which usually spend only 1 hour for the same WU at Einstein@Home.

credits for this alpha project are 500 per WU that validates, irregardless of how long it takes to run. Also, last I read this project is soon not going to export stats, if they haven't yet turned that off.
____________

CAL ATI Radeon HD 4700/4800 (RV740/RV770) (1024MB) driver: 0.1

It seems Ageless and I have the same video card. Thus far, I haven't been able to validate a single WU:


http://albert.phys.uwm.edu/workunit.php?wuid=12534
http://albert.phys.uwm.edu/workunit.php?wuid=12549
http://albert.phys.uwm.edu/workunit.php?wuid=12550
http://albert.phys.uwm.edu/workunit.php?wuid=12551
http://albert.phys.uwm.edu/workunit.php?wuid=12294



Also (as mentioned above) it looks like there are problems with the nVidia cards validating with themselves (wu 12294):

The GTX 260 validates with the GTX 590, but not with the GTX 580.
____________

ATIOpenCL v1.19 doesn't validate with another ATIOpenCL v1.19 either:
TankMaster (HD 69xx) versus me (HD 4850) == http://albert.phys.uwm.edu/workunit.php?wuid=12850 (Completed, validation inconclusive) with a third task going out.

The next two tasks I have will be against other HD 48xx Radeons. I aborted all tasks that had CUDA or CPU as wingmen. They don't validate anyway so it's kinda useless to spend electrons on that at this time. Perhaps later again when there's been time to fine tune the validator even further.
____________
Jord.

BOINC FAQ Service

They say most of your brain shuts down in cryo-sleep. All but the primitive side, the animal side. No wonder I'm still awake.

ATIOpenCL v1.19 doesn't validate with another ATIOpenCL v1.19 either:
TankMaster (HD 69xx) versus me (HD 4850) == http://albert.phys.uwm.edu/workunit.php?wuid=12850 (Completed, validation inconclusive) with a third task going out.

Hmmm... Forget HR. Forget using any HD4850 it seems, or any OpenCL 1.0 only GPUs? I noticed that Infusioned now does have credit, but he did so with a CPU task, not his HD4850.

http://albert.phys.uwm.edu/workunit.php?wuid=12832 is my HD4850 versus Alexone's (presumably) HD4850 or 4870. Validation is inconclusive.
The difference here being my Intel i3 versus his AMD XII perhaps? Or my 8GB of RAM versus his 4GB?

A third task went out to a CUDA, we all know how that's going to end. I'm ending my extra electron burn here, I aborted the other similar task, since it would put my GPU against Alexone's again anyway. Either my GPU is broken, or I use a driver version your app doesn't like (Catalysts 11.6), or it's the direction of the ley lines crossing under my computer room that break things. I stop testing for now and turn my attention fully to Skyrim. ;-)
____________
Jord.

BOINC FAQ Service

They say most of your brain shuts down in cryo-sleep. All but the primitive side, the animal side. No wonder I'm still awake.

Due to a bug in the BOINC client this has to wait until at least 6.13.13 (should be released soon).

What's it you're saying, Oliver? You want me to return to 11.6?
That's no problem. I'm here to test work for you, remember? Totally not in it for the credits. :-)

I'll run the one ATIOpenCL v1.19 I have started already to completion on 11.7, then switch back to 11.6
____________
Jord.

BOINC FAQ Service

They say most of your brain shuts down in cryo-sleep. All but the primitive side, the animal side. No wonder I'm still awake.

Hello,

HD5770 fails after ~30 seconds
http://albert.phys.uwm.edu/result.php?resultid=51833

What's it you're saying, Oliver? You want me to return to 11.6?

No, you don't have to. You may of course do so as it wouldn't require a full core anymore.

So... will need an eye on what http://albert.phys.uwm.edu/workunit.php?wuid=13760 will go do. It's me versus two CUDA that can't decide between themselves who's right. I doubt I'll be the clincher for them. ;-)

So... will need an eye on what http://albert.phys.uwm.edu/workunit.php?wuid=13760 will go do.

Completed, marked as invalid
WTF?

Easily explained: http://albert.phys.uwm.edu/workunit.php?wuid=12082
You're ATIOpenCL, you were paired against two CUDA which walked away with the credits. The validator isn't tuned enough yet to see that these results may well have been the same.
____________
Jord.

BOINC FAQ Service

They say most of your brain shuts down in cryo-sleep. All but the primitive side, the animal side. No wonder I'm still awake.

This is from the Seti@Home Beta message boards (developing an ATi OpenCL App):


http://setiweb.ssl.berkeley.edu/beta/forum_thread.php?id=1867

Please, update your hosts with this builds. ATi and NV builds got speed increase, HD5-version added, NV version added.

CPU builds got some updates too.

Known issues:
1) As with OpenCL AstroPulse, last driver version from both vendors show increased CPU usage. AMD already aknowledged this issue and promised to fix in new Catalyst releases, NV still keeping silence about this issue.

2) OpenCL NV app can silently (i.e., w/o errors in stderr) produce incorrect results (overflows). Again, situation resembles NV AstroPulse rev521 case and usually means too long kernel call. Why NV OpenCL runtime doesn't report error code for kernel enqueue runtime call - no idea. But low-end NV GPUs could be not capable to use this app. This testing should determine GPU requirements for NV app too.

Thanks, I downloaded the WU and confirm the difference.

At least part of the problem is a long-standing issue which is seen in SETI@home Enhanced between the stock CPU and stock CUDA applications too. The most efficient order to do the various searches is different for CPU and GPU, so for this kind of task with a lot of potential signals the CPU finds a different subset than the GPU does. Eric Korpela is aware of the issue and maybe if he or Jeff Cobb get a chance the Validator code will be revised to judge quick overflow results differently.

The way that's pertinent to this case is the MB7 r365 sources are primarily targeting openCL builds so the Autocorr and Spike searches are done in a different order than stock 6.97.

At first glance, that doesn't seem to explain all the differences between the MB7 CPU result and 6.97 result. I need to analyze more to really be sure what the data indicates.

FWIW, those results will be considered "weakly similar" and both get credit when the third result is returned.

This is from the Seti@Home Beta message boards (developing an ATi OpenCL App):


http://setiweb.ssl.berkeley.edu/beta/forum_thread.php?id=1867

Please, update your hosts with this builds. ATi and NV builds got speed increase, HD5-version added, NV version added.

CPU builds got some updates too.

Known issues:
1) As with OpenCL AstroPulse, last driver version from both vendors show increased CPU usage. AMD already aknowledged this issue and promised to fix in new Catalyst releases, NV still keeping silence about this issue.

2) OpenCL NV app can silently (i.e., w/o errors in stderr) produce incorrect results (overflows). Again, situation resembles NV AstroPulse rev521 case and usually means too long kernel call. Why NV OpenCL runtime doesn't report error code for kernel enqueue runtime call - no idea. But low-end NV GPUs could be not capable to use this app. This testing should determine GPU requirements for NV app too.

Thanks, I downloaded the WU and confirm the difference.

At least part of the problem is a long-standing issue which is seen in SETI@home Enhanced between the stock CPU and stock CUDA applications too. The most efficient order to do the various searches is different for CPU and GPU, so for this kind of task with a lot of potential signals the CPU finds a different subset than the GPU does. Eric Korpela is aware of the issue and maybe if he or Jeff Cobb get a chance the Validator code will be revised to judge quick overflow results differently.

The way that's pertinent to this case is the MB7 r365 sources are primarily targeting openCL builds so the Autocorr and Spike searches are done in a different order than stock 6.97.

At first glance, that doesn't seem to explain all the differences between the MB7 CPU result and 6.97 result. I need to analyze more to really be sure what the data indicates.

FWIW, those results will be considered "weakly similar" and both get credit when the third result is returned.

Maybe this is part of the issue regarding validation?

Maybe this is part of the issue regarding validation?

It doesn't mean that NVidia cards don't silently generate overflows in general.

Also, the second post I quoted details how even the CUDA app was not validating against a CPU due to the order of calculations and the validator needed tweaking to regard them as weakly similar.
____________

Can the developers in the mean time fix the driver detection?

Sorry, not up to us. I'm not sure whether the BOINC devs can do anything about it since this might even be an AMD driver issue.

Oliver

Sorry, not up to us. I'm not sure whether the BOINC devs can do anything about it since this might even be an AMD driver issue.

Oliver

<coproc_ati>
<count>1</count>
<name>ATI Radeon HD 4700/4800 (RV740/RV770)</name>
<available_ram>1040187392.000000</available_ram>
<have_cal>1</have_cal>
<have_opencl>1</have_opencl>
<req_secs>0.000000</req_secs>
<req_instances>0.000000</req_instances>
<estimated_delay>0.000000</estimated_delay>
<peak_flops>2000000000000.000000</peak_flops>
<CALVersion>1.4.1417</CALVersion>
<target>5</target>
<localRAM>1024</localRAM>
<uncachedRemoteRAM>2047</uncachedRemoteRAM>
<cachedRemoteRAM>2047</cachedRemoteRAM>
<engineClock>625</engineClock>
<memoryClock>950</memoryClock>
<wavefrontSize>64</wavefrontSize>
<numberOfSIMD>10</numberOfSIMD>
<doublePrecision>1</doublePrecision>
<pitch_alignment>256</pitch_alignment>
<surface_alignment>4096</surface_alignment>
<maxResource1DWidth>8192</maxResource1DWidth>
<maxResource2DWidth>8192</maxResource2DWidth>
<maxResource2DHeight>8192</maxResource2DHeight>
<atirt_detected/>
<coproc_opencl>
<name>ATI RV770</name>
<vendor>Advanced Micro Devices, Inc.</vendor>
<vendor_id>4098</vendor_id>
<available>1</available>
<half_fp_config>0</half_fp_config>
<single_fp_config>62</single_fp_config>
<double_fp_config>63</double_fp_config>
<endian_little>1</endian_little>
<execution_capabilities>1</execution_capabilities>
<extensions>cl_amd_fp64 cl_khr_gl_sharing cl_amd_device_attribute_query cl_khr_d3d10_sharing </extensions>
<global_mem_size>1073741824</global_mem_size>
<local_mem_size>16384</local_mem_size>
<max_clock_frequency>625</max_clock_frequency>
<max_compute_units>10</max_compute_units>
<opencl_platform_version>OpenCL 1.1 AMD-APP-SDK-v2.5 (775.2)</opencl_platform_version>
<opencl_device_version>OpenCL 1.0 AMD-APP-SDK-v2.5 (775.2)</opencl_device_version>
<opencl_driver_version>CAL 1.4.1417</opencl_driver_version>
</coproc_opencl>
</coproc_ati>

Sorry, not up to us. I'm not sure whether the BOINC devs can do anything about it since this might even be an AMD driver issue.

Oliver

Of course it's up to you. Apparently the server back-end version that you use doesn't store the ATI/CAL driver version, but it is sent to you.

From my 7.0.2 sched_request_albert.phys.uwm.edu.xml file:

<coproc_ati>
<count>1</count>
<name>ATI Radeon HD 4700/4800 (RV740/RV770)</name>
<available_ram>1040187392.000000</available_ram>
<have_cal>1</have_cal>
<have_opencl>1</have_opencl>
<req_secs>0.000000</req_secs>
<req_instances>0.000000</req_instances>
<estimated_delay>0.000000</estimated_delay>
<peak_flops>2000000000000.000000</peak_flops>
<CALVersion>1.4.1417</CALVersion>
<target>5</target>
<localRAM>1024</localRAM>
<uncachedRemoteRAM>2047</uncachedRemoteRAM>
<cachedRemoteRAM>2047</cachedRemoteRAM>
<engineClock>625</engineClock>
<memoryClock>950</memoryClock>
<wavefrontSize>64</wavefrontSize>
<numberOfSIMD>10</numberOfSIMD>
<doublePrecision>1</doublePrecision>
<pitch_alignment>256</pitch_alignment>
<surface_alignment>4096</surface_alignment>
<maxResource1DWidth>8192</maxResource1DWidth>
<maxResource2DWidth>8192</maxResource2DWidth>
<maxResource2DHeight>8192</maxResource2DHeight>
<atirt_detected/>
<coproc_opencl>
<name>ATI RV770</name>
<vendor>Advanced Micro Devices, Inc.</vendor>
<vendor_id>4098</vendor_id>
<available>1</available>
<half_fp_config>0</half_fp_config>
<single_fp_config>62</single_fp_config>
<double_fp_config>63</double_fp_config>
<endian_little>1</endian_little>
<execution_capabilities>1</execution_capabilities>
<extensions>cl_amd_fp64 cl_khr_gl_sharing cl_amd_device_attribute_query cl_khr_d3d10_sharing </extensions>
<global_mem_size>1073741824</global_mem_size>
<local_mem_size>16384</local_mem_size>
<max_clock_frequency>625</max_clock_frequency>
<max_compute_units>10</max_compute_units>
<opencl_platform_version>OpenCL 1.1 AMD-APP-SDK-v2.5 (775.2)</opencl_platform_version>
<opencl_device_version>OpenCL 1.0 AMD-APP-SDK-v2.5 (775.2)</opencl_device_version>
<opencl_driver_version>CAL 1.4.1417</opencl_driver_version>
</coproc_opencl>
</coproc_ati>

You can even use the OpenCL information.
Then with the CAL version we can figure out which Catalysts they are. E.g. CAL 1.4.1417 is Catalysts 11.6

If you want to be totally confused, it does work on Einstein. See my account there.

You can't blame it on the client version either, it's merely all ATI that is affected. Examples: this host uses 6.10.58 and shows driver 0.1; this host uses 6.12.41 and shows as driver version 0.1
____________
Jord.

BOINC FAQ Service

They say most of your brain shuts down in cryo-sleep. All but the primitive side, the animal side. No wonder I'm still awake.

Jord, what exactly do you think should be fixed?

Well, whatever you did fixed that bug. It now shows on all hosts I checked which CAL driver version these people use. It may have been in there all this time, just not showing as such. So thanks. :)

Btw Oliver, BOINC 7.0.1 (the minimum requirement now) was never compiled and stored anywhere. The minimum minimum anyone could download was 7.0.2; only people who got the source code of branch_7.0 and compiled that on the 30th of November will have 7.0.1, all else will have 6.13.12 or 7.0.2. ;-)
____________
Jord.

BOINC FAQ Service

They say most of your brain shuts down in cryo-sleep. All but the primitive side, the animal side. No wonder I'm still awake.

Can the developers in the mean time fix the driver detection?

Sorry, not up to us. I'm not sure whether the BOINC devs can do anything about it since this might even be an AMD driver issue.

You may talk about two different things here.

Jord, what exactly do you think should be fixed?

I do see that displaying the ATI CAL/driver version on the host web pages appears broken (on Albert), and possibly the string in the DB is, too.

In the scheduler the ATI "driver" version is stored as "char version[50]" and "int version_num" in coproc_ati, and in "char opencl_driver_version[32]" in opencl_device_prop. These could in principle be used in app_plan(), though we don't check this yet.

BM

Since the upgrade to 7.0.2 I'm not getting any work for the GPUs ..

08-Dec-2011 07:20:02 [Albert@Home] Sending scheduler request: To fetch work.
08-Dec-2011 07:20:02 [Albert@Home] Requesting new tasks for ATI
08-Dec-2011 07:20:05 [Albert@Home] Scheduler request completed: got 0 new tasks
08-Dec-2011 07:20:05 [Albert@Home] No tasks sent
08-Dec-2011 07:58:09 [Albert@Home] Sending scheduler request: To fetch work.
08-Dec-2011 07:58:09 [Albert@Home] Requesting new tasks for NVIDIA
08-Dec-2011 07:58:11 [Albert@Home] Scheduler request completed: got 0 new tasks
08-Dec-2011 07:58:11 [Albert@Home] No tasks sent

host details are here:
http://albert.phys.uwm.edu/show_host_detail.php?hostid=1396

Any thoughts?
____________

Hm ... according to sched_request the ATI device isn't OpenCL capable:

<coproc_ati> <count>1</count> <name>ATI Radeon HD 5800 series (Cypress)</name> <available_ram>1024458752.000000</available_ram> <have_cal>1</have_cal> <have_opencl>0</have_opencl> <req_secs>0.000000</req_secs> <req_instances>0.000000</req_instances> <estimated_delay>0.000000</estimated_delay> <peak_flops>50000000000.000000</peak_flops> <CALVersion>1.4.815</CALVersion> <target>8</target> <localRAM>1024</localRAM> <uncachedRemoteRAM>1788</uncachedRemoteRAM> <cachedRemoteRAM>508</cachedRemoteRAM> <engineClock>0</engineClock> <memoryClock>0</memoryClock> <wavefrontSize>64</wavefrontSize> <numberOfSIMD>20</numberOfSIMD> <doublePrecision>1</doublePrecision> <pitch_alignment>256</pitch_alignment> <surface_alignment>256</surface_alignment> <maxResource1DWidth>16384</maxResource1DWidth> <maxResource2DWidth>16384</maxResource2DWidth> <maxResource2DHeight>16384</maxResource2DHeight> <atirt_detected/> </coproc_ati>

Weird .. with BOINC 6.13 the same ATI GPU completed scores of work units:

For example:
http://albert.phys.uwm.edu/result.php?resultid=53182

And I use the ATI GPU for OpenCL development all the time ..
____________

What exactly does BOINC do to check for OpenCL?
____________

Thanks Oliver. That was helpful. Figured it out .. it was a 64-bit Vs 32-bit issue. The ATI app is 32-bit, but the BOINC client I built is 64-bit. So, I had to make both 32 and 64 bit OpenCL libs available in my library path.

Its working now (finished a result successfully):
http://albert.phys.uwm.edu/result.php?resultid=54521

____________

Aborting task p2030.20100912.G57.94-00.24.S.b5s0g0.00000_416_1: exceeded elapsed time limit 6394.64 (2800000.00G/432.72G)

<app_version> <app_name>einsteinbinary_BRP4</app_name> <version_num>119</version_num> <platform>i686-pc-linux-gnu</platform> <avg_ncpus>0.150000</avg_ncpus> <max_ncpus>1.000000</max_ncpus> <flops>2402526409719.028320</flops> <plan_class>atiOpenCL</plan_class>

<coproc_ati> <count>1</count> <name>ATI Radeon HD 5800 series (Cypress)</name> <available_ram>1002438656.000000</available_ram> <have_cal>1</have_cal> <have_opencl>1</have_opencl> <peak_flops>4176000000000.000000</peak_flops>

This is quite a mission impossible from a BOINC perspective, isn't it? If the initial estimation is off too much, the WUs will ALL get terminated prematurely, and the server will NEVER get a valid result to adjust the estimation of the computation performance, which is actually needed to provide a good estimation for the max elapsed time in the first place!!

... The app would then do a short test run (app developers would know best how to do that) that returns an estimation of the runtime for the entire workunit.

Over on GPUGRID, I saw something about them finding that the HD4xxx series cards had some type of memory access problem - a limit on the amount of graphics memory each processor on the GPU can access before it starts using a much lower bandwidth path to the computer's main memory instead. I haven't kept up with whether more recent software updates have removed this restriction.

I think your card takes around 33k sec to complete a WU, so no matter what the theoretical (computed) peak performance is, the server would be right to assign a ca 7 times lower performance to your card.

The way of calculating (projected_)flops differs largely depending on how many tasks with this app version your host has successfully computed. Maybe this value differs between your hosts.

Have you thought of starting with a certain number of dummy tasks, to be replaced with similar information from tasks actually completed as soon as there are enough of them?

Some BOINC projects limit the number of tasks any computer can have downloaded and in progress at first, with this limit relaxed as soon as there are enough tasks successfully completed by that computer to get a better idea of how often it can handle yet another workunit.

I've read that at least some of the BOINC versions never initialize one of the variables often used in runtime estimation. You may want to add reporting of the variables you use so you can check for signs of this.

That's certainly an option to limit the effect of the runtime estimation / work fetch going mad. But actually I'd like to understand and fix what's going wrong in the first place.

Hi,

I also have aborted task due to

exceeded elapsed time limit 19036.53 (28000000.00G/1470.86G) problem

Output file p2030.20100913.G44.55+00.20.N.b6s0g0.00000_2424_1_3 for task p2030.20100913.G44.55+00.20.N.b6s0g0.00000_2424_1 absent