The VTK Simple Sphere Benchmark Results Database

If you want to bookmark this page, please do
it on this PERMANENT URL rather than the current page

  1. Introduction
  2. What makes differences between platforms ?
  3. What's in the database ?
  4. Results


You will find here results for the "simple sphere benchmark" made by Sébastien Barré and I to evaluate graphics performance of various workstations under the VTK software system.

The original version of the bench was simply timing a flat-shaded spherical triangle mesh rotate on itself.
The second version avalaible here with extensive documentation adds much more options, for example texturing, changing size of the scene, etc...

What makes differences between platforms?

Let's first have a quick glance on how does a graphics rendering chain works [1] :
  1. the application generates some 3D-data to display.

    Of course, something must generate data to be seen.
    Usually, 3D-objects will be displayed as a set of (often planar [2]) 3D filled polygons.
    In our sphere bench, it's simply a VTK module vtkSphereSource which creates bunch of triangles, meshed on a vertices cloud.

  2. 3D geometry is transformed.

    Application coordinates and data can't be drawn directly : there is no warranty that coordinates will match hardware ones, and data must be put into something visible, usually colour.
    So there are in this step scaling, rotating, and colour, lighting, if needed texture, transformations computations.

  3. transformed 3D geometry is projected to 2D view.

    The ultimate rendering device is still a portion of a planar screen or sheet of paper, which are 2D worlds.
    The projection operation must integrate numerous factors like observer's eye characteristics (position, focal, ...), perspective, clipping of out-of-view datas, ...

  4. 2D view is rasterized.

    Until now we've just geometric objects, but nothing visible : we now must compute which screen pixels will be on or off and what colour they will have.
    Previously computed colour, lighting, and texture transformations are used to fill and shade polygons, by a rasterization operation.
    Hidden parts of the scene are obscured using a Z-buffer mechanism where is stored for each pixel the distance to the observer eye.

When a specialized hardware (a graphics card) is present, it can take place at various stages of these transformations.

Some cards can do the job from step #2 to the end, implementing geometrical transformations and rasterization on specialized chips developping several Gflops/s.
Other simpler - and cheaper - ones could do only rasterization - and some wouldn't even have a Z-buffer.

There are also pure-software rendering platforms (like Mesa on Unix systems with unsupported graphics hardware) where every computation is made by the main CPU and the video card is only used as a bitmap of pixels.

So what can impact on performance ?

What's in the database ?

The original version of the sphere benchmark simply drew a flat-shaded triangular mesh with various numbers of polygons (by setting sphere resolution) and was very geometry-oriented. Although we still keep old results in the database.

In version 2 benchmark, we've added some options to adjust the amount of work of the other parts of the rendering chain.

The results

You have to query the database : Defaults settings will send you "small sphere" (v1 bench results) for all platforms available when you'll hit the "Query" button.
System family :
Show performances for :
Flat shading - small sphere
 (v1-bench compatibility)
Flat shading
Stripped polygons
Textured and Transparency

Remarks :

[1] We'll talk only of flat polygons drawing, and not about volume rendering, ray tracing, etc...

[2] Polygons may not be planar (i.e. "nurbs"). But this functionnality is not yet avalaible in VTK.

Back to text

R. Rivière - last modification on 7 july 2000