Timothy Moore (moore++at++WOLFENET.com)
Wed, 15 Jan 1997 10:22:27 -0800 (PST)
On Jan 15, 8:59am, Jude Anthony wrote:
>
> Question 1: Am I missing some important calculation here?
>
> From this calculation, this app should run 30Hz without even breathing
> hard. I must be missing something. Maybe I need to add the screen clearing
> and Z-buffer clearing pixels in here?
You should certainly factor in the time taken to clear the screen.
I've seen 1ms measured for 1280x1024 on iR.
It's quite a bit more than that on an RE2 (the machine in question),
no? I recall a number of 12ms for a screen and Z-buffer clear, though
this can be overlapped with other graphics operations.
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).
>
> Question 2: Is there any way to increase the speed of this app to 30Hz?
>
> I found that by eliminating multisampling, turning off the Z-buffer
> altogether, or not clearing the Z-buffer, I can increase the iteration rate.
> Unfortunately, I'm not allowed to change those things, since the test app
> conditions are supposed to match the simulation conditions.
> I also find that moving the observer back just a little speeds things up.
Have you display listed the geometry which you draw?
Seems like that would reduce this usefulness of this test as a
simulation benchmark.
Have you installed patch 1355?
This is an RE2...
>
> Question 3: In what way does depth complexity directly affect render speed?
>
> If every pixel of every polygon is compared against the Z-buffer before it
> is drawn, then it should make no difference to speed if I overlap several
> polygon strips or spread them out over the screen (as long as the number of
> pixels remains constant). In each case, every pixel gets compared against
> the Z-buffer once before it is drawn, resulting in the same number of
> comparisons ever time. Is there some other way that depth complexity affects
> render speed, or am I misiniformed with respect to the Z-buffer algorythm?
This is correct, z buffering isn't the only issue but on our systems your
reasoning is fine for a lot of cases. It may help to use simpler texture
filters, and does help to use smaller texture formats, blending & shading.
Small polygons will will not give good fill performance.
The test has a depth complexity greater than 1, so you're going to
overlap polygons. Also, Z-buffer comparison is not the only cost
associated with pixel fill. In addition to the texturing, blending and
shading costs mentioned by Angus, There is the cost of updating the
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,
especially if the near polygons are large and occlude much of the
geometry behind them. This may violate the conditions of your test,
but on the other hand it is realistic for many simulation applications
(e.g., rendering own vehicle geometry).
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