Seti@Home optimized science apps and information
Optimized Seti@Home apps => Windows => GPU crunching => Topic started by: KarVi on 04 Apr 2012, 03:00:17 pm
-
Has anybody done some testing into what "-unroll -ffa_block -ffa_block_fetch -sbs" settings works most efficiently for a Radeon 5770?
Defaults seems to be "-unroll 4 -ffa_block 2048 -ffa_block_fetch 1024 -sbs 128", when you use the installer, but must also be based upon less powerfull cards and their abilitys.
-
-unroll 10 -ffa_block 6144 -ffa_block_fetch 1536 should work fine.
Sbs switch not needed atm.
-
Thanks.
Also got basically the same settings fra Claggy, but had problem getting it to run.
Just got short bursts of 30% usage on GPU, and slow progress in crunching.
But one more restart of boinc seems to have cured it, now crunching with 75-99% GPU usage, and it seems to be faster than with standard settings.
I hope it lasts, time will tell :)
-
Thanks.
Also got basically the same settings fra Claggy, but had problem getting it to run.
Just got short bursts of 30% usage on GPU, and slow progress in crunching.
But one more restart of boinc seems to have cured it, now crunching with 75-99% GPU usage, and it seems to be faster than with standard settings.
I hope it lasts, time will tell :)
That will be the GPU usage Bug a fair amount of us are suffering from, suspending GPU usage, waiting for the app to exit (watch task manager), then resuming often gets high GPU usage again,
Claggy
-
Donīt forget GPU usage also differs on high blanking.
-
Yes, if GPU processing few heavely blanked tasks there can be GPU usage drop even with few tasks per card.
But I think there is the way to distinguish such pattern from GPU low usage bug pattern.
Heavely blanked pattern should have almost 100% spikes when FFA done on GPU (it's best optimized partion IMHO cause I worked on it from Brook+ times). Blanking affects on processing between FFAs and FFA itself should make use of almost all GPU.
Whereas low usage bug pattern will shouw steady low % perhaps.
Not sure in that but you can make observations and improve my suggestion.
-
Did that already.
On AP using r558 GPU usage bouncing between 20% and 45% running 2 instances.
On high blanking its bouncing as well so you only can try with suspend and resume.
My times varies between 3000 secs and 10000 secs with blanking less than 15%.
Additional note:
While on MBs suspending work cures at least for whole unit in progress, on APs low GPU load returns after a few minutes sometimes.
I imagine it depends on steadily CPU usage ?
-
WoW, good observation!
No, I think not.
There is key difference in buffer allocations for MB and AP.
While MB does more or less homogenic calculations AP implements 2 almost independent sections - main loop and FFA.
For FFA we need different buffers (different number, different sizes) than for main loop single pulse search.
Hence there is only once buffers allocation in MB, at the beginning, but constant buffers recreation/discarding for AP.
Before there was opinion that low GPU usage bug can be connected with orphaned OpenCL resources left behind when task finished. Indeed, I did not directly deallocate buffers in MB leaving cleanup for OS/OpenCL runtime (as should be when OS process get killed).
But I do buffers deallocation in AstroPulse ! When transition from main loop to FFA occurs some of main loop buffers are deallocated and FFA ones are allocated, and vice versa. So, the problem not in deallocation, the problem in allocation!
No clue how to fix it on our end still, but at least it's good bug report to AMD.
-
This is the sort of load i get with ATI AP when there is minimal load:
(http://gpuz.techpowerup.com/12/04/05/abb.png)
and this is what it like once i've suspended and resumed the Wu (notice the higher frequency of memory usage):
(http://gpuz.techpowerup.com/12/04/05/4p7.png)
Claggy
-
That is exactly what it looks like on mine as well.
I must note that I hadn't noticed the error before optimizing the settings.
I'm thinking about going back to see if it disappears with the standard settings...
-
This is the sort of load i get with ATI AP when there is minimal load:
Claggy
How many tasks per GPU in fly on that picures ?
-
This is the sort of load i get with ATI AP when there is minimal load:
Claggy
How many tasks per GPU in fly on that picures ?
I only ever run 1 task per GPU, it enables me to see what the app is doing, rather than having multiple apps masking the problem,
Claggy
-
Yes, your approach is right for app testing. Host performance suffer in such mode though.
But then your picture "kills" my method of bug/blanking discrimination.
There are spikes of bigger load (I think it's FFA) on you "low GPU bug" picture... And those spikes much less visible (though exist) in "full load" mode.
-
BTW, look for memory graph.
There are "spikes" - they corresponds short FFA (most of them).
Look how often they occur on "fast"task and how wider (X-axis is time so wider =slower) they are on "slow" task.
But amount of computation between them is just the same!
Hence we have slowdown not just in some area of algorithm. Whole processing more or less equally slowed. single pulse search takes more and FFa takes more too.
It's important result cause it can decline assumption that there are just many false positives from near to threshold reesults in FFA so much more bus transfers are needed. In that case FFA would took much longer while single pulse (main loop) - not. So we would see disproportional increase in max or min memory usage time.
-
Another thing to note, when ATI AP app is suffering from low usage Bug, ATI driver restarts have occured on number of occasions,
normaly this occurs when i have been away from the computer, and i start browsing, driver restart occurs, i check SIV/GPU-Z and find there has been little ATI GPU usage,
and lots of elapsed time, and little % progress, suspending & resuming gets the app working with 80%+ GPU load,
on a couple of occasions i've come back from work and found the app a couple of hours in but with 0% done, i suspect a driver restart happened there too,
suspending/resuming has got it working.
Claggy
-
After driver restart app can't continue. It will either take 100% CPU core or just hang.
And driver restart itself just consequence of low GPU usage => too long kernel execution => Windows thinks driver hang => windows restarts driver.
You can try to get rid from these driver restarts by disableng watchdog in windows registry.
-
After driver restart app can't continue. It will either take 100% CPU core or just hang.
And driver restart itself just consequence of low GPU usage => too long kernel execution => Windows thinks driver hang => windows restarts driver.
You can try to get rid from these driver restarts by disableng watchdog in windows registry.
I never get a driver restart ?
Mostly it cures itself on the next task.
-
yes, next task will be OK cause it creates new OpenCL context.
But after driver restart current app instances become invalid cause their OpenCL contaxts become invalid.
-
This low GPU usage bug is driving me nuts :(
Right now I cant get my GPU to crunch anything AP at full speed.
The last many WU's have been the 30% for a few seconds, then 0% for 10 seconds patterne. WU's take forever.
Making it crunch 2 or 3 at a time gives same the results.
Any number of starts and stops of the boinc client, doesn't help.
The funny thing is I didn't have this bug before i began to tamper with the settings, to make it go faster.
Are there any tricks to make it work better? Never Boinc, other drivers (I'm on 12.3), or anything. This is more than mildly frustrating...
-
A reboot of the system cured it, but well see how long it lasts.
I am running a absolute stock settings from Lunatics installer, to see if it lasts.
-
A reboot of the system cured it, but well see how long it lasts.
I am running a absolute stock settings from Lunatics installer, to see if it lasts.
I'm not sure that any app settings connected with this issue anyhow.
-
I'm not either.
But as I hadn't encountered the issue before starting to tamper with settings, I thought it worthwhile to at least try to run with original settings again.
Its still working, but I need a little more than 1 and ― WU to see if its cured, or at least reduced.
-
If suspend and resume dont work you need to restart.