Contents:

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...

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 ?

• in every case the card will have to be fed with data issued from previous steps.

  This can be a serious hardware requirement, as 3-D vertices float coordinates and associated data may represent big volumes of data to transfer. So the bus speed and throughput, general architecture of the computer may have great importance.


 
• hardware implementation of various stages of the chain and its effective use by graphics library and drivers.

  Typically, one or several specific chipsets may be present :

  • a geometry engine working on steps 2 and 3
  • a texture engine
  • a raster engine for step 4
  • an hardware Z-buffer

 
• CPU speed when some parts of the rendering chain are not done by hardware.

  Previous specialized engines, if not here, will be replaced by software routines executed by the main CPU. It may also happen that available library or driver aren't able to use the chips.
  For example, under the Mesa library, 100% of rendering may be done by software, and then CPU speed would be the only factor of performance.

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.

• Geometry work is still adjustable by the SphereSource resolution.

  We store in database the resolution giving the bests results. The polygon count for a resolution of R is 2 * R * (R - 1) which gives :

  Sphere resolution	Number of polygons
  128 x 128	32,512
  256 x 256	130,560
  512 x 512	523,264

  It's now also possible to evaluate impact of triangle stripping by using or not a Stripper vtk module (stripped triangles is a reorganised mesh limiting amount of node coordinates processing and often optimised on hardware).

• Rasterization work is now adjustable :
   
  • by changing the size of the object displayed : the bigger the sphere will be, the more pixels will have to be filled.

    The old size of the sphere (radius 0.5) is keeped in the database (under the name small sphere) for compatibility with version 1 bench. The new radius of 0.9 is the reference size for options testing.
    It's also possible to increase size of the rendering window. This option is only for user tests, we don't keep in the database results for window size different from default (400x400).

  • by activating or not several options frequently used in scientific visualization :
    • texturing
    • transparency (eventually combined with texturing)
    • wireframe
       
  • screen depth is another important factor.

    It's the number of bits used for each pixel to store its colour. A 8-bit screen will display 256 colours (obviously not enough for sci-viz), a 32-bit one will be able to display more than 16 millons coulours, each in 256 levels of opacity. The more bits per pixel there are, the more operations the rasterization stage will have to perform. Some hardwares are optimised for a given screen depth (for example 16 bpp), and will be slower for other screen depth.
    This parameter isn't configurable by application. It's a system parameter, users may adjust it by specific mechanisms - or may not at all, but we keep it in the results database.

• choose what kind of platform you wish to look at
• and/or what kind of rendering option.

Back to text