Re: pfFrame questions

New Message Reply Date view Thread view Subject view Author view

Jim Helman (jimh++at++surreal)
Fri, 01 Jul 94 15:46:05 -0700

> If I understand forked intersections, it appears to
> me that the argument to pfIsectFunc is initiated at each
> pfFrame and then runs asynchronously with the rest of the
> rendering pipeline. What happens if the intersection
> processing at frame "n" continues beyond the call to
> pfFrame in frame "n+1"? Are the intersections at frame
> "n" discarded?
   
pfIsectFunc is initiated at each pfFrame, but only if the
previous invocation of the isect func has completed. Hence,
if intersections for frame "n" extend into frame "n+1", then
pfIsectFunc won't be called again until frame "n+2" at the
earliest.

> Is it possible for an application-sproc'd process to
> call pfSync/pfFrame in stead of the application making
> the calls? If the sproc'd process can call pfFrame, is
> the performer in-memory database locked during the
> pfFrame operation?

A sproc'd APP thread should not modifiy libpf objects while
the other thread is doing so or while the other thread is in
pfFrame or pfSync. Basically, sprocing only buys you is the
ability to create libpr objects or do other non-performer
processing in the sproc'd thread. We're looking at better
ways to allow simultaneous access to the APP's scene graph
for things like database paging.

> If so, what is the latency associated
> with pfFrame including the locked operation?
   
pfFrame returns fairly quickly in MP mode if pfSync has already
been called, otherwise it sleeps until the next frame boundary.
pfSync on the other hand not only cleans the libpf scene graph,
but always waits until the next frame boundary. So, one or the
other is going to sleep for a while.

rgds,

-jim helman

jimh++at++surreal.asd.sgi.com
415/390-1151

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:50:23 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.