Re: pfSwitches

New Message Reply Date view Thread view Subject view Author view

Chris Mitchell (chris++at++scotch.physics.ucla.edu)
Sun, 26 Oct 1997 18:34:03 -0800 (PST)

> > Hi pfPeople
> >
> > To eliminate the pfBuffer::merge() overhead in the Dbase
> > process, I have recently been trying to manage a pfSwitch
> > between two processes.
> >
> > A slow update process builds the scene under the
> > unselected switch value while the selected switch
> > value is fed to the graphics pipeline.
> >
> > The problem: The process working on the unselected
> > subgraph causes a SegV when calling
> > pfDelete().
> >
> > I created the process with a regular old fork().
> > Indigo2 Max Impact, Irix 6.2, Performer 2.1.
> >
> > Any ideas? I would greatly appreciate any help.
>
> Only the APP process can modify the database and keep the multibuffering
> safe, that is why Performer introduces the pfBuffer datastructure.

Let me first say thank you for responding.
I thought that if I forked this process from the
APP it would circumvent the multibuffering issue.

I guess that was wrong.

> If the pfBuffer::merge() is a too large overhead, then just like
> texture paging where you do not want to load all the new textures
> in the hardware in a single frame, you have to split the changes
> in small chuncks.

My scene does not really lend itself to "small chunks."
I'm visualizing scientific data, and the entire database
must be updated for each new "timestep" of the experiement.
Is there no other way than a buffer::merge()?

Chris Mitchell
UCLA Physics Department
LAPD Plasma Lab
310-206-1772
chrism++at++ucla.edu
http://scotch.physics.ucla.edu/~chris
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
            Submissions: info-performer++at++sgi.com
        Admin. requests: info-performer-request++at++sgi.com

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:56:07 PDT

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