From: Yair Kurzion (yair++at++polygon.engr.sgi.com)
Date: 04/26/2000 13:38:15
Hello Chris !
> I have a question regarding who does the work with a pfFlux.
>
> In a pfBuffer, a process can schedule requested additions or deletions to a
> pfNode by doing bufferAddChild or bufferRemoveChild. This acts as a request
> only and doesn't get run until pfFrame (or pfSyncFrame) or something like
> that in the app. It is actually the app that "does the work" of removing and
> deleting all the children.
>
> How does this work with a pfFlux? Although you don't need to do buffer
> scheduling, and manipulate the data directly, there are calls like
> writeComplete and getCurData. Does this either wait for the next pfFrame (or
> Sync) or cause any appreciable extra work to happen there, or is all the
> work done immediately by the calling process?
There are two main modes of operation for pfFlux buffers:
1. All reads/writes happen in synchronous processes (APP, CULL, DRAW).
2. Some reads/writes happen in asynchronous processes (DBASE, COMPUTE),
while other reads/writes happen in synchronous processes.
In the first mode there is NO global/central processing of pfFlux buffers. At
no time during the course of your application does Performer process all the
pfFlux buffers. The computational cost of using such pfFlux buffers is charged
every time you read/write from/to a pfFlux.
When you call writeComplete, the newly written data becomes visible to readers
(in downstream processes) after the next pfFrame. Performer can achieve this
with no central processing because it marks each written pfFlux buffer with a
frame number. Readers of a pfFlux buffer never see data written at a frame
number newer (larger) than their own.
In the second mode you sometimes group a set of pfFlux buffers into a
sync-group. pfFlux buffers on a sync group can be written to independently.
However, their newly written contents becomes available to readers when calling
pfFrame after calling pfFlux::syncGroupReady (pfFrame calls
pfFlux::syncComplete which marks all the written pfFlux buffers as ready). So,
the more sync-group'ed pfFlux buffers you write the longer pfFrame will take to
process them.
I can think of a single reason for using sync-group'ed pfFlux buffers:
When computing multiple results in an asynchronous process (say - DBASE), you
want to make all the results visible at exactly the same instant. For example -
if your asynchronous process animates the surface of a lake, and computes the
position/angles of a boat on that lake, you want to synchronize the lake
surface and the position of the boat. If you don't, the boat will sometimes
fly and sometimes sink.
BTW, If you run the above lake/boat computation in your APP process, you don't
have to use a sync-group. As long as the writes to the lake/boat pfFLux buffers
happen during the same frame, they will become visible at exactly the same
frame.
-yair
--
\_________ \_____ \__ \__ \_____ 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 : Wed Apr 26 2000 - 13:38:22 PDT