Tom, I don't think that ATI program will work on your system. Your computer is running an integrated Intel, not an AMD ATI Graphic. Just thought I should mention it before you tried running that program on your computer.

There are a number of roadblocks, but none insurmountable. Most of those actually revolve first around boincapi and client limitations, then the four known credit System design flaws currently under detailed analysis.

The only barriers that really revolve around OpenCL per se, are slightly different implementations by hardware vendor, which Raistmer has already shown are manageable separately, so can be managed with unified conditional code down the line.

Also The Cuda builds cope with 6 quite different GPU architectures, though there are OS induced latency issues to be solved there, by refocussing on new ways to determine optimal code paths. The literature suggests a combination of traditional ( multibeam + fttw ) wisdom-like runtime optimisation, plus some amount of hardware awareness and narrowed search space by offline (install-time) optimisation (like mobile devices do), and hard dispatch, would yield the best usability results, though require some thought toward different user goals (like efficiency versus throughput versus display responsiveness or application sharing)"It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change."
Charles Darwin

The really short summary is, it sucks and nobody else uses it. Which is why most other projects give more credit than SETI@home, (although some projects are incredibly ridiculous about the credits they give). @SETIEric

...then the four known credit System design flaws currently under detailed analysis.

Jason, can you elaborate on this part of your response?

Sure, I'll summarise here. I did post more details in NC a while back, but these tend to get buried in mayhem. The Collatz April Fools joke post makes a nice summary too ;)

#1) Coarse scaling error: The FLOPs estimates from returned tasks at validation time, which get converted to the cobblestone scale to aquire a raw credit claim, are based on Boinc Whetstone [and elapsed time]... which for CPU implies that FPU, SSE-SSE3, and AVX are all the same. As the detected 'most efficient' application (stock CPU for multibeam), scales down every other application, then there is an effective underclaim of between 2.85 and 8x (probably around 3.3, subject to isolating the actual SIMD performance of modern processors & applications. That's important because creditnew is ignoring what's known as 'Instruction Level Parallelism'

#2) Stability: In Engineering senses, Credit awards show all the instabilities (ringing, overshoot, and skew) associated with an uncalibrated control system. Mathematically the system is a Sigma type feedback with some weighting, which is the same algorithm as a cheap DAC in a $5 disposable CD player. I'd like to see a properly stabilised PID controller implementation, one time tuned, with proper damping... for each of the two scales (host scale and gloabal app version scale). The current implementation appears to meet the requirements for Chaos, which are 'sensitivity to initial conditions', and some 'stirring' by the way validation times mix up estimates/avergaes, and self similar looking oscilaltions. (different to 'random')

#3) No Multithreading support: Milkyway users complained when MT plan class applications divided credits. Obviously Elapsed time 'per resource' should be being summed, making it greater than wall-time. It's used directly

#4) Overly sensitive to Task estimates: This really, in control theory, is a side effect of the earlier items. The task estimates only need to be a theoretical minimum (usually established from numerical computing theory). The problem here is that system is then receiving shorter elapsed times then expected (i.e. impossible), then downscaling estimates for everyone (feedback), and so attempting to convince us that magic is real, as opposed to some of the systems assumptions being faulty [such as the faulty assumption that stock CPU applications have no parallelism].

The old system used a credit multiplier of 2.85, which was removed/disabled. That would have been about right for SSE-SSE3 type SIMD implementation.. since AVX for multibeam we need a larger figure I believe around 3.3, but it'll be nicer to maintain the working - self scaling, self correcting - aspects of creditNew, but fix those assumptions, and damp the oscillations. Doing those things and embedding a little foresight toward upcoming technology change, will probably be a wise investment now, more useful long term than just piling on more bandaids and workarounds."It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change."
Charles Darwin

I'll laugh at the Collatz joke when they start counting operations and using that to grant credit.

I suppose us [temporarily] switching back to flopcounts with a SIMD compensating credit multiplier is out, given the logistics..."It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change."
Charles Darwin

Sorry but i can´t understand why you simply can´t add a simple multiplier to the actual credit paid. Something like (not the actual values just a guess)

MB Credit = MB Credit * 3.3

After all the creditscrew calculations where made, Nothing else. NO chanches in the Creditscrew code itself (that´s for another time).

If IIRC 3.3 was the number finded by Jasons as the discrepance on the values (i could be wrong)

Something similar could be made on the AP section.

Basically the system is a lot like one of those mechanical governers on a steam engine (but with the wrong kindof ball weight, and some bent pushrods at the moment... hooked to another for each passenger...).

You can wedge a brick in it to keep the throttle open, but then the boiler explodes and everyone dies, or the thing runs out of control derails & runs through downtown San-Francisco :)
[ Then also, piling on bandaids is probably what created the bent pushrods in the first place ]

The way to fix it would be to unbolt the device, make all the adjustments and test, then reinstall and finetune. The difference here is that we have to do it while the vehicle's in motion and fully loaded with passengers. Since Albert's willing to let us use their beta to test & tune some things (in time), we're hopeful for an Apollo 13 style rescue, over a Coors-Light party train disaster."It is not the strongest of the species that survives, nor the most intelligent that survives. It is the one that is the most adaptable to change."
Charles Darwin