I just found that if I go to Windows Task Manager and bump the priority of the GPU app to "realtime", it runs quite a bit more speedily on my 8800GT's (especially when I'm also heavily tasking the CPU like during x264 encoding), without obvious detriment to anything else.

This makes me wonder: is there a way to get the BOINC client to start WU's in "realtime" priority automatically, instead of having to do it manually all the time?

Do not try under Vista (64) with GTX260 - bluescreens result

6.1.14 is prepared to increase priority for gpu app (without going realtime).

gdf

6.1.14 is prepared to increase priority for gpu app (without going realtime).

gdf

I'm running 6.3.14, does it mean that there's a mechanism for the BOINC client to change the priority that GPU apps start in?

That said, I found priorities from low through high to behave the same way, or at least very similarly: I cannot discern a difference with my setup until I get to realtime.

There is no way for users to change this.

There is no way for users to change this.

Ah... Well, I wish there was flag in one of the config files that I could change to accommodate the realtime priority. It's good to know that the BOINC client knows to adjust the windows priority for tasks using <1 CPU; too bad I don't see a benefit with running GPUGRID at normal priority compared with low though.

I'm not sure how to explain it technically. Heres my non technical thinking on it. If the CPU/CUDA app makes a request CPU to CUDA and is at running Normal Priority, that request in the system has priority over the apps running at low priority, it goes to the front of the line. If all the apps are running at low, then it just goes in line, so a few other app instructions maybe ahead of it, making it miss a beat. This causes a slow down in the CPU to CUDA overall performance. There should be smoother performance when the CPU/CUDA app is running at normal. That's not the exact way it happens but sort of draws the picture. Do you see it now ?
If not, wait until the project makes the change, then you can see for yourself.

I'm not sure how to explain it technically. Heres my non technical thinking on it. If the CPU/CUDA app makes a request CPU to CUDA and is at running Normal Priority, that request in the system has priority over the apps running at low priority, it goes to the front of the line. If all the apps are running at low, then it just goes in line, so a few other app instructions maybe ahead of it, making it miss a beat. This causes a slow down in the CPU to CUDA overall performance. There should be smoother performance when the CPU/CUDA app is running at normal. That's not the exact way it happens but sort of draws the picture. Do you see it now ?
If not, wait until the project makes the change, then you can see for yourself.

I understand that's how "normal" versus "low" is supposed to make a difference, but I cannot observe that difference with my computers. I have to raise the priority all the way to "realtime" in order to realize a performance gain.

In the meantime therefore, I'm using a brute force approach to automating the setting of CUDA tasks to "realtime" priority by running a script at regular intervals via Scheduled Tasks. Quite inelegant, but it serves the purpose.