I was having a nosey at the Boinc Trac and spotted that they had just changed version to 6.6.24 (looks like it will be compiled in unicode and is GPL3).

I thought these fixes may be of interest to those that are getting errors and I've edited for GPU "highlights":

17869 and 17856: client: fix crash bug in CUDA init

17868 and 17855: * client: new approach to handling multiple GPUs.

old: find fastest GPU, and pretend that others are the same.

Problem: other GPUs might be less capable,
and not able to handle jobs sent by server.

new: find the most "capable" GPU, use others that are equivalent,

don't use those that are not.
"Capable" is defined by

* compute capability (i.e., hardware version)
* driver version
* memory size
* FLOPs
in that priority order.

17865 and 17847: * client: improve CPU sched debug messages

(say what kind of job and why we're scheduling it)

* client: log messages describing GPUs: one line per GPU; fixes #879

Rob

FOr those with more than one GPU it seems to disqualify the second GPU ... not sure why yet ...

6.6.24 *MAY* also fix some of the "thrashing" of tasks where tasks are preempted far more often than they should be ... I cannot tell of course yet as I am not going to give up one GPU just for amusement sake...

{edit}

New message looks like:
4/23/2009 9:00:17 PM CUDA device: GeForce GTX 295 (driver version 18250, compute capability 1.3, 896MB, est. 106GFLOPS)

I have a GTX280 and a 8800GT in one system and can confirm this behavior. The 8800GT will not work under BOINC 6.6.24, so I had to downgrade to 6.6.23 to crunch with both cards at the same time for BOINC.
____________

I have a GTX280 and a 8800GT in one system and can confirm this behavior. The 8800GT will not work under BOINC 6.6.24, so I had to downgrade to 6.6.23 to crunch with both cards at the same time for BOINC.

After 6.6.24 was installed GPUGRID WUs got the state "waiting to run" on both GPUs of the GTX 295 although GPUGRID is the only GPU project running!
So I rolled back to 6.6.20 immediately.
____________

new: find the most "capable" GPU, use others that are equivalent,

don't use those that are not.
"Capable" is defined by

Jeeez.. what are they thinking?! Didn't anyone tell them how popular it is to mix GPUs, for the single purpose of using all of them?

Why is it so difficult to

- make a smart decision on which coprocessors to use (e.g. default: all, but not when PC is in use)
- let the user specify in the options if he want's coprocessors to be excluded (display a list which ones are detected)

Sure, that's not the entire deal yet as there are many problems left. But still.. it seems so much better than what they suggest and it doesn't seem much more complicated.

Sure, they hate giving options to the user (to avoid micromanagement) and would rather have BOINC take care of everything automatically. But at some point they also have to admit that right now they can not even get the basics of co-processor handling straight. How are they ever planning on handling a system, where an ATI is meant to crunch only Milkyway, a CUDA 1.3 is meant to run GPU-Grid and SETI, a CUDA 1.0 is meant to only run SETI and a Larrabee does Einstein? An extreme example, but right now this would be totally hopeless.
[not that I'm saying Einstein would be developing a Larrabee client, I just wanted to give an example]

Okay after updating to 6.6.24 BAD things happen.

On my solo GTX-260 machine I can no longer run ABC, Rosetta and GPUGrid.

GPUGrid is showing 0.43 CPU, 1 CUDA. At this the CPU tasks run but no GPU. If I suspend ABC and Rosetta, GPUGrid runs fine (if a little slow I'm thinking I need to time it). If I turn ABC on which has only 1 WU downloaded then both GPUGrid and ABC run. If I suspend ABC and resume Rosetta which has 10+WU's, 4 CPU schedule on the Q6600 plus GPUGrid, then all WU run with GPUGrid running for about 5 or 6 updates (tick type updates) then GPUGrid just stops. It says it's still running but after 15 mins it's stuck at the same % complete.

IS this the BOINC scheduler that's being a PITA?
____________

Okay after updating to 6.6.24 BAD things happen.

On my solo GTX-260 machine I can no longer run ABC, Rosetta and GPUGrid.

GPUGrid is showing 0.43 CPU, 1 CUDA. At this the CPU tasks run but no GPU. If I suspend ABC and Rosetta, GPUGrid runs fine (if a little slow I'm thinking I need to time it). If I turn ABC on which has only 1 WU downloaded then both GPUGrid and ABC run. If I suspend ABC and resume Rosetta which has 10+WU's, 4 CPU schedule on the Q6600 plus GPUGrid, then all WU run with GPUGrid running for about 5 or 6 updates (tick type updates) then GPUGrid just stops. It says it's still running but after 15 mins it's stuck at the same % complete.

IS this the BOINC scheduler that's being a PITA?

6.6.x something broke the scheduler and work fetch. I don't know where exactly ... but I have seen reports from 6.6.20 on ... 6.6.20 also has the added fun of sometimes running GPU tasks VERY slowly ... 6.6.23 and on fixed this and made work fetch worse.

The only cure for work fetch is to go back to 6.5.0 or to get used to resetting debts as needed. On my i7 that is about once every day or so.

Sadly, "they" (yes the omnipresent "They") are wearing me down because they say they want to fix things as long as they don't have to change any of the causes of the problems ...

I would suggest that you use your influence with the project to have the project lead drop a line to Dr. Anderson ... he is far more responsive to missives from project leads than from peons like me ...

Didn't have time for that yet. Considering the changes in 6.6.25, would it still be desirable to take any action? Did Berkeley already get the message that their new policy is.. not the best idea in the world?