Directed GPU Use Option????

[Tex1954]

Howdy, first time here and I love this interface!! Much better than the standard IMHO.   

I have one problem lately with BOINC in general that "MAYBE" ya'll can help me with. When I was first running PrimeGrig on my GPU's I had no problems; but lately their latest (cuda_fermi) tasks use 99.99% of my display system, even with no CPU tasks running!!! This slows down the display update to a click-and-wait crawl. There is no problem with it running on only one GPU, only when it's running on both at the same time.

My system specs: http://valid.canardpc.com/show_oc.php?id=1748349   and normally runs 4.2GHz 24/7....

So, I was wondering...

In the case of multiple GPU systems, can we force a project to use only one GPU at a time to allow other projects to use the other GPU and not slow screaming fast display systems to a crawl?

OR, is there a way to contact PrimeGrid (other than the forum) and ask them to back-off a little on hogging the display resources?

OR, is there some other work-around to this other than manually suspending a task all the time?

OR, am I completely missing something somewhere and someone could help in tuning or something?

Thanks for any and all help!

[Pepo]

My system specs: http://valid.canardpc.com/show_oc.php?id=1748349   and normally runs 4.2GHz 24/7....

Indeed a nice specs

When I was first running PrimeGrig on my GPU's I had no problems; but lately their latest (cuda_fermi) tasks use 99.99% of my display system, even with no CPU tasks running!!! This slows down the display update to a click-and-wait crawl. There is no problem with it running on only one GPU, only when it's running on both at the same time.

So, I was wondering...

In the case of multiple GPU systems, can we force a project to use only one GPU at a time to allow other projects to use the other GPU and not slow screaming fast display systems to a crawl?

OR, is there a way to contact PrimeGrid (other than the forum) and ask them to back-off a little on hogging the display resources?

OR, is there some other work-around to this other than manually suspending a task all the time?

Well, the PrimeGrid team has apparently really succeeded to squeeze the last drops of GPUs when running their apps, thumbs up! I'm sharing your pain, although with just a single onboard mobile GPU, because the responsiveness is indeed biased towards crawl... If a PrimeGrid is on the row, then I have to snooooze... to be able to work with the machine.

AFAIK there is currently no setting for the client, that would cause a particular task being run at a particular GPU. One option would be to enable/disable one of the GPUs on the fly. Maybe you could ask on some of the GPU projects' (GPUGRID, PrimeGrid, maybe SETI or BOINC/dev GPUs section) forums, whether an app_info.xml could direct an app to some particular GPU? According to this thread pointing to recent changeset [23253], the BOINC setup should be possible "soon" (understand it as a couple of months).

I'd like to set a list of projects (or applications), which would be denied computing when the user is active (or, better, a list of apps, which are allowed to use the GPU, while the user is active and GPU is not snoozed). If I'd just suspend the demanding tasks, the client might immediately download some replacement 

[Tex1954]

Well, thanks for the hints! I'll try to pass on the information. I see no reason why I can't process CUDA while doing normal task... however, I am now seeing a couple of compute errors for PrimeGrid... no doubt that is me doing something.

Waiting is no problem, but I think they need to tune their apps a bit less tightly... who cares if it takes 1 minute longer if it avoids errors! That is better than not running it at al.

8-)

Thanks again! On to a PrimeGrid forum I guess and hope someone sees!

[Pepo]

I've read your thread on PrimeGrid, nothing positive came out so far... 

Could also this BOINC/dev thread be somehow related to your issue?

[Beyond]

I'm seeing no appreciable lag on any of my 5 PrimeGrid crunchers at 99% GPU, but if you have the problem why not lower the task priority with eFMer Priority?

[fred]

You can also set a minimum GPU throttle in the tthrotle.exe file (examples).

<GPU_SETUP>
  <gpu_percentage_min> 2 </gpu_percentage_min>      
  <gpu_percentage_max> 98 </gpu_percentage_max>
</GPU_SETUP>

Move the tthrottle.xml file to the folder with the exe = one down.

[Pepo]

I'm seeing no appreciable lag on any of my 5 PrimeGrid crunchers at 99% GPU, but if you have the problem why not lower the task priority with eFMer Priority?

Most probably because at the time of its spin-off, I've not had any usable GPU, and probably forgot later (or never recognized) what is it good for 

You can also set a minimum GPU throttle in the tthrotle.exe file (examples).
Move the tthrottle.xml file to the folder with the exe = one down.

I'll try to play with <gpu_percentage_max>.

[Pepo]

You can also set a minimum GPU throttle in the tthrotle.exe file (examples).
Move the tthrottle.xml file to the folder with the exe = one down.

I'll try to play with <gpu_percentage_max>.

(Surrounding global <TThrottle></TThrottle> seems to be just optional?)

The <gpu_percentage_max> is apparently not incentive enough for "PrimeGrid PPS (Sieve) (cuda23)" app the primegrid_tpsieve_1.38_windows_intelx86__cuda23.exe process seems to require as less CPU time (in average 0.06%-0.08% of a core, around 0.3% of a 4-core system) to feed the GPU with necessary data and code, that it is not very good possible to throttle it by conventional means. When I set the max even down to 4%, the GPU (monitored with Orbmu2k's GPU Observer sidebar gadget) still seems to be constantly loaded to 99%, with occasional blips to 78% or 60% or even less frequently 25% or 0%.

I'm seeing no appreciable lag on any of my 5 PrimeGrid crunchers at 99% GPU, but if you have the problem why not lower the task priority with eFMer Priority?

Most probably because at the time of its spin-off, I've not had any usable GPU, and probably forgot later (or never recognized) what is it good for

I took a look at eFMer Priority too - am I right that it just lowers/rises the process' priorities? Because lowering the PrimeGrid process' priority to idle had no impact at the GPU usage at all - probably still the same reason - nearly no CPU requirements of the task.

BTW,

...the primegrid_tpsieve_1.38_windows_intelx86__cuda23.exe process seems to require as less CPU time (in average 0.06%-0.08% of a core, around 0.23-0.33% of a 4-core system)...

Why does, at the same time, BT display around 1.7%-2.0% in the task's "CPU %" (short-term) column?? (I've seen it deepest to 0.7%, while the real process usage was at 0.21%/4c.)
I take it back. I assume it's because the newest Process Explorer tries to use cycle-based CPU usage on Win7, which can slightly differ from the conventionally calculated process CPU usage (especially on not-CPU-bound processes). I'm just lazy to try out the older version.

[Beyond]

I'm seeing no appreciable lag on any of my 5 PrimeGrid crunchers at 99% GPU, but if you have the problem why not lower the task priority with eFMer Priority?

Most probably because at the time of its spin-off, I've not had any usable GPU, and probably forgot later (or never recognized) what is it good for

I took a look at eFMer Priority too - am I right that it just lowers/rises the process' priorities? Because lowering the PrimeGrid process' priority to idle had no impact at the GPU usage at all - probably still the same reason - nearly no CPU requirements of the task.

Yes, just changes/monitors the priorities.  You could always set BOINC Manager to only use the GPU after the computer has been idle for 1 minute.  Not the most elegant solution perhaps...

[Pepo]

You could always set BOINC Manager to only use the GPU after the computer has been idle for 1 minute.  Not the most elegant solution perhaps...

I could, but I'd rather like to tell the client to snooze GPU just if some particular task would like to run. Better, some "selective snooze mode" - to not run GPU tasks from my "list of bad guys", until my machine gets again idle.