Re: Stats Question correction

New Message Reply Date view Thread view Subject view Author view

Sharon Clay (src++at++rose.engr.sgi.com)
Tue, 7 Apr 1998 12:30:49 -0700


+>---- On Apr 7, 10:09am, Jay Gischer wrote:
> Subject: Re: Stats Question correction
->In-Reply-To: <9804061311.ZM7807++at++rose.engr.sgi.com>
->
->As they say, learning is a lifetime process. Earlier I said:

And part of that is obviously being well aware of clearly how complicated
the stats have gotten which is unfortunate since that degrades their
usefulness. I think some folks have some better stats tools in
progress and we are looking at how to better enable these (including of
coures fixing bugs) and how to make some of these trade-offs better
in the future and more self-explanatory tools we should provide.

->
->->As it turns out, in perfly there are two contributions to the DRAW
->->stage which are not measured by the perfly stats, pre-draw and
->->post-draw.
->
->I've since found out that this is not completely accurate. Pre-draw
->time is measured and is represented by a dark line before the normal
->line. Post-draw time is measured and is represented by a dark line
->after the normal line.
->
->The GUI redraw is done in a separate channel,
->rather than in pre-draw, but the effect is the same... it appears as
->the gap between the frame-synch vertical bar and the beginning of the
->normal line.
->
->The dotted line represents the time taken to draw stats.

That is the main thing it includes in the simple case but I'll attempt to match Jay's
standards for perfection and detail.
Basically, the dotted line is everything after the end of the draw of the given channel
until swapbuffers is called for that pfPipe.
1) Early Performers (1.0) will remember that the dotted line went to the vertical
    retrace boundary. We stopped that since you can figure out when the
    swap happened yourself and instead stop the line at when we call
    swapbuffers for that pfPipe.
2) Multiple channels just aren't handled as gracefully as they probably could.
    For channels before current one, you get a big space.
    Channels after the current one on the current pipe are thrown into
    the dotted line as well.
    It is just a lot of extra overhead for one channel to know about the
    others (even that there were other active channels) so basically this
    just wasn't handled.
         
Phew! On a positive note, I think the man page (in pfChannel (obviously :-)) and
pguide notes for this graph in Performer2.2 are pretty good and if you sit with
both up in front of you at once you should come up with the above and more...
Just wait till you start cliptexturing and using calligraphic lights!
We found just a bit more space in that graph...

->One other contribution to draw time is system overhead. If you aren't
->running as root with the DRAW process locked down to a processor, you
->could easily be spending 1-2 ms in the OS handling interrupts, I/O,
->and who knows what...

The X clock running on the background :-))

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

New Message Reply Date view Thread view Subject view Author view

This archive was generated by hypermail 2.0b2 on Mon Aug 10 1998 - 17:57:13 PDT

This message has been cleansed for anti-spam protection. Replace '++at++' in any mail addresses with the '@' symbol.