Rob Jenkins (robj++at++quid.engr.sgi.com)
Thu, 9 Apr 1998 08:18:32 -0700
If the suggestions for testing a fill limitation show that you are not fill
limited then there's some things you can look at to test for a transform
bottleneck. Expensive things in the transform stage are: multiple lights, state
changes ( shademodel, texture, material ). The Performer programming guide has
more detail on tracking these things and also on what can be done ( and what
Performer does by default ) to sort the scene by graphics state. The P.G is
still a bit Reality Engine-centric but the principles are the same if you have
iR. pfStats that might indicate lot's of transform intensive mode changes:
tstrip histogram: large % short strips
primitives per GSet or State: low
unneeded per vertex attributes being sent, eg number of colors equals numbers
of vertices for a flat shaded scene. The geometry stats will show this info.
High total number of primitives, 'high' depends on type of primitive. GLperf
benchmarks will give an idea of peak rates for different types, see
http://www.specbench.org/gpc/opc/glperf_publish/index.html although they only
have numbers for a 1Rm iR there, numbers for more RMs are available somewhere
external to SGI I'm sure. The rule of thumb generally is that getting 70% of
peak throughput for a given primitive type is good going in a real app.
number of lights, type of lights and light models: transform overhead increases
with each light and light model. Shown in the State stats.
Cheers
Rob
On Apr 8, 9:32pm, Sharon Clay wrote:
> Subject: Re: Stats Question correction
> +>---- On Apr 8, 10:56pm, Steve Baker wrote:
> > Subject: Re: Stats Question correction
> ->
> ->On Thu, 9 Apr 1998, Sam Chu wrote:
> ->
> ->> Thank you for detail explanation about statistics. And from
> ->> all informtion provided by those stats Can we find out the
> ->> program is transform bottleneck or fill bottleneck?
> ->
> ->The easiest way is *still* to shrink the size of the window
> ->and see if it goes faster. If it does then it's pretty certain
> ->that it's fill limited. If it doesn't then it's something else
> ->(but not necessarily transforms).
>
> If you have an iR, you can use manual DVR to do this to draw to a smaller
> screen area independent of normal viewport size.
>
> ->
> ->When you do this test, be sure that you switched off Performer's
> ->feature to automatically vary LOD ranges according to display
> ->resolution.
> ->
>
> Right! By default we scale LODs based on viewport and FOV.
> You can set the Channel LOD scale factor to 0. DVR doesn't change
> the channel viewport or FOV so will not have this problem.
>
> src.
>
> --
> -----{-----{---++at++ -----{----{---++at++ -----{----{---++at++ -----{----{---++at++
> Sharon Rose Clay - Silicon Graphics, Advanced Systems Dev.
> src++at++sgi.com (650) 933 - 1002 FAX: (650) 965 - 2658 MS 8U-590
> -----{-----{---++at++ -----{----{---++at++ -----{----{---++at++ -----{----{---++at++
> =======================================================================
> List Archives, FAQ, FTP: http://www.sgi.com/Technology/Performer/
> Submissions: info-performer++at++sgi.com
> Admin. requests: info-performer-request++at++sgi.com
>-- End of excerpt from Sharon Clay
--
________________________________________________________________
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:57:14 PDT