[3.0] (not so) IMPORTANT : vtk performance drop ? : solved (c lipping range)
Lisa Sobierajski Avila
lisa.avila at kitware.com
Fri Nov 5 10:18:21 EST 1999
<x-flowed>Yes Jim, that is what I meant only I did not state it quite so coherently.
I looked at the code and it seems that we are asking explictly for a "less
than or equal to" operator on Z buffer comparisons. I suspect that the
reason this big change is seen only on some graphics cards is that those
are the ones that are ignoring the LEQUAL and doing a strict LESS instead
(otherwise you shouldn't see a difference).
Lisa
At 08:35 AM 11/5/99 -0500, Miller, James V (CRD) wrote:
>Here is a possible interpretation (or perhaps just a clarification of
>Lisa's hypothesis :)
>
>A Z-buffer operation is essentially an "if-check" followed by a
>write. When the clipping planes are
>far apart, all of sphere geometry mapped to a few bins in Z. As a
>consequence, the "if-check" failed
>frequently and the write operation was avoided. When the clipping planes
>were brought in tighter,
>the sphere spans more of the Z-buffer, the "if-check" fails less
>frequently, causing more write
>operations into the Z-buffer, slowing down performance.
>
>Intuitively, I am happy with this explanation. That is until I think
>about the fact that we are
>rendering a single sphere in the benchmark. When rendering a sphere, I
>would expect only two
>"if-checks" per pixel over the vast majority of the sphere with the
>potential of more Z-buffer
>operations near the boundary of the sphere. I wouldn't expect this
>degradation in performance.
>However, I think the sphere benchmark uses a very high resolution sphere,
>perhaps with more triangles
>than pixels. In this case, multiple triangles map to the same pixel,
>requiring more than two
>"if-checks" per pixel across the sphere.
>
>
>
> > -----Original Message-----
> > From: Lisa S. Avila [mailto:lisa.avila at kitware.com]
> > Sent: Thursday, November 04, 1999 11:33 PM
> > To: Sebastien Barre; vtkusers at gsao.med.ge.com
> > Cc: Volpe, Christopher R (CRD); Robert Riviere
> > Subject: Re: [3.0] (not so) IMPORTANT : vtk performance drop
> > ? : solved
> > (clipping range)
> >
> >
> > I made the change to the clipping range some time shortly
> > after the 2.4
> > release went out. I thought I sent a note out to the list, but maybe I
> > forgot.
> >
> > There were two reasons for the change - first, the previous
> > way that the
> > clipping range was initially computed was very conservative
> > (wasted a lot
> > of the range of the z buffer). Also, the way that the
> > clipping range was
> > updated during interaction (rotate, pan, zoom, etc.) did not prevent
> > objects from being clipped - so if you zoomed in a bit you
> > would clip your
> > object. I added a method to recompute the clipping range based on the
> > bounding box of all props, and this is called from the
> > interactor to keep
> > the objects from being clipped. If you modify the camera directly, the
> > clipping range will not be recomputed (allowing the user to
> > cause clipping
> > if desired).
> >
> > It is disturbing that tightening the clipping range can have such a
> > negative impact on performance. I suspect that some parts of
> > the rendering
> > pipeline are being avoided (some pixels aren't being drawn) due to the
> > decreased resolution causing two points to have the same Z
> > value (whereas
> > they would have different Z values with more resolution in
> > the Z buffer).
> > Maybe.
> >
> > Lisa
> >
> >
> > At 12:44 AM 11/5/99 +0100, Sebastien Barre wrote:
> > >Here are the conclusions regarding my two previous emails :)
> > >
> > >[nightly] IMPORTANT : vtk huge rendering performance drop ?
> > >[nightly] IMPORTANT 2 : vtk huge rendering performance drop ?
> > >
> > >The problem was : Christopher Volpe and I noticed huge
> > performance drop
> > between
> > >VTK 2.4 official and VTK 3.0 (current nightly releases)
> > using the VTK Sphere
> > >Bench (http://www.hds.utc.fr/~barre/vtk/sphere-bench.html).
> > >
> > >After performing some checks, it seems to me that the whole stuff is
> > related to
> > >the way clipping planes are computed... And of course, my
> > inability to detect
> >
> > >this change efficiently in my script :)
> > >
> > >I do apologize, there was NO "huge performance drop", there
> > was "just" a
> > >(undocumented ?) change in the way VTK computes default
> > clipping planes, and
> > >this won't hit your application, unless you are doing some
> > very specific
> > stuff
> > >like a benchmark which relies on static default values :)
> > >
> > >I do not know (or remember) exactly why the clipping range method was
> > changed,
> > >I'm sure it's for the best, but this was a bit tricky to spot :)
> > >
> > >Here are the facts :
> > >
> > >When I wrote the script some time ago, I added some lines to
> > check the
> > defaults
> > >values of the default active Camera of a vtkRenderer :
> > >
> > > set my_defaults {
> > > $active_camera {
> > > GetClippingRange {0.348564 17.4282}
> > > GetDistance 3.48564
> > > GetFocalPoint {0 0 0}
> > > GetParallelProjection 0
> > > GetViewAngle 30
> > > }
> > > }
> > >
> > >These were the values that were intended, and a warning
> > would be emitted
> > >otherwise. From time to time, Robert Riviere (who maintains
> > the results
> > >database) and I received some bench results were the
> > clipping range values
> > were
> > >not exactly the same, but we paid not much attention as they
> > were very
> > close to
> > >our default values (I will introduce a +- x% tolerance in
> > the next release of
> > >the bench 2.1)
> > >
> > >BUT, this changed dramatically somewhere during the 2.4-3.0
> > nightly release.
> > >According to Christopher Volpe, "the change (if I recall
> > correctly) was to
> > >compute the clipping planes by computing all the actors'
> > bounding boxes
> > and to
> > >project the vertices onto the VPN, keep track of the max and min
> > distances, and
> > >then use those values as the near and far clipping planes.
> > This prevents
> > >wasting z-buffer resolution on empty space."
> > >
> > >Here are the new values of the active Camera in our
> > situation, according
> > to my
> > >bench :
> > >
> > >System :
> > > - VTK 3.0.0 (rev: 1.322, 1999/11/02 01:06:27)
> > >
> > >Defaults :
> > >WARNING : $active_camera GetClippingRange was 2.44347
> > 4.52015 , should be
> > >0.348564 17.4282
> > >
> > >Apparently, the way the default clipping range (in our
> > simple sphere context)
> > >is computed is different, although the picture looks exactly
> > the same (and
> > this
> > >is also where my mistake also relies, I trust my eyes too much :)
> > >
> > >Sadly, this has a disastrous effect on the results :
> > >
> > >System :
> > > - VTK 3.0.0 (rev: 1.322, 1999/11/02 01:06:27)
> > >
> > >Best results, summary :
> > > 1) 256x256 : 2408.3 kpolys/s : [stripper]
> > > 2) 256x256 : 1912.5 kpolys/s : [small_sphere]
> > > 3) 256x256 : 1283.4 kpolys/s : []
> >
> > > 4) 256x256 : 1279.2 kpolys/s : [transparency]
> > > 5) 256x256 : 1262.6 kpolys/s : [texture]
> > > 6) 256x256 : 1250.5 kpolys/s : [texture, transparency]
> > > 7) 256x256 : 689.3 kpolys/s : [wireframe]
> > >
> > >Compared to the 2.4 offical release :
> > >
> > >System :
> > >- VTK 2.4.0 (rev: 1.211, 1999/06/30 17:48:40)
> > >
> > >Best results, summary :
> > > 1) 256x256 : 3197.9 kpolys/s : [stripper]
> > > 2) 256x256 : 1950.7 kpolys/s : [small_sphere]
> > > 3) 256x256 : 1950.7 kpolys/s : []
> > > 4) 256x256 : 1950.7 kpolys/s : [transparency]
> > > 5) 256x256 : 1393.4 kpolys/s : [texture, transparency]
> > > 6) 256x256 : 1388.4 kpolys/s : [texture]
> > > 7) 256x256 : 886.7 kpolys/s : [wireframe]
> > >
> > >Huge drop (30%).
> > >
> > >Please note that it *depends* on your hardware ! Clipping
> > range seems to
> > have a
> > >more or less impact depending on the way your Z-buffer is handled. I
> > noticed NO
> > >performance drop using my 3dlabs GMX 2000 at home, and a
> > strong effect on my
> > >Visual SGI 320 (as seen above).
> > >
> > >I will update the script very soon, and it will correct the values
> > >automatically so that they might respect the compatibility
> > with our database
> > >(VTK 2.0, 2.1, 2.2, 2.3, until offical 2.4). I guess Robert
> > and I may have to
> > >ask these who sent us results using later release to do
> > their tests again :(
> > >
> > >Sorry again for the buzz/noise.
> > >
> > >
> > >-------------------------------------------------------------
> > ----------------
> > >This is the private VTK discussion list. Please keep
> > messages on-topic.
> > >Check the FAQ at: <http://www.automatrix.com/cgi-bin/vtkfaq>
> > >To UNSUBSCRIBE, send message body containing "unsubscribe
> > vtkusers" to
> > ><majordomo at gsao.med.ge.com>. For help, send message body containing
> > >"info vtkusers" to the same address. Live long and prosper.
> > >-------------------------------------------------------------
> > ----------------
> > >
> >
> >
> >
> > --------------------------------------------------------------
> > ---------------
> > This is the private VTK discussion list. Please keep
> > messages on-topic.
> > Check the FAQ at: <http://www.automatrix.com/cgi-bin/vtkfaq>
> > To UNSUBSCRIBE, send message body containing "unsubscribe vtkusers" to
> > <majordomo at gsao.med.ge.com>. For help, send message body containing
> > "info vtkusers" to the same address. Live long and prosper.
> > --------------------------------------------------------------
> > ---------------
> >
>
>
>-----------------------------------------------------------------------------
>This is the private VTK discussion list. Please keep messages on-topic.
>Check the FAQ at: <http://www.automatrix.com/cgi-bin/vtkfaq>
>To UNSUBSCRIBE, send message body containing "unsubscribe vtkusers" to
><majordomo at gsao.med.ge.com>. For help, send message body containing
>"info vtkusers" to the same address. Live long and prosper.
>-----------------------------------------------------------------------------
-----------------------------------------------------------------------------
This is the private VTK discussion list. Please keep messages on-topic.
Check the FAQ at: <http://www.automatrix.com/cgi-bin/vtkfaq>
To UNSUBSCRIBE, send message body containing "unsubscribe vtkusers" to
<majordomo at gsao.med.ge.com>. For help, send message body containing
"info vtkusers" to the same address. Live long and prosper.
-----------------------------------------------------------------------------
</x-flowed>
More information about the vtkusers
mailing list