Rob Jenkins (robj++at++reading.sgi.com)
Thu, 5 Aug 1999 13:18:33 +0100
I'm not sure of the exact calls for latency in pfStats but in your case you
can imagine a case where latency just based on the MP model and the draw
time you have will approach the number you see: APP_CULL_DRAW means 3 frames
from i/p to change drawn, each frame ultimately is draw proc limited to
almost 60 mS by draw, and has to wait for the next swapbuffers. You could
reduce latency by changing MP model, with the numbers you show, APP and CULL
could be the same process for example, reducing latency by a frame (
substantial in your case ).
On the subject of geom perf tuning, you need to analyze the reason for the
long draw in order to tune it, for example, if you were actually fill
limited then all the scenegraph layout tuning in the world won't help. If,
as you already noted, you can do some extra CULL work on a spatially
organized database then you might well reduce the draw time, if indeed
you're geometry/host limited. The PF Prog Guide does have some good
discussion on this, including 'rule of thumb' numbers for tris/strip,
strips/geostate etc so you might take a look through there and see how it
goes, if you need more info then grab a sample of all the stats for a
typical frame and we could look at those.
Cheers
Rob
-----Original Message-----
From: Robert Stein [mailto:rstein++at++ncsa.uiuc.edu]
Sent: 03 August 1999 17:50
To: info-performer++at++sgi.com
Subject: pfStats and Optimization
Hi Everyone,
I have an application that draws adaptive terrain... and I'm trying
to
optimize it for performance on our Onyx2 IR2 system... When I display the
pfStats data there appears a line like the following:
msecs: latency=199.6 app=0.5 cull=5.6 draw=57.0 compute=0.0 dbase=0.0
I understand what all the numbers are except for the one for "latency"
where does this number come from, and how can I reduce it?
Currently the scenegraph is set up such that for the terrain each pfGeoSet
has one (1) tristrip length=128. Each pfGeoSet also gets put into its own
pfGeode, and they are all assigned the same pfGeoState... These pfGeodes
are put into a pfGroup node and the whole this is stuck into the scene...
This is obviously a braindead way of structuring a scenegraph... but other
than increasing the culling cost (which not high as seen above) and
intersecion testing (my datastructure for the terrain handles the
intersection testing quickly) are there other places where this is costing
me? How should such a scene graph be constructed for optimal performance?
Does strip length matter? Num strips per GeoSet? GeoSets per Geode? etc...
Thanks in advance for your help... Also while I'm at it let me sound the
collective YIPPEE for SGI's descision to port Performer to the Linux
platform! :)
Sincerely,
Robert Stein
Robert J. Stein
National Center For Supercomputing Applications
405 N. Matthews, Urbana, IL
(217) 244-7584
rstein++at++ncsa.uiuc.edu
-----------------------------------------------------------------------
List Archives, FAQ, FTP: http://www.sgi.com/software/performer/
Submissions: info-performer++at++sgi.com
Admin. requests: info-performer-request++at++sgi.com
This archive was generated by hypermail 2.0b2 on Thu Aug 05 1999 - 05:18:46 PDT