Re: CULL & DRAW times.

New Message Reply Date view Thread view Subject view Author view

Steve Baker (steve++at++mred.bgm.link.com)
Thu, 26 Sep 96 19:30:16 -0500


Bill Storma <BILLS++at++p3.enzian.com> asked why his processing
times increase when he increases his display resolution...

> I am trying to understand the interaction between the app, cull, draw
> times in a performer scene and how the screen resolution affects the
> performance data. The machine I am using is a 3 pipe RE2, with 2
> RM4's per pipe, running Performer 2.0 and IRIX 5.3. All testing is
> being performed at root level.
>
> As I understand the process from the SGI technical manuals, the cull
> process determines what information is to be drawn into a channel
> (pipe). The draw process then determines which polygons are affected
> and then forwards this list to the graphics pipe. Therefore, if I
> run an application at 1280x1024 vice 1024x768, with the same frustrum
> looking at the same scene, the app and draw times should be the same
> for both programs. The screen resolution should only come into play
> inside the graphics pipe, where the tri's are scanned into pixels.
>
> I have setup this exact scenario, and have noticed that the app and
> draw times are longer for the higher resolution screen. If the
> cull is forwarding the same frustrum data to the draw process and
> the draw is processing the same number of polygons in the scene,
> why are the process times higher with a higher resolution screen ?
> Have I missed something in understanding how the system flows
> information from one process to the next ? Can someone explain
> exactly why the app and draw times are affected by the screen
> resolution ?

Bill's understanding of the machine certainly agrees with my mental
picture of the beast and I find it hard to explain the increased
APP time - but both CULL and DRAW variations can be expected
under some circumstances:-

1) When you drop the resolution of the screen, Performer reasons
   that you don't need your LOD nodes to turn on quite so close
   to the eye. Hence, dropping the resolution could result in
   some nodes being dropped from the scene - and CULL might
   have less work to do down at the leaves of the tree.
   (There is a way to stop Performer from doing that if it
   matters to you).

2) Since CULL might draw stuff at lower LOD - or drop stuff out
   altogether, it follows that DRAW might have more polygons to
   process - making it run faster at lower screen resolution.

3) In addition to that, there might be times (if your polygons are
   large in area) when the Raster managers down at the far end of
   the pipe are too busy stuffing pixels to accept new polygons.
   Some kind of FIFO then proceeds to back up until (possibly) the
   Geometry engines cannot output more polygons because there is
   nowhere to put them. At that point, they too have to pause.
   Meanwhile, DRAW is still stuffing polygons into the GE - and
   the input to the GE will eventually block and DRAW time will
   be wasted. If you drop the display resolution enough - then
   the RM's have less pixels to draw, the GE's don't pause so
   often - and DRAW doesn't waste so much time.

But APP slowing down is harder to explain - unless you are missing entire
frames at the higher resolution or something odd like that. Maybe
a pfPerson can come up with a likely explanation?!?

  Steve Baker 817-323-1361 (Vox-Lab)
  Hughes Training Inc. 817-695-8776 (Vox-Office/vMail)
  2200 Arlington Downs Road 817-695-4028 (Fax)
  Arlington, Texas. TX 76005-6171 steve++at++mred.bgm.link.com (eMail)

=======================================================================
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:53:38 PDT

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