From: Allan Schaffer (allan++at++sgi.com)
Date: 01/31/2005 22:16:35
Hello Dimi & all,
Dimi wrote:
> We recently purchased a SGI Prism (I think we are the first in Europe)
> and are experiencing a few strange situations
> when testing with our applications.
> SGI Prism: 8 CPU 1.2 Itanium 2, 16 GB Ram, 4 pipe FireGL2 gfax cards,
> with compositor.
I believe you've already been in touch with our service folks & SE's to
figure out the source of these problems. For others who might be interested
I'll summarize what we did find:
> 1)Our application runs slower on the Prism tha it does on a Linux
> Machine (P4 2.8, GF4 MX. 512MB), when running our
> application on a single pipe. Are there any knows issues witch have to
> do with performer and affect the performance with the new Prism.
For best performance it's necessary to convert data from the previous
immediate-mode rendering style of pfGeoSet to the new pfGeoArray type, which
let you take advantage of the vertex buffer object extension. Performer 3.2
now also contains a Scene Graph Optimizer which will reorganize and optimize
your dataset to be best suited for these cards. The '.gopt' pseudoloader
is the simple way to do this conversion.
Also something interesting coming for Performer 3.2.1 (our next upcoming
release) is enhanced management of the pfGeoArray(s) for cases when they
won't all fit in memory on the card. Results so far are already very promising.
> 2)The compositor was bought in order to speed up the rendering on 1
> screen, by allowing to divide the screen and
> having each of the 4 cards render a portion of it. Unfortunately we DIDI
> NOT see any speedup but actually experienced a 4x DECREASE in
> fps. When lookin at the Performer stats there eas constantly a texture
> download happening which does no exist if you disable the compositor and
> use the cards to render on a different pipe (normal setup).
It appears this one is a simple / easy mistake; the performer application
was being run through the OMP (OpenGL Multipipe) layer to activate the
compositor rather than just directly using the native support in Performer.
For folks who do use OMP, be sure to run your performer apps (like perfly)
using OMP's "-aware" option to bypass the indirection.
As an aside, we've been seeing some very good results with the compositor
via Performer; in one case we have a benchmark showing 88 million polygons /
second on 1-pipe, and 350 million polygons / second when run on 4-pipes
composited; basically a perfect 4x. We were happy to demo this at I/ITSEC
last december.
(Thanks to Amir Meteraso at SGI for working through these issues!)
Allan
-- Allan Schaffer allan++at++sgi.com Engr. Dept. Manager, Visual Systems Group 1-650-933-2160 Silicon Graphics http://www.sgi.com----------------------------------------------------------------------- List Archives, Info, FAQ: 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 -----------------------------------------------------------------------
This archive was generated by hypermail 2b29 : Sat Feb 05 2005 - 02:38:05 PST