Fwd: VTK Timings w/r to OpenGl

[Sean Spicer]

Bob,

Your last email was blown away by a server meltdown here at Stanford...is
there any chance I can get to you re-send the VTK/OpenGL Timing code?

Thanks,

sean

On Wed, 26 Apr 2000, obara wrote:

> Hi Folks,
> 
>  While working on an application that involve thousands of 
> actors in VTK, I noticed really poor graphics performance on a SUN 
> Ultra10 Elite 3D workstation for relatively simple geometry.  I then 
> began investigating what the performance bottleneck was by writing some 
> very simple test applications.  One app was written in VTK and the other 
> was written in OpenGl.  Basically each app displays n cubes (each a 14 
> point triangle strip) and can change the way the data is structured by 
> varying the number of actors (or display lists in the case of OpenGl) 
> used as well as changing the material property of each cube.
> 
> One using one actor (or one display list) the results are basically the 
> same:
> #of cubes      framerate      rendering rate
> 1000      Framerate = 76      .91 MTri/Sec <- limited by frame buffer 
> switching
> 8000      Framerate = 38      3.7 MTri/Sec
> 15625     Framerate = 25      4.7 MTri/Sec
> 27000     Framerate = 15      4.9 MTri/Sec
> 
> However when I changed the number of actors used (even for 1000 cubes) 
> the results differed dramatically:
> 
> 
> For 1000 cubes - simply varying the number of actors
> actors         Framerate           Rendering Speed
> 1          Framerate = 76      .91 MTri/Sec <- limited by frame buffer 
> switching
> 100        Framerate = 76      .91 MTri/Sec <- limited by frame buffer 
> switching
> 125        Framerate = 38      .30 MTri/Sec
> 250        Framerate = 38      .30 MTri/Sec
> 500        Framerate = 19      .23 MTri/Sec
> 1000       Framerate = 9.4     .11 MTri/Sec
> 
> In the case of OpenGl there was no difference with varying the number of 
> display lists (including setting a material property per cube).  The 
> Framerate was still 76/sec
> 
> In the case of increasing the number of cubes beyond 1000 (each with a 
> different material property) using OpenGl:
> 
> # of cubes     Framerate           Rendering Speed
> 1000           Framerate = 76      0.91 MTri/Sec <- limited by frame 
> buffer switching
> 8000           Framerate = 19      1.8  MTri/Sec
> 15625          Framerate = 9.5     1.8  MTri/Sec
> 27000          Framerate = 4.8     1.6  MTri/Sec
> 
> You can see we are getting at least an order of magnitude penalty.
> 
> We also ran both test applications through quantify and saw the following 
> behavior:
> 
> The expected issue:
> There is overhead in vtk itself with so many actors seemingly mainly due
> to the fact that it has to poll each actor for changes before it
> renders each frame. We are working with Kitware to develop solutions
> to this problem.
> 
> The unexpected issue:
> There is something about how vtk and opengl are interacting that
> makes the rendering of the display lists that vtk creates for
> the vtkActorTest much slower than for the plain OpenGl code that we 
> wrote.
> 
> The actual time spent in glCallList for the vtk-based example vs. the 
> non-vtk-based example is something like an order of magnitude greater. 
> 
> We even tried to allocate (and initializing) blocks of memory between the 
> allocations of display lists in the OpenGl example (to simulate the fact
> that with vtk the display lists won't be in contiguous memory blocks).
> This didn't have any noticable effect.
> 
> If anyone have expertise in OpenGl and would like to take a look at why 
> the performance differs so drastically please let me know and I can send 
> you copies of the test programs.
> 
> Please let me know what you think.
> 
> 
> Bob
> 
> 
> 
> Robert M. O'Bara
> Senior Software Engineer
> Simmetrix Inc.
> 1223 Peoples Ave.
> Troy, NY 12180
> 
> Lab: (518) 276-2867
> Main Office: (518) 276-2729
> 
> --------------------------------------------------------------------
> This is the private VTK discussion list. Please keep messages on-topic.
> Check the FAQ at: <http://public.kitware.com/cgi-bin/vtkfaq>
> To UNSUBSCRIBE, send message body containing "unsubscribe vtkusers" to
> <majordomo at public.kitware.com>. For help, send message body containing
> "info vtkusers" to the same address.
> --------------------------------------------------------------------
> 

___________________________________________________________________________
Sean Spicer                       Stanford University Medical Center  
Biomechanical Engineering         Division of Vascular Surgery, Suite H3642
Cardiovascular Biomechanics Lab   Stanford CA, 94305 
                                  Telephone...650.723.1695
                                  Fax.........650.723.8762

             http://solvedeath.stanford.edu/~spicer
 

--------------------------------------------------------------------
This is the private VTK discussion list. Please keep messages on-topic.
Check the FAQ at: <http://public.kitware.com/cgi-bin/vtkfaq>
To UNSUBSCRIBE, send message body containing "unsubscribe vtkusers" to
<majordomo at public.kitware.com>. For help, send message body containing
"info vtkusers" to the same address.
--------------------------------------------------------------------