OpenCL apps are available for download on Lunatics

You cant compare HD5 app version against non HD5 app.
Stay tuned we will release new HD5 app soon.

____________

For those having trouble running Cat 13.1.
Just unistall APP runtime and use pre version under same drivers.

You might want to use a file manager like system commander.

Shut down Boinc

Go to C:/AMD/support/13-1_vista_win7_win8_64_dd_ccc_whql/Packages/apps/OpenCL64 directory and run OpenCL.msi to uninstall APP runtime.

Now follow this steps carefully.


Restart your computer.

Now unpack Cat 12.8. by clicking on it but abort installation and run OpenCL.msi from 12.8 package.

Restart your computer again.

Check with GPUz or GPUCapsviewer that OpenCL is checked.

Now you are running Cat 13.1. with OpenCL runtime from 12.8.

Hope this helps.
____________

For those having trouble running Cat 13.1.
Just unistall APP runtime and use pre version under same drivers....

I don't suppose it would be as easy as: start with clean install of 12.8, run 13.1 install but don't check the box for "APP SDK Runtime" ? IE keep the previous APP runtime?

1'st task done with 1761
http://setiathome.berkeley.edu/result.php?resultid=2821308526
Speed is about the same as 1363 and it works, which is the important thing.


Good Work!!!

I've noticed a warning message that's been bothering me since r1761:

• Affected hosts both run Windows XP.
  
• Affected hosts have this warning message on HD 4000 GPUs. HD 6000 GPUs (only other ATI GPUs I have) are not affected.
  
• This is only an issue on ATI AstroPulse. NV AstroPulse and ATI MB are not affected.
  
• Issue appears to be present in r1761, r1764, and r1766. It was not present in r1636.
  

I'm just wondering, is this going to be a problem for me? Are these hosts really going to spend CPU cycles recompiling for every single AP WU?
____________
Soli Deo Gloria

Its not really a problem.
Nothing changed depending binary creation since r1316 AFAIK.

Yes, it will create the binaries on each AP unit.

Maybe you changed something else.
Boinc/driver etc ?

____________

I've noticed a warning message that's been bothering me since r1761:

WARNING: can't open binary kernel file for oclFFT plan: C:\Documents and Settings\All Users\Application Data\BOINC/projects/setiathome.berkeley.edu\AP_clFFTplan_ATIRV770_32768_r1766.bin, continue with recompile...

On two of my hosts, I get this message with every single work-unit (and, obviously, I haven't purged any binary caches). This is what I've been able to find, relating to this warning message:

• Affected hosts both run Windows XP.
  
• Affected hosts have this warning message on HD 4000 GPUs. HD 6000 GPUs (only other ATI GPUs I have) are not affected.
  
• This is only an issue on ATI AstroPulse. NV AstroPulse and ATI MB are not affected.
  
• Issue appears to be present in r1761, r1764, and r1766. It was not present in r1636.
  

I'm just wondering, is this going to be a problem for me? Are these hosts really going to spend CPU cycles recompiling for every single AP WU?

I'll double-check when I get home, but I have restarted BOINC and the whole system at least a few times since r1761 was first released. I haven't changed the Catalyst drivers, but that's a good point: the affected hosts are using Catalyst 11.12, and none of my other hosts use that particular version.

As for the invalid results: yes, I'm aware of those. That's the AGP HD 4670 you helped me with some time ago. The funny thing about that card is that its failures (and successes) are inconsistent. With BOINC and the host remaining on continuously and no driver or other system changes, there will be a bunch of valid AP results for a while, then a bunch of invalid results, then a bunch of valid results... I do know that Catalyst 12.1 gives a lot of invalid results on this card, though, but Catalyst 11.12 is okay.
____________
Soli Deo Gloria

Phew, site is back on-line...

Interestingly, I just realised that the ATI bin cache is not being written to disk at all, which would explain the warning messages. Now the puzzle is why it's not being written to disk. The directory is not write-protected in anyway, and the other .bin_V6 and .wisdom cache files are being written as normal.

Any idea why the bin file isn't getting saved with each WU run?
____________
Soli Deo Gloria

Phew, site is back on-line...

Interestingly, I just realised that the ATI bin cache is not being written to disk at all, which would explain the warning messages. Now the puzzle is why it's not being written to disk. The directory is not write-protected in anyway, and the other .bin_V6 and .wisdom cache files are being written as normal.

Any idea why the bin file isn't getting saved with each WU run?

Ah, that makes sense. The 'patching' warning, that is, as both hosts where the .bin cache is not present also exhibit the patching warning. That's fine, as long as I know there's no major problem, I'm satisfied, thanks for the answer. APP SDK 2.5 support is supposed to start with Catalyst 11.7, so both hosts should be okay at Catalyst 11.12, anyway.

Just for the record, the HD 4850 has a workgroup size of 256, though it produces the patching warning.

Somewhat related, the invalid results you were observing on my HD 4670 earlier, I have a sneaking suspicion - though no valid proof yet - that the invalid results may be caused by CPU starvation. It's a very old Pentium 4 CPU on this host, so I don't have any CPU tasks running on it, but the AstroPulse NV tasks do cause a lot of CPU usage. I'm aware of the high-CPU usage issue in recent GeForce drivers... what's the most recent set of drivers that did not exhibit this high-CPU issue? After waiting so long for AMD to fix Catalyst's high-CPU usage problem, I'm disappointed Nvidia still hasn't fixed theirs...
____________
Soli Deo Gloria

Somewhat related, the invalid results you were observing on my HD 4670 earlier, I have a sneaking suspicion - though no valid proof yet - that the invalid results may be caused by CPU starvation. It's a very old Pentium 4 CPU on this host, so I don't have any CPU tasks running on it, but the AstroPulse NV tasks do cause a lot of CPU usage. I'm aware of the high-CPU usage issue in recent GeForce drivers... what's the most recent set of drivers that did not exhibit this high-CPU issue? After waiting so long for AMD to fix Catalyst's high-CPU usage problem, I'm disappointed Nvidia still hasn't fixed theirs...

Thanks for that. I haven't done any OpenCL development before, but I think I understand what's going on there.

After looking around, it seems OpenCL 1.1 was introduced with GeForce 280.26, with the release notes for GeForce 275.33 indicating OpenCL support is at 1.0. You're saying the CPU issue relates to the multi-threading drivers introduced with OpenCL 1.1 or did the switch to multi-threading happen before that?

Also, you say that OpenCL 1.1 is dependent on the developer to implement GPU call-back - is this the case for the current AstroPulse NV application?

I might give 275.33 a try tomorrow.
____________
Soli Deo Gloria

...After looking around, it seems OpenCL 1.1 was introduced with GeForce 280.26, with the release notes for GeForce 275.33 indicating OpenCL support is at 1.0. You're saying the CPU issue relates to the multi-threading drivers introduced with OpenCL 1.1 or did the switch to multi-threading happen before that?

Also, you say that OpenCL 1.1 is dependent on the developer to implement GPU call-back - is this the case for the current AstroPulse NV application?

Thanks for the information. I thought of one more point: I notice that running AP and MB simultaneously on the same NV GPU results in far lower overall CPU usage (on the GPU tasks) than running multiple AP WUs on a single NV card only. I notice this pattern across all hosts, where those hosts also run CPU-only tasks, on recent GeForce drivers.

Does this match your experience of running tasks on NV GPUs?
____________
Soli Deo Gloria

Does this match your experience of running tasks on NV GPUs?

Thanks for the information. I thought of one more point: I notice that running AP and MB simultaneously on the same NV GPU results in far lower overall CPU usage (on the GPU tasks) than running multiple AP WUs on a single NV card only. I notice this pattern across all hosts, where those hosts also run CPU-only tasks, on recent GeForce drivers.

Does this match your experience of running tasks on NV GPUs?

Thanks for the information. I thought of one more point: I notice that running AP and MB simultaneously on the same NV GPU results in far lower overall CPU usage (on the GPU tasks) than running multiple AP WUs on a single NV card only. I notice this pattern across all hosts, where those hosts also run CPU-only tasks, on recent GeForce drivers.

Does this match your experience of running tasks on NV GPUs?

It can be explained if postulate that OpenCL sync uses busy-wait loop while CUDA uses interrupt-based signalling (or smth more modern signalling that I'm not aware of but not busy-wait loop).
Then, if GPU busy with both OpenCL AP and CUDA MB kernels there is time for AP kernel to complete before driver thread starts to poll CPU constantly. Hence, lower CPU usage overall.
Also, I see BIG drop in CPU usage for the same reason between idle and busy CPU (studied in details on APU, observed on Intel "APU" (Ivy Bridge) and on "CPU consuming" NV drivers on GTX 260). If CPU busy with some work it will take longer time to switch to polling driver thread. Hence, GPU may report completion on first iteration saving CPU cycles for useful work.
Unfortunately, in this case CPU can easely become TOO busy to feed GPU unit with new work so, while CPU consumption will be quite slow, GPU load and overall host performance will drop considerably.
Hence, freeing core for GPU feeding is some sort of compromise.

If so, could somebody put together a recommended toolset and programming guide for study?