From: Todd J. Furlong (tfurlong++at++e-motek.com)
Date: 07/25/2001 17:08:15
Thnk you for your reply, Yair. That is very useful information, and I
think it will help me.
Now I have another question:
Is a chain of pfEngines able to process on multiple processors?
Meaning, is there a way to cascade the processing from one processor to
the next such that different stages of the chain are being worked on at
the same time but for different frames?
If pfEngines don't work that way, how would you recommend introducing
that functionality to a Performer app?
Thanks,
Todd
Yair Kurzion wrote:
>
> Hello Todd !
>
> A flux with PFFLUX_PUSH on always forces an evaluation of all engines
> that it feeds upon the call to writeComplete. If PFFLUX_PUSH is off,
> writeComplete marks all engines that read this fluxes as `srcChanged', and
> returns.
>
> When creating engine/flux chains, you can ``charge'' the cost of computing
> the engine functions to either:
>
> o The process writing the source fluxes that the engine reads.
> o The process reading the destination fluxes that the engine computes.
>
> In other words, if the source fluxes are written by a slow (asynchronous)
> process like DBASE or COMPUTE, and the destination fluxes are read by any of
> APP/CULL/DRAW, then you often want a writeComplete to trigger an engine
> evaluation in the slow process. This way, when APP/CULL/DRAW try to read the
> destination flux, they don't have to recompute the engine result.
>
> So, if the source fluxes have PFFLUX_PUSH set, the engine evaluation happens at
> writeComplete. Otherwise, if the destination flux has FF_ON_DEMAND set,
> evaluation happens when you getCurData on the destination flux.
>
> Can you use this info to design the flow of your engine/flux chain ?
>
> -yair
>
> > I am creating a chain of pfFlux's and pfEngine's, and I've found that
> > pfFlux::writeComplete() does not return on the first pfFlux until all
> > processing is complete. It seems like pfEngine's have a way around this
> > issue because they finish processing in sequence.
> >
> > First, I create a pfFlux to start the chain with the following options:
> > m_p_Fluxmem->setMode(PFFLUX_COPY_LAST_DATA, PF_ON);
> > m_p_Fluxmem->setMode(PFFLUX_PUSH, PF_ON);
> >
> > Then I create a number of pfEngine's of type PFENG_USER_FUNCTION.
> >
> > So, a chain looks something like this:
> > pfFlux1 -> pfEngine1 -> pfFlux2 -> pfEngine2 -> pfFlux3
> >
> > And here's the order in which things occur:
> > 1. call getWritableData() on pfFlux1
> > 2. write data, call writeComplete() on pfFlux1
> > 3. pfEngine1 user function processes
> > 4. pfEngine2 user function processes
> > 5. writeComplete() on pfFlux1 returns
> >
> > My issue here is that I want to keep putting data into pfFlux1, but my
> > update function that calls writeComplete() get stalled. In the final
> > application, I will likely have multiple branches to the chain, and I
> > need to put data into memory at the speed at which the fastest branch
> > processes.
> >
> > Is there a way to perhaps fork the writeComplete() so that it doesn't
> > slow things down? Or can I somehow start a chain with a pfEngine
> > instead?
> >
> > Thanks,
> > Todd
> >
> > --
> > Todd J. Furlong
> > MOTEK Motion Technology, Inc. voice 603.641.1300
> > 360 Commercial St fax 603.641.8385
> > Manchester, NH 03101 web http://www.e-motek.com
> > -----------------------------------------------------------------------
> > 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
> \__ \__ \__
-- Todd J. Furlong MOTEK Motion Technology, Inc. voice 603.641.1300 360 Commercial St fax 603.641.8385 Manchester, NH 03101 web http://www.e-motek.com
This archive was generated by hypermail 2b29 : Wed Jul 25 2001 - 14:11:51 PDT