Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!sgi!shinobu!odin!cashew.asd.sgi.com!kurt
From: kurt@cashew.asd.sgi.com (Kurt Akeley)
Newsgroups: comp.benchmarks
Subject: Re: VGX benchmark redux
Keywords: VGX, GPC, PLB
Message-ID: <1991Apr10.235306.19549@odin.corp.sgi.com>
Date: 10 Apr 91 23:53:06 GMT
References: <1991Mar28.213128.9355@hellgate.utah.edu> <1991Apr1.154902.17858@odin.corp.sgi.com> <1991Apr9.154616.1976@hellgate.utah.edu>
Sender: news@odin.corp.sgi.com (Net News)
Reply-To: kurt@cashew.asd.sgi.com (Kurt Akeley)
Organization: sgi
Lines: 32

In article <1991Apr9.154616.1976@hellgate.utah.edu>, thomson@cs.utah.edu (Rich Thomson) writes:

[stuff deleted]

|> 
|> >    Display listed triangle mesh (colored):
|> >      62 triangles per mesh: 1020342 triangles per second
|> 
|> I find this interesting.  Apparently, the way to max out the VGX is to
|> use display lists.  I thought SGI considered display lists "naughty".

While we may have implied this, it is not our technical position.  The
Graphics Library has included graphical objects from its creation, and will
continue to do so.  Graphical objects are the right choice for network
graphics, for example, and may also yield the best performance in simplistic
example codes (such as my benchmark).  What *is* naughty is to force
programmers to use graphical objects, or to force them to use immediate mode.
We do neither.

[stuff deleted]

|> I notice that the zbuffer was enabled, but that the Z test was set to
|> ZF_ALWAYS.  I can imagine a good microcoder optimizing that case so as
|> to not perform the read-modify-write cycle to the Z buffer (since the
|> test will always win anyway).  Is a r-m-w cycle taking place, or is it
|> just being written through?

The r-m-w cycle is taking place.  Because ZF_ALWAYS does not eliminate the
nead for the write cycle, it simply isn't worth it to us to optimize this
case.

-- kurt