Yair Kurzion (yair++at++polygon.engr.sgi.com)
Thu, 30 Sep 1999 11:46:45 -0700 (PDT)
> I am having problems with performance in the APP process when I paging in
> new data base tiles. Let me describe my problem. I am loading a new
> database tile in the DBASE process. The database may be large, but they all
> branch from 1 node. I page in the tile in a buffer that is separate from
> the APP buffer. I then add the new node to the scene graph with a
> bufferAddChild() and a merge() call.
>
> What I see is a performance hit that seems to be related to the size of the
> database tile that I am paging. The performance hit seems to be in the APP
> process (at least, that's what Performer stats seem to indicate.) In my
> mind, I have a hard time understanding why this is so. I thought adding a
> node/tile to a scene graph is a rather light action, but it seems to take
> over a second to do this in some circumstances! This 1+ second delay in the
> APP process blocks all pfFrame calls and the entire program waits until the
> new tile is added to the scene graphic before drawing anything new. At
> least, that's what I think is happening.
>
> Can anyone explain to me why it appears to take so long to load a large tile
> into the scene graph? Am I coming to the wrong conclusion? What approaches
> can I take to improve my performance?
You probably get a hit from any of the following:
1. The first App frame after a DBASE process frame finishes App merges the newly
generated scene graph into the main scene graph. App registers all
the new nodes that DBASE created into the App node table (aka pfBuffer).
At the start of the next Cull frame, all Cull processes repeat this process
on their copies of each newly generated node.
The per-node cost is very small but if you have many nodes, this could
amount to something.
2. Every frame, the App process cleans up the scene graph. Common cleaning
involves re-computing bounding volumes of new nodes, and of all their
parents on the scene graph. It also involves checking all the new pfDCS
matrices - trying to optimize on special matrix types (translation-only,
affine-rotation-only, etc). The more new nodes you add, the longer cleaning
will take.
Note that adding a node directly under the root node of your scene graph
is cheaper than adding it 10 levels of hierarchy away. A new node triggers
a re-calc of the bounding volumes of all the nodes separating it from the
root of the scene graph. In other words, it is a good idea to page new
geometry into a very flat scene graph structure.
3. If your newly paged scene graph contains many new texture maps, you should
expect a hit when the Draw process downloads the newly visible ones to the
graphic pipe. The more new texels, the slower the next Draw frame.
Performer does not provide a way to split the addition of new geometry onto many
App frames. I think that providing such a way for any general scene graph is
very difficult. In order to minimize the DBASE-merge hit, you have to tune your
application to page in smaller amounts of new geometry every DBASE frame.
Application writers often break their paging geometry into tiles. They measure
the hit that paging their geometry tiles causes (empirically, on their target
machine configuration). They tune the size and complexity of the paged tiles
and the number of tiles paged every DBASE frame so that merging will not make
the App process drop a 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 2.0b2 on Thu Sep 30 1999 - 11:47:03 PDT