Re: how to make each channel's Cull & D

New Message Reply Date view Thread view Subject view Author view

Jeff Brickley (jbrickley++at++lmwsmr.lesc.lockheed.com)
Tue, 01 Oct 1996 10:22:11 -0700


Frames-Per-Second rates are usually application specific and limited to
hard-ware maximums. We can easily maintain 30fps on our IR for most
applications, although we DO have processors to spare and more Raster
Managers than most. However, we had some difficulty with our specific
application when we first got the IR (we were abusing the poor thing on it's
first week here <grin>). With some help from SGI we were able to optimize
it for the new architecture and get our application up to some GREAT speeds
under the new architecture -- I love the IR's!!
     I can still abuse it to the point of reducing it to 4fps, but it takes
a LOT of work for me to do it (and I'm still working on improving that rate
too...).
     Jeffry Brickley
     3D Systems Programmer
     Lockheed Martin
     White Sands Missile Range
P.S. we use dual pipe and dual channel and can still maintain 30fps if we
try, although for our application we generally limit it to 20fps so the IR
doesn't run faster than the rest of our equipment.... Thanks SGI!
 ----------
From: cege
To: Bernard Leclerc; flysiml
Cc: info-performer
Subject: Re: how to make each channel's Cull & D
Date: Monday, September 30, 1996 5:28PM

We are also working on a project that will use three displays. Your reply
worries us since we want 30fps. We are, however, going to be running it on
an
Infinite Reality Engine. What type of RE are you running your application
on
that gave you those performance results? If it isn't an IRE, would you
expect
a problem getting 30fps with an IRE?

=======================================================================
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:53:42 PDT

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