Timothy Moore (moore++at++WOLFENET.com)
Wed, 15 Jan 1997 15:00:51 -0800 (PST)
On Jan 15, 10:22am, Timothy Moore wrote:
> The pfEskyMode may be an important factor in this test. If you can
> use PFES_SKY_GND or PFES_SKY instead of PFES_SKY_CLEAR you'll get
> better performance (but I don't know how that translates into Vega).
You won't get better performance on iR, it doesn't support the TAG clear
which RE2 does so by drawing the sky or ground you add graphics load on iR.
If the simulation requires sky and ground, though, it would seem that
they need to be included in the pixel fill benchmark.
> Have you display listed the geometry which you draw?
>
> Seems like that would reduce this usefulness of this test as a
> simulation benchmark.
>
Well I had assumed this was iR so it's was very significant, and it's
realistic for real applications to display list the database for
two reasons 1) on iR you have a huge <16Mb display list on the GE board.
This goes a long way in a vis sim database, it's also good for storing
reusable objects like a vehicle, and rendering something like a vehicle is
probably your worst case graphics host limit in Vis Sim scenario and
potentially where display lists could buy you back some fill.
2) display lists when not on the graphics board are held optimised
on the host and may draw faster. The iR can also DMA the display
list from the host so for reasonably sized lists it's a win,
especially if you have R4400 processors.
Interesting! What implications does using display lists have for
database paging? 16Mb of geometry information is a tiny database in
my neck of the woods. Is it possible to do display list compilation
in the DBASE process? Seems like it would be with some shared
graphics context hackery. What performance cost does display list
compilation have at simulation time?
Can you compile up an essentially unlimited amount of geometry into
display lists and rely on OpenGL to page the list into display list
cache at the appropriate time?
In anycase this test is clearly trying to isolate and measure pixel
fill, the way to this is to eliminate other factors.
If you want a simulation benchmark you should run a simulation.
Yeah, but if you can only meet your fill rate target by doing things
that aren't practical in the simulation, your fill benchmark is
telling that you can't meet your fill target. Seems like the SGI folks
would be interested in giving Jude some other answer :-)
> color and Z buffers if the depth test succeeds. So, you may get a
> measurably better fill rate if you render polygons front to back,
I very much doubt this would be worthwhile on RE2 or iR systems
unless you manage to occlude some transparency, but anything is worth
a try I suppose.
Yeah.
Angus, the information you provide on iR is very useful. I'll gently
remind you, though, that the RE2 is still a relevant target to many on
this list and its performance characteristics and quirks are germaine
here.
Tim
=======================================================================
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:21 PDT