interesting observation running GPUGRID

[bmwr606]

i am going for my 10MM in GPUGRID

normally, the GPU usage is at 88-89% (as per MSI Afterburner)

just for grins, i set the priority of the GPUGRID .exe to "realtime" via taskmanager

the GPU usage jumped to 94-95% with some spikes to 100%

is this an indication of being I/O bound or CPU bound?

any thoughts?

i will try the same thing 12/1 when i switch the GPU to DirT for the BIG PUSH week

[Fire$torm]

i am going for my 10MM in GPUGRID

normally, the GPU usage is at 88-89% (as per MSI Afterburner)

just for grins, i set the priority of the GPUGRID .exe to "realtime" via taskmanager

the GPU usage jumped to 94-95% with some spikes to 100%

is this an indication of being I/O bound or CPU bound?

any thoughts?

i will try the same thing 12/1 when i switch the GPU to DirT for the BIG PUSH week

It just means that in its default priority state Windows was giving higher priority to other threads. You told Windows to treat it as an equal.

[DrPop]

Hmmm...F$, do you think I should go do that to GPU projects like Moo!, PG or DiRT? Would it make a difference?

[Fire$torm]

Hmmm...F$, do you think I should go do that to GPU projects like Moo!, PG or DiRT? Would it make a difference?

I don't really know. Though that little voice in my head says to be careful if you do. Change too many and it may cause problems with Windows system apps running in the background.

Edit: As an alternative you could use the utility that Bryan & Maxwell recommend called lasso IIRC. It does the same thing but is less likely to FUBAR Windows.

[Bryan]

You possibly aren't seeing what you think. They are mixing in some wu called "Nathan" that produce GPU loads of 96%. The next time you see loads that high check to see if there is a Nathan wu crunching.

[Slicker]

On some projects, if you have a fast GPU, it pays to set aside an entire core just for GPU computing. For example, on DiRT I gain more credits by running only one less WU on the CPU than I have cores so that the GPU can run at full speed than I get if I a WU per core as well as a GPU WU.

If the project sets the GPU app to run at normal priority, then it will take precedence over the CPU apps which run at low priority. If the project doesn't set the GPU app to run at normal priority, it will run at low priorty (the boinc default) and have to fight with the CPU WUs for access. In other words, change the ncpus setting in the cc_config to 1 less than the number of cores/hyperthreads. For example, on an i7, add <ncpus>8</ncpus> so that one hyperthread will not be used. Or set the computing percent to 87.5 (0.875 = 7/8)

Just don't forget to change it back when switching to a project that doesn't need it or you will be wasting a core/hyperthread for nothing.

[bmwr606]

slicker....

i think in my case that would be major overkill.... i have a dual core E6750 (oc @ 2.8ghz) and a gtx260-216 (oc - core @ 651mhz, shader @ 1429mhz and mem @ 999mhz)

when i bump the gpugrid .exe priority from "low" to "realtime" the gpu usage goes up ~5% at the cost of the gpugrid .exe taking ~3% of one cpu

note that setting the gpugrid .exe to "high" does not result in any gain, i seem to remember reading that "realtime" locks an app in ram, not allowing paging?

btw, this "trick" does not seem to work at all on Dirt

scott