Re: Multiprocessing.

New Message Reply Date view Thread view Subject view Author view

Jim Helman (jimh++at++surreal)
Fri, 16 Dec 94 12:12:15 -0800

Performer handles data synchronization using multiple copies
for libpf objects for APP, CULL and ISECT. With forked DRAW,
the DRAW uses a pfDispList which includes things like matrices
passed by value. This allows processes to have access to the
data almost all the time, as well as providing frame-accurate
data propagation. The alternative is single copy with locks,
but this has performance implications because of possible
contention for the lock.

By contrast, libpr objects like geosets and geostates are not
multibuffered. Performer 2.0 will have better support for
multibuffering vertex and other geoset attribute arrays for
handling dynamic geometry more conveniently. Currently, for
safety, dynamic geometry must either be handled in the DRAW
process or multibuffered by the application itself, e.g. with a
pfSwitch node.

sproc with only one thread rendering should work reliably.
Multiple rendering threads requires locking and synchronization
(e.g. gflush). It's conceivable that bad data could cause a
pipe crash, but unlikely that valid floating point numbers such
as those in a matrix would be a problem. There used to be a
problem sending NaN's as normals, but it was fixed.

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:44 PDT

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