Angus Dorbie (dorbie++at++bitch.reading.sgi.com)
Thu, 16 Jan 1997 12:56:09 +0000
> 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.
A pixel fill benchmark measures pixel fill. A rendered sky needs to be
included when you count the depth complexity of the scene.
My approach on RE2 with this benchmark would be to TAG clear. This would
give a number I can spend on scene depth complexity (including sky) for
the given shading modes (in the absence of other bottlenecks).
>
> 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?
You would have to display list in the draw process the first time you
draw paged geometry and you can expect some overhead for this in the draw
time which you'd have to measure. You'd only be display listing a little
at a time so it's probably managable.
>
> 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?
On iR it'd either cache on the GE board or DMA from memory both are
potential wins.
You also have control over which display lists reside on the GE board
and which reside in memory using display list priority control.
>
> 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 :-)
I don't agree that any of my suggestions were impractical in a simulation.
The key point is to measure all relevant metrics and apply the numbers
with a little common sense. If you introduce host or geometry limits
while measuring pixel fill you won't be well informed after the
exercise. That doesn't mean that when you bring your measured fill
statistic to the table you ignore host, geometry or other overheads,
you consider those capabilities in context.
If your approach is to introduce other limits then you should measure a
scene representative of your application once you've done everything
practical in simulation to optimise the test.
>
> 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.
I agree, but I'm surprised you get the impression I would think otherwise.
Cheers,
Angus.
=======================================================================
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