We're just guessing at the requirements for this version, so point me at any hosts that are repeatedly failing with this app version.

The app is fully OpenCL 1.0 compatible.

I tested on HD 4770 (RV 770) HD 4850 with driver 12.1.

Work group size 256 required.

I suggest driver version 12.1. and newer.

Running Windows XP driver 12.1 is the last driver with OpenCL support.

Mike

And I'm running my HD4850 on Vista with driver version 12.4, which also is an OpenCL 1.0 driver on the 4850. Apparently HD4850 doesn't support other than OpenCL 1.0, so no matter which newer driver you install, you will not get anything more than OpenCL 1.0 on that card.

But you knew that already Mike, I'm just a bit chatty :-)

HD 4xxx only has OpenCL beta Level support and now is officially depreciated by AMD.
http://developer.amd.com/TOOLS/HC/AMDAPPSDK/pages/DriverCompatibility.aspx

Which means it might work but must not.
I found out RV 770 works O.K.

---

With each crime and every kindness we birth our future.

Can't believe it's finally here! I almost gave up hope on running S@H on my ATI.
Already completed successfully 4 units or so. Took about 20 minutes per task. Crunching on...but only have 2 tasks on my machine at a time. Speaking of which: is there some sort of limitation or have I been knocked down to unreliable?

Win 7 Ultimate x64
Asus ATI 6870 1GB stock frequencies
Boinc 7.0.28 (x64)

Cheers!

---

Per aspera, ad astra!

Can't believe it's finally here! I almost gave up hope on running S@H on my ATI.
Already completed successfully 4 units or so. Took about 20 minutes per task. Crunching on...but only have 2 tasks on my machine at a time. Speaking of which: is there some sort of limitation or have I been knocked down to unreliable?

Win 7 Ultimate x64
Asus ATI 6870 1GB stock frequencies
Boinc 7.0.28 (x64)

Cheers!

Maybe you need to increase your preferences here.
Just go to your account and change keep enough work for x days.

---

With each crime and every kindness we birth our future.

There has to be some difference though between our results.

wuid=4153634

The first listed result (from host 59866) is missing a best_spike entry in its result file. I'm not sure why that would happen.

The name of that workunit alone indicates a problem in the splitter that I will have to track down and fix.

---

We're just guessing at the requirements for this version, so point me at any hosts that are repeatedly failing with this app version.

The app is fully OpenCL 1.0 compatible.

I tested on HD 4770 (RV 770) HD 4850 with driver 12.1.

Work group size 256 required.

I suggest driver version 12.1. and newer.

Running Windows XP driver 12.1 is the last driver with OpenCL support.

Mike

And I'm running my HD4850 on Vista with driver version 12.4, which also is an OpenCL 1.0 driver on the 4850. Apparently HD4850 doesn't support other than OpenCL 1.0, so no matter which newer driver you install, you will not get anything more than OpenCL 1.0 on that card.

But you knew that already Mike, I'm just a bit chatty :-)

HD 4xxx only has OpenCL beta Level support and now is officially depreciated by AMD.
http://developer.amd.com/TOOLS/HC/AMDAPPSDK/pages/DriverCompatibility.aspx

Which means it might work but must not.
I found out RV 770 works O.K.

Well, I guess I should upgrade my HD4850 to something newer. Reluctantly though, since it served me well, since 2008. I have to take a look at what I can get without totally emptying my bank account :-)

...
The name of that workunit alone indicates a problem in the splitter that I will have to track down and fix.

WUs with that sort of name were first noticed on the main project, shortly after maintenance two weeks ago.

new WU numbering scheme

There has to be some difference though between our results.

wuid=4153634

The first listed result (from host 59866) is missing a best_spike entry in its result file. I'm not sure why that would happen.

The name of that workunit alone indicates a problem in the splitter that I will have to track down and fix.

The name yes, I've been wondering about the new naming of WU's both here and on main. There seems to have been a change of how WU's are named. I have tons and tons of WU's with different naming types from what we've been used to, both here and on main. That's been going on for a couple of weeks now, and the new type of naming is now the norm rather than the exception

Example old type could be named:

05ap10al.31522.890.6.14.185_1

New naming example:

05ap10al.31522.1299.140733193388038.14.77_0

Hi Mike,

Just as I came back because I had seen the "error of my ways", you had already replied. Indeed, being used to always keeping a cache of at least a day of work, I forgot that I recently changed my preferences to 0, because of the recent WCG HCC GPU app release.

Thanks anyway!

---

Per aspera, ad astra!

That huge number is supposed to be the ID of the receiver we used, which is obtained from a library routine. I'm guessing that at some point the library was compiled with a version of g++ that doesn't have the same storage format for the data type used.

Fortunately the correct values is used in the workunit header, so we don't have to do all this work over.

---

That huge number is supposed to be the ID of the receiver we used, which is obtained from a library routine. I'm guessing that at some point the library was compiled with a version of g++ that doesn't have the same storage format for the data type used.

Fortunately the correct values is used in the workunit header, so we don't have to do all this work over.

On the main board, Joe posted

The 140733193388045 is hexadecimal 7FFF0000000D so the excess is only in the upper 32 bits, I'm reasonably sure the proper channel indicator would be hex D or decimal 13 for that WU. For mental conversion, subtract 32 from the last two digits.

which perhaps points to a 32 bit/64 bit problem.

Yes. So my assumption of a bad compile of the library was wrong. A fresh compile has the same problem.

It appears the g++ is taking the liberty of storing enums as 32 bit quantities, but when converted back to integer, the upper 32 bits of the integer get undefined values. Either that, or when presented with 'enum { A=0, B }' is assigning 0xffffffff00000001 to B rather than 1.

Or there could be a problem in the std::map container that is mangling the upper 32 bits of integers.

---

Back to topic:
As we can't compare results "on the fly" due to lack of info CUDA app provides (we discuss this on Lunatics intencively now) I propose to post links to suspictious workunits with ATi app involved (not results, workunits, please, to save time of reviewer) in separate thread. To organize testing more effectively.

I will start such thread soon. We need to form test case base for further investigation.

Eric, ATI HD4650 should be excluded (as having workgroup size of 128 -the is known incompatibility with such cards).

We're just guessing at the requirements for this version, so point me at any hosts that are repeatedly failing with this app version.

The app is fully OpenCL 1.0 compatible.

I tested on HD 4770 (RV 770) HD 4850 with driver 12.1.

Work group size 256 required.

I suggest driver version 12.1. and newer.

Running Windows XP driver 12.1 is the last driver with OpenCL support.

Mike

And I'm running my HD4850 on Vista with driver version 12.4, which also is an OpenCL 1.0 driver on the 4850. Apparently HD4850 doesn't support other than OpenCL 1.0, so no matter which newer driver you install, you will not get anything more than OpenCL 1.0 on that card.

But you knew that already Mike, I'm just a bit chatty :-)

HD 4xxx only has OpenCL beta Level support and now is officially depreciated by AMD.
http://developer.amd.com/TOOLS/HC/AMDAPPSDK/pages/DriverCompatibility.aspx

Which means it might work but must not.
I found out RV 770 works O.K.

Well, I guess I should upgrade my HD4850 to something newer. Reluctantly though, since it served me well, since 2008. I have to take a look at what I can get without totally emptying my bank account :-)

6670 with DDR5 memory if it isn't too slow.

Back to topic:
As we can't compare results "on the fly" due to lack of info CUDA app provides (we discuss this on Lunatics intencively now) I propose to post links to suspictious workunits with ATi app involved (not results, workunits, please, to save time of reviewer) in separate thread. To organize testing more effectively.

I will start such thread soon. We need to form test case base for further investigation.

Good idea, thanks!

---

Either that, or when presented with 'enum { A=0, B }' is assigning 0xffffffff00000001 to B rather than 1.

It's worse than that. When presented with 'enum { A=0, B }', g++ is assigning 0xffffffff00000000 to A and 0xffffffff00000001 to B.

---

Back to topic:
As we can't compare results "on the fly" due to lack of info CUDA app provides (we discuss this on Lunatics intencively now) I propose to post links to suspictious workunits with ATi app involved (not results, workunits, please, to save time of reviewer) in separate thread. To organize testing more effectively.

I will start such thread soon. We need to form test case base for further investigation.

Good idea, thanks!

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

Hey, hey! Got my first validated unit http://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=4157040! Everything seems to be working smooth here.

Good job!

---

Per aspera, ad astra!

Hey, hey! Got my first validated unit http://setiweb.ssl.berkeley.edu/beta/workunit.php?wuid=4157040! Everything seems to be working smooth here.

Good job!

LoL, one of still quite rare ATi vs ATi validations :)

I must confess that I have been cheating...

I did one OpenCL 6.04 just now.

Sorry..

LOL