From: Yair Kurzion (yair++at++polygon.engr.sgi.com)
Date: 06/10/2002 17:31:44
Hello Rob !
I assume you are using a single pipe (right ?). If more than one pipe, are they
genlocked/swap-readied ?
First, look at the Performer stats display and determine what process is the
bottleneck. E.g. if your APP process takes 20 msec per frame, you can not
expect an overall frame rate of 60Hz.
Assuming the DRAW process is the bottleneck, check the stats graph portion of
the DRAW process. Check the dotted line at the end of a DRAW frame. Does
this dotted line extend beyond the vertical retrace line ?
If it does, then you may be fill limited. Shrink your window and see if your
frame rate improves.
BTW, make sure that no other programs running on your machine have a graphic
display. Such programs share your graphic pipe and will make your program run
slower.
Your best bet at tuning your application is isolating the slowest component and
understanding why it is slow. Your best tools for finding the bottleneck are:
o pfFrameStats - see the Performer programmers guide for more details.
o eventView - see `man pfInitializeEvents' and `man eventView' for details.
-yair
> I'm developing a stereoscopic simulation using Performer, and am finding
> it difficult to achieve the 60Hz that we require.
>
> In order to measure the framerate I've used both pfDrawStats() and
> the irix command line 'osview' (this seems to have less of an impact on
> the performance of the application).
>
> When running on an Onyx workstation (with APP_CULLDRAW and LOCKED
> phase) I'm achieveing 30Hz, with approximately 0.5ms and 5.0ms for each
> channels cull and draw processes, which adds up to approximately 11ms.
>
> So, the crux of my question is when running in APP_CULLDRAW with LOCKED
> phase on an Onyx how much time should I expect it to perform swapping of
> the colour buffers, and all other necessary tasks.
>
> Here are a number of things I've tried:
> Limiting the scene to reduce the draw time, this was rather rough but it
> seemed that if reduced the draw time to about 3ms (per channel) then I
> achieved, at least some of the time, 60Hz.
>
> Not using double buffering. Other then causing huge ugly visual
> problems it worked in terms of running at 60Hz.
>
> Running in APP_CULL_DRAW, caused no significant change.
>
> Is this type of performance to be expected? Could this be indicating a
> hardware problem? Please, if you have some advice or comments please let
> me know...
>
> Rob Krajcarski
> DRDC - Toronto
>
--
\_________ \_____ \__ \__ \_____
\_________ \_____ \__ \__ \_____ Yair Kurzion
\__ \__ \____\__ \__ yair++at++sgi.com
\__ \__ \__ (650) 933-6502
\__ \__ \__
\__ \__ \__
This archive was generated by hypermail 2b29 : Mon Jun 10 2002 - 17:31:50 PDT