Rob Jenkins (robj++at++quid.csd.sgi.com)
Fri, 6 Feb 1998 11:47:59 -0800
Does that imply that it used to run faster ? If so, how much faster ? If your
performance changed then somethiing else must have, can you pi point any change
in things like: You SW install ( esp patches ), your data, your HW config, your
video combination, genlocking or maybe your app, any changes could be
significant.
BTW when you say 2RMs, 128 M texture memory I assume that means you have 2 64M
RM, in fact that means you still only have 64 M texture memory. More RMs have
texture meory replicated across them, the benefit of more RMs is higher texture
load bandwidth, more framebuffer and faster fill.
> Are there any tools for graphics performance analysis and tuning?
> The "top and gr_osview" doesn't help too much in this aspect.
> Though Performer itself gives this kind of infomation, we suspect
> something not fully configured in our machine.
>
osview can be useful to look for increased I/O or memory swapping for example.
gmemusage usage is useful too. The absolute best tool for looking at
performance though are the Performer stats. In my experience serious system
config or HW problems make things stop working, not just go slow. I expect it's
far more likely that there's either explainable performance bottlenecks
somewhere, or possibly a bug introduced in recent SW installation ( the former
is usually more likely ). I would strongly recommend going through the Prog
Guide section on 'Performance Tuning and Debugging', that may help you narrow
it down and gives far more detail than I can try and do here but some general
advice: Performance problems typically fall into one of these loose categories:
o constant slowness, same for all parts of scene
o intermitent slowness, dependant on position and orientation in scene
o intermitent slowness, regardless of position and orientation in scene, ie if
you stay in the same place with nothing changing you still slow down sometimes.
So first try and work out what you see. If the problem changes as the scene
does then start looking for what changed in the performer stats ( more
textures, more lights, more fill etc ), make sure you're not paging texture (
if you do I/O will go up, you slow down but then if you keep still you should
speed up again ).
If the problem happens occasionally with nothing changing then run:
par -rQQt<time> where time is long enough to run during a slow time, look for
the system kicking you off CPUs and see the realtime section in the FAQs.
If the problem is general then just look at the stats at try to figure out
where the bottleneck is, turn things on/off and see if anything changes ( for
example disable texture or blending or draw less vertexs - see Prog Guide for
more detail ).
> One more thing, frequently we run Performer programs from a PC and
> kill the process later. Are shared momery automatically freed in
> this case? Maybe there are too much rubbish left in the memory because
> of this ugly exit?
>
This little script can clear up a bit if you're worried about that:
quid 8% more bin/ipcrmall
#!/bin/csh -f
foreach type (m s)
foreach thing (`ipcs -$type | tail +3 | grep -v : | awk '{print $2}'`)
echo ipcrm -$type $thing
ipcrm -$type $thing
end
end
Cheers
Rob
--
________________________________________________________________
Rob Jenkins mailto:robj++at++sgi.com
Silicon Graphics, Mtn View, California, USA
=======================================================================
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:56:44 PDT