From: Yair Kurzion (yair++at++polygon.engr.sgi.com)
Date: 01/02/2001 10:48:42
Hello Kenneth !
This is a common problem when multiple processes (in your case - ISECT, COMPUTE
and DBASE) share a CPU. It is even a bigger problem when these processes run in
different priorities.
Performer 2.4 has some new API to overcome this problem. This new API changes
the priority of processes when they grab scene graph changes and other updates
from APP (and APP has to wait for them). Take a look at the man page for
pfProcessPriorityUpgrade and pfProcessHighestPriority.
This API is not available in Performer 2.2.8. If you don't wish to upgrade,
you may find a partial solution by doing any of the following:
o Setting the priority of ISECT higher than COMPUTE and DBASE. ISECT usually
requires more time to grab its updates because it has its own copy of the
scene graph.
o Changing the priority of ISECT, COMPUTE and DBASE during their frame of
execution: Lower their priority at the beginning of each frame, and raise it
back at the end of the frame. Make sure the highest in-frame priority of the
three is lower than all end-of-frame priorities. APP waits on these processes
following the end of their frame. So, APP communication always happens at a
higher priority.
-yair
>
> I have 4 CPUs on an onyx 2. App, cull and draw is locked down and isolated
> on a CPU each. Isect, compute and dbase is forked and running on the other
> CPU. I noticed from the timing graph that app for frame n + 1 will not
> start until isect, compute and dbase for frame n has started. I am not
> passing any data via pfPass<*>Data(). I understand that isect and cull
> copies the scene graph and other data from the app process.
>
> Do you expect app for frame n + 1 to wait until after compute and dbase for
> frame n is started?
>
> To avoid the app process waiting for an excessive period, my strategy is to
> block the asynchronous processes as soon as it is started. Once the first
> asynchronous process is blocked, the second asynchronous process will start
> and so on. After all the asynchronous processes have started, pfFrame will
> return in the app process and the asynchronous process will be "signalled"
> to resume.
>
> Is there a better strategy to overcome the problem?
>
> I am currently sending CONT (from app to isect, compute and dbase) and STOP
> (from isect, compute and dbase to itself) signals which yields a
> satisfactory result. I have tried calling sginap(0) in the asynchronous
> processes but other asynchronous processes doesn't start immediately some
> of the time.
>
> Is there a more suitable inter-process synchronisation mechanism than using
> signals?
>
> Platform Details:
>
> IRIX 6.5.8
> Onyx 2 4 R10k CPUs
> Performer 2.2.8
> MipsPro 7.2.1
>
> Cheers...
>
> Kenneth Chan
> __________________________________________________
>
> CSC
> 460 Pacific Hwy St Leonards NSW 2065
> Ph: +61 2 9901 1165 Mobile: 0413 04 34 74 (+61 413 043474) Fax: +61 2
> 9901 1110
> Email: kchan2++at++csc.com.au
>
> -----------------------------------------------------------------------
> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> Open Development Project: http://oss.sgi.com/projects/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
>
--
\_________ \_____ \__ \__ \_____ Yair Kurzion
\_________ \_____ \__ \__ \_____ yair++at++sgi.com
\__ \__ \____\__ \__ http://reality.sgi.com/yair
\__ \__ \__ Work: (650) 933-6502
\__ \__ \__ Home: (408) 226-9771
\__ \__ \__
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 10:48:50 PST