Re: pfGeoSet Size

New Message Reply Date view Thread view Subject view Author view

Brian Furtaw (brian++at++dingbat.clubfed.sgi.com)
Tue, 13 Apr 1999 21:57:55 -0400

I went through the insight book version of the "Performer Programmer's Guide"
in IRIX 6.5.3, so you won't see any page numbers below. I pulled out three
excerpts which focus on the topic of pfGeoSet size. I believe number two is the
subject of this Info-performer thread. If you read these quotes they are all
talking about Process Pipeline which is refering to APP to CULL to DRAW
efficiency not graphics pipeline efficiency. Load balancing of vertex data
passing into the graphics pipe is based graphics subsystem architecture. So
different tristrip lengths are optimally processed across the SGI graphics
product line.

These excerpts are simply making reccomendations as to the best lengths for
database traversal and culling algorithm efficiency. I don't know of any limits
to the number of primitives you can send in a pfGeoSet. The pfGeoSet class
defines the number of primitives as an `int', so send lots if you are not
worried about performance.

I think the best length for Onyx2 IR and IR2 is multiples of 8 and for
Octane/Impact graphics it is 9. Maybe someone else could confirm or deny this I
am going off of memory. I don't know for O2 just do some benchmarking the
information below gives you some good starting points.

Excerpts from the Performer Programmers guide,

>From Chapter 4 - Organizing a Database for Efficient Culling

"When modeling a database, you should consider other trade-offs as well. Small
amounts of geometry in each culling unit, whether pfGeode or pfGeoSet, provide
better culling resolution and result in sending less non-visible geometry to
the pipeline. Small pieces also improve the performance of line-segment
intersection inquiries (see"Database Concerns" in Chapter 19). However, using
many small pieces of geometry can increase the traversal time and can also
reduce drawing performance. The optimal amount of geometry to place in each
pfGeoSet depends on the application, database, system CPU, and graphics
hardware."

>From Chapter 19 - How IRIS Performer Helps Performance

"Uses a large number of specialized routines for rendering different kinds of
objects extremely quickly. There's a specialized drawing routine for each
possible pfGeoSet configuration (each choice of primitive type, attribute
bindings, and index selection). Each time you change from one pfGeoSet to
another, one of these specialized routines is called. However, this happens
even if the new pfGeoSet has the same configuration as the old one, so larger
pfGeoSets are more efficient than smaller ones-the function-call overhead for
drawing many small pfGeoSets can reduce performance. As a rule of thumb, a
pfGeoSet should contain at least 4 triangles, and preferably between 8 and 64.
If the pfGeoSet is too large, it can reduce the efficiency of other parts of
the process pipeline."

>From Chapter 19 - Process Pipeline Tuning Tips

"The ideal size of a pfGeoSet (and of each triangle strip within the pfGeoSet)
depends a great deal on the specific CPU and system architecture involved; you
may have to do benchmarks to find out what's best for your machine. For a
general rule of thumb, use at least 4 triangles per strip on any machine, and 8
on most. Use 5 to 10 strips in each pfGeoSet, or a total of 24 to 100 triangles
per pfGeoSet."

Brian

On Apr 14, 9:10am, mnippere++at++csc.com wrote:
> Subject: Re: pfGeoSet Size
> I don't know exactly what the bottleneck would be, or if a problem should
> occur in a pfGeoSet with more than 64 triangles. But I have run with up to
> 180 triangles without any problems. And this was only on a little O2.
>
>
>
>
>
>
> ramey++at++ccpo.odu.edu on 13/04/99 06:24:58
>
> To: info-performer++at++sgi.com
> cc: (bcc: Matthew K Nipperess/AUST/CSC)
> Subject: pfGeoSet Size
>
>
>
>
> pg 591 states that a pfGeoSet should not be more than 64 triangles long.
> Why is this? What would happen if you exceeded this number? Say you had
> 15 primitives and your primitives were tristrips of length 50 or so...
> what could be expected?
>
> What part of the graphics hardware is this going to cause a bottleneck
> in? I am really only concerned about high end systems (OnyxII, O2000)
> with IR,IR2,or RE2 graphics.
> ---------------------------------------------------------------
> Larry E. Ramey ramey++at++ccpo.odu.edu
> 757-683-6276(office) 757-683-5335 (CAVE)
> "Count the heads man." - Zaphod Bebblebrox
> "Won't weigh you down, with good intentions" -Sarah McLachlan
> -----------------------------------------------------------------------
> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
>
>
>
>
>
> -----------------------------------------------------------------------
> List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
>-- End of excerpt from mnippere++at++csc.com

-- 
    ----oOOo----    ----oOOo----    ----oOOo----    ----oOOo----


Brian Furtaw  (brian++at++sgi.com)	
Graphics Guru		       Office:(301)572-3293   Fax: (301)872-3293
12200-G  Plum  Orchard  Drive  OpenGL/Performer/OpenInventor/ImageVision	
Silver Spring, Maryland 20904  Optimizer/React/PCI Device Drivers

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Tue Apr 13 1999 - 20:12:32 PDT

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