Sharon Clay (src++at++rose.engr.sgi.com)
Wed, 29 Oct 1997 19:01:46 -0800
Well, this isn't so clear and shouldn't cause a deadlock.
This only matters if you are running 2 or more of
separate APP, CULL and DRAW processes on the SAME CPU - as you might be with
a single or dual CPU machine. APP_CULLDRAW would improve your
latency. APPCULL_DRAW might get better frame-rate because you can sort.
Depending on how you structure your program, I can imagine reasons for
APP being higher and Draw being higher. I agree that the default though
should probably generally be Draw as highest priority, then Cull, then APP.
This is becuase CULL and DRAW do not run anyway if there is no work to do so
if there is work for them to do, then they should get to do it. At
one time we did have it this way in fact.
We have a much new and improved process menager in
Performer2.2 that does exacty that and the new posix scheduling API that
provides a lot more control.
->By giving the pf draw process a slightly
->higher priority than the other pf processes, you get rid of the deadlock. The
->app process is probably waiting for swap buffer but is never giving the chance
->to the draw process to do it, I assume. Perhaps by setting scheduling to round
->robin with equal priority to all processes would do it two, but I haven't tried
->it.
There won't be a deadlock on swapbuffers - the draw gives up the CPU to all
equal or higher prority processes
when swapbuffers is called and APP will get to run. App goes to
sleep in pfSync() to the next vertical retrace and will let draw run.
Also, App and draw are
woken by the kernel on vertical retrace interupt and do not use a semaphore
to syncrhonize to the graphics pipeline.
A semaphore is used if you are of pfPhase FREE_RUN however.
But, in general if a lower priority process holds a lock
that a higher priority process wants, the OS will auto-raise
the priority of the lower priority process so that it gets to run.
I can believe that on old (6.2) IRIX this might have been buggy but
in 6.4 it _should_ work. We run perfly this way no trouble
on 6.4 (Patches: 1794, 1815) on Octane and I've not seen it deadlock so
I am still suprised. Can you reproduce this with perfly? (I apologize
in advance for entering this discussion late if this is Q redundant with
previous info).
src.
--
-----{-----{---++at++ -----{----{---++at++ -----{----{---++at++ -----{----{---++at++
Sharon Rose Clay (Fischler) - Silicon Graphics, Advanced Systems Dev.
src++at++sgi.com (650) 933 - 1002 FAX: (650) 965 - 2658 MS 8U-590
-----{-----{---++at++ -----{----{---++at++ -----{----{---++at++ -----{----{---++at++
===================================List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:56:08 PDT