Javier Castellar (javier++at++sixty.asd.sgi.com)
Sat, 23 Nov 1996 22:52:08 -0800
* FILL RATE:
There are different types of pixel fill rate: with or without Zbuffer, with or
without texture, ... etc.
Depending on the market we provide the proper numbers, this numbers are being
used in all SGI marketing presentations.
- Volume rendering is around 200Mpixels per each RM
- Visual simulation "mixtures" get around 170Mpixels per RM although we
initialy used 150Mpixels/RM to provide a security margin. If you are using DVR
you should use 170.
The peak numbers (if you are willing to compare apples with apples) are
around 220Mpixels/RM
On the Onyx2 version of the iR you will get 10% better numbers since we
included some improvements in the TM ( we included it just in time ! ).
* PIXEL PATH
The pixel path is typically independent of the number of RMs if you are
not fill limited. If you are fill limited it will depend on the size of the
pixel transfer (it may fit into the internal iR buffers).
We had a nice example is SIGGRAPH'96 with the REALTIME film preview on
Onyx iR:
2048x1024 at 24hz uncompressed from disk into frame buffer. Around 170MB/s of
pixel transfer (glDrawPixels). This system was using only one RM.
On Onyx2 this numbers are better since the host bandwidth is also
better.
* BY THE WAY ... BAD HABITS WITH PIXELS ...
When using glDrawPixels/ReadPixels remember that the raster position is
transformed by the model and projection matrix, as well as clipped by clipping
planes, Zbuffered, textured ... etc. Remember to disable texture, and use the
right viewport and transform matrix. While "going into 2D" please DO NOT abuse
of glGetXXXXX, use glPush/PopAttrib and glPush/PopMatrix.
In real time applications, try to avoid glGet, it will safe you tons of
ms and undeterministic frame times.
Regards.
-Javier
The fortune of the week:
# SalesRep from InterCrash:
"... and if you don't use stupid fog, use VGA resolution instead of 1280x1024,
turn off the antialias, the mipmapping and simplify the database we can offer
better price/performance ratio than SGI at 20hz"
# VisSim customer:
" ... and if I don't render any polygons I don't need an IG since my syster
can draw it at 60hz with a calligraphic pencil"
On Nov 23, 12:11am, Hansong Zhang wrote:
> Subject: Re: Generating 4 channels on one iR at 60 Hz?!?
> Steve Baker wrote:
> >
> > Hendrik-Jan van Veen said:
> >
> > > b> Pixel Fill Rate for 2RM's is approximately 400M pixels/sec, or 6.6M
> > > pixels/frame at 60Hz. Thus, an average depth complexity of 3 should be
> > > possible. This is not much, but it depends strongly on your application
> > > whether it's sufficient or not.
> >
> > I don't think many people are still quoting 200Mpixels/sec per RM as a
> > figure that you will 'typically' achieve. I have heard several smaller
> > figures for pixel fill in the last year.
> >
> > Someone from SGI should give the official position.
> >
>
> Yeah, here's another pair of interested ears...
>
> Also, to repeat the question I posted early today (well, yesterday),
> what's the relationship between number of RM's and pixel TRANSFER rate?
> (Or, what's the relationship between fill-rate and tranfer-rate (if
> any)? )
>
> Hansong
--
*************************************************************************
* Javier Castellar Arribas * Email: javier++at++asd.sgi.com *
* * Vmail: 3-1589 *
* Member of Technical Staff * Phone: 415-933-1589 / 2108 (lab) *
* Core Design - Applied Engineering * Fax: 415-964-8671 *
* Advanced Systems Division * MailStop: 8L-800 *
*************************************************************************
* Silicon Graphics Inc. *
* 2011 N. Shoreline Boulevard, *
* Mountain View, California 94043-1386, USA *
*************************************************************************
"Violence is the last refuge of the incompetent"
Hardin Seldon
=======================================================================
List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:54:00 PDT