RE: Magazine Articles

New Message Reply Date view Thread view Subject view Author view

Michael Jones (mtj++at++babar)
Sun, 7 Apr 1996 22:57:13 -0700


The fabled 100x number is a misprint in one of the first-day's
press releases. It was corrected that day and was communicated
to everyone who the first one was sent to. It has been made as
clear as possible since then, and does not appear in any other
literature/releases/sales guides/etc. (perhaps we should find
some case where it's 100x faster just to answer this question,
one obvious case would be drawing >16MB of texture where lack
of paging could make such a difference if texture thrashing was
avoided).

It's clearly 10x at most things, faster than that in a few cases
and less than 10x in others. We generally say 4x to 5x the
polys for vis sim apps, and 3x to 4x the pixel fill per RM,
just to be sure.

We see more than 5 million triangles per second in perfly, in
IRIS Performer 2.1, so I know that it's fast, but just how much
faster would depend on many subtle factors. Also, there is always
the possibility of host limitation: if cpu's and busses can't
keep up with the faster graphics then the application speedup
will not be as much as the potential of the machine.

None of this is new news, and the customers we've had into the
InifiniteReality porting palace have seen excellent performance
in their applications. The biggest caveat is when a huge multi-
pipe application is crammed into a single-pipe iR -- you really
need to make sure that host limitation does not become a problem
for your application.

This is how it always is: graphics get faster, then CPUs, then
graphics, then CPUs, etc.

Michael Jones

Be seeing you, Phone:415.933.1455 Fax:415.965.2658 M/S:8U-590
Michael T. Jones Silicon Graphics, Advanced Systems Division
mtj++at++sgi.com 2011 N. Shoreline Blvd., Mtn. View, CA 94039-7311
                    "Du musst Amboss oder Hammer sein" -- Goethe


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:52:41 PDT

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