[19:27:27][4969][ERROR] Error during OpenCL FFT setup (error: -5)
[19:27:27][4969][ERROR] Demodulation failed (error: 2021)!

Sorry, not enough GPU memory.

It is Debian unstable, fglrx 11.11, amd-app 2.5, BOINC 6.13.12. The installation of amd-app is essential. Without it, neither primegrid nor albert@H binaries can be executed.

Why? What happens if you don't install it? The runtime libOpenCL.so should already be installed with the driver (as of 11.9 IIRC). Hm, maybe you still need to register the ICD...

Oliver

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.

I did return to 11.6, but left SDK 2.5 on my system.
Immediately the use of the one core went back to 02-10%, instead of the full 25% it was using before that on 11.7.

Skyrim is now also back to being a bit more stable. I had many more CTDs (crash to desktop) with 11.7 than I have had with 11.6; where with 11.6 it would be perhaps once a day, with 11.7 it was 7 times yesterday alone. So after the last CTD I reverted back to 11.6 ;-)

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. ;-)

---

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... 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. ;-)

As I thought, I wasn't the clincher. That task was crunched with catalysts 11.6

Looks like these don't validate to ATIOpenCL yet. Further fine tuning of the validator? I have suspended the last 3 tasks I have until I hear more. Although, I could of course abort them and see what the newer scheduler in 7.0.2 thinks I should get for loads of amounts of work. With a REC of 11000, too much anyway. ;-)

Remember, work that got credit is bad work. Work that didn't validate is good work. It tells the developers here their validator isn't ready yet to work in the outside angry world. :)

(and really developers, how many set it and forget it users do you have on here? ;))

---

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... will need an eye on what http://albert.phys.uwm.edu/workunit.php?wuid=13760 will go do.

I see it was another dud. It took another CUDA32 to get validated, me and another CUDA32 finishing outside the points.

I have 4 new tasks.
12537 is paired against a BRP3cuda32. I think I won't even try.
15980 is two ATIOpenCL. I wish driver detection here was working so I could make a reasonable guess as to what driver the other guy is using. Driver: 0.1 is useless.
15971 also has me paired against a BRP3cuda32.
15943 also has me paired against a BRP3cuda32.

15980 it is then.
Can the developers in the mean time fix the driver detection?

---

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.

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.

Maybe this is part of the issue regarding validation?

---

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?

I think the problem might be in the FFT and CuFFT variations....
But I am not sure. I saw something about such a discussion in another thread...

---

Maybe this is part of the issue regarding validation?

Nvidia cards are still using the CUDA app though, not OpenCL.

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

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

It seems to work in previous boinc manager versions. Maybe not in 6.13xx yet though....

---

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

---

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.

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

Jord has a point here.

And it can help users detect possible wrong drivers when they compare with other users. On the question, "which driver is the best driver for my ATI card?"

---

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.

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

Jord, what exactly do you think should be fixed?

Showing of the CAL driver version on ATI cards on the account pages here.

Yes, sorry, I said it wrong. I asked for a fix for the driver detection. I know you don't do that, that that's up to the client. I meant that all the driver versions showing for Nvidia GPUs is correct, for all ATI GPUs it's always 0.1, which isn't correct.

---

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.

Hm. On your host page I currently read:

AMD ATI Radeon HD 4700/4800 (RV740/RV770) (1024MB) driver: 1.4.1417

I don't see anything wrong with that. Maybe the previous entry was from an old Client version?

The only thing I changed this morning was (parts of) the web page code, but nothing related to the pages involved here.

BM

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.

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. ;-)

I know, I'm just using the exact tag/version that contains the required bug fix :-)

Oliver