I arrived at an appropriate development stage in my graphics engine that current bottlenecks are interesting to locate and certain optimizations may be appropriate. Here is an abbreviated account of what I did to explore these bottlenecks and search for possible optimizations.

The first thing I wanted to do was to identify any openGL errors that may have crept in my code unknowingly, since these errors can be a bottleneck in certain situations. I defined the following error checking macro and wrapped all the engine's openGL calls appropriately (i.e. CHECK_OPENGL_ERROR(glPopMatrix());)

#define CHECK_OPENGL_ERROR( cmd )   cmd;      { GLenum error;          while ( (error = glGetError()) != GL_NO_ERROR)         { printf( "[%s:%d], '%s' failed with error %s\n",           __FILE__, __LINE__, #cmd, gluErrorString(error) ); }   }

After running the engine with the gl calls wrapped, stdout posted the following:

[C:\src\engine\main.cpp:164], 'glPopMatrix()', failed with error stack underflow

The problem was that I was popping the matrix stack at the beginning of my render function and pushing at the end of the function. This was fine for everything but the first pass through the function, but the first call to glPopMatrix would pop an empty stack. Adding a glPushMatrix call to the setup routine solved this problem. No other errors were detected.

Satisfied that no openGL errors could be degrading my performance, I was ready to identify the bottlenecks in the rendering engine. I was prepared to identify five potential bottlenecks: a framebuffer limitation, a texture limitation, a transform limitation, a transfer limitation, and a CPU limitation.

For this particular exercise, I tested on a laptop. The laptop was a Dell Latitude D810 with a Pentium 2.13GHz and 1GB of RAM. The video card was an ATI mobility Radeon X600.

First, I rendered a simple mesh of Venus twice, without instancing, to a 1900x1200 framebuffer to get a baseline framerate.



At the 1900x1200 resolution, about 40,000 vertices and 87,000 faces were rendered at 37.2 frames per second. I dropped the framebuffer size to 1280x800 and rendered identical geometry.



The framerate did not change. This suggested that either a geometric bottleneck or a application CPU bottleneck was occurring at this level of scene complexity.

Before I determined whether this was CPU (application) limited or geometry (transfer) limited, I wanted to find out where fill limitation (framebuffer) threshold was crossed.

Instead of rendering Venus, I created a course helix in Maya to allow a higher degree of mesh granularity.



At 1920x1200, the engine rendered 48,000 vertices and 49,000 faces; the framerate was 78.4.




Rendering the same scene at 1280x800 revealed a framerate of 78.4. The same geometric-limitation or CPU-limitation existed at this level.


I removed a column of helix and rendered again.




Now a framerate discrepancy was revealed. Rendering 42,000 faces at 1920x1200 offered a framerate at 85.8; while rendering to a 1280x800 framebuffer offered a framerate at 90.2. The fill-limitation of this engine running on the laptop threshold was crossed at ~45K faces.

Now I needed to go back and determine if the original bottleneck was due to my data structures (CPU-limitation) or if the graphics hardware was pushing all the geometry that was possible at the given framerate.

To accomplish this, I needed to be able push the same quantity of data from the engine to the OpenGL pipeline. I used the C preprocessor to substitute glVertex calls with glNormal calls. I created the following header file:



I now included this header file and rendered the mesh of Venus, exactly as I done in the previous step. This was useful because the same quantity of data is being pushed to the openGL pipeline but no geometry is being rendered.




When rendering to the 1900x1200 framebuffer a framerate of 147.7 was noted - a 400% increase in performance. Similarly, using the 1280x800 framebuffer, 333 frames per second was observed - a 425% increase in performance.

This confirmed that when rendering at a scene complexity of about 45,000 faces on my laptop, the engine moves from a fill-limitation to a geometry limitation; and a CPU limitation is never observed.

To test for texturing limitations, I rendered a Poser model with 128,000 texture coordinates using a 3000x3000 resolution .png skin texture. I then resampled the .png to 128x128 and rendered again. The framerate stayed consistent regardless of texture size, thus revealing no texture limitations.

I was able to observe that no transform limitation existed by not using any visibility culling. I then observed the framerate while not moving through the scene and observed the framerate while moving through the scene. The framerate stayed consistent, thus revealing that no transform limitation existed.



Another area of interest at this stage of development is the object selection feedback algorithms. In fact, there was much room for appropriate optimization here. For a baseline reading, I rendered a hellskull mesh to a 1900x1200 framebuffer.



The baseline revealed that rendering 14,000 faces to 1920x1200 framebuffer allowed the engine to maintain a 79.8 framerate.



When placing the mouse cursor over the skull and selected it, the following occurs:


While rendering the correct selection feedback silhouette, the framerate drops to 38.4 - a 52% drop in performance.

To achieve the silhouette effect, I was doing the following:
1. Setting the stencil buffer to create the stencil
2. Rendering the entire mesh into the stencil buffer
3. Setting the stencil buffer to use the stencil
4. Setting line width
4. Rendering the entire object in wireframe mode

This worked well visually. The line width stayed the same no matter where the camera was placed. But there were two things here that could be changed that might improve performance.

First, there was no reason to render the entire image (texture and normal calls included) to create the stencil. So I changed the code to create a display list that was as simple as possible to get the stencil. This revealed another problem in regards to the use of the glStencilOp state function. This was corrected.

Second, there was no need to render the entire wireframe when only the silhouette was needed. So I decided to render only the front and back facing edges.

This was not trivial, as it turned out. First, I had to go back into my original OBJ parsing code to create the edge list. I also had to move my camera class into the world class so I could have convenient access to the eye vector. Once this was accomplished, I had to decide what was a front facing polygon and what was a back facing polygon independent of viewpoint. I implemented this algorithm as a world class method as follows:

>


Now I could achieve the same effect with the following results:


Now the engine enjoyed a 43.9 framerate when object selected was active. With this optimization, the framerate dropped 45% due to object selection, thus mitigating the expense by 7%.

It is important to note that in this particular scene, the object itself is the entire scene. This is an upper bound that would never be realistically presented to the engine in a production state. More commonly, an object that is selectable will be a low-polygon object that is only a small part of the entire scene.

Having coded the edge detection algorithm for the mesh, I decided it might be interesting to bypass the stencil buffer completely. I achieved the following results:



I was actually pleased with these results. Only a %15 drop in performance is observed when bypassing the stencil and the results are visually interesting. I included this code in the engine so that either choice can be made to inform the user what objects are selected in the world - either the stenciled silhouette or the complete edge detection highlights. Here is another example of the edge detection highlights option:







Related resources:

Shreiner, David; Performance OpenGL: Platform Independent Techniques Siggraph 2001 Course #3; April 27, 2001

Hart, Evan; OpenGL Performance Tuning; ATI; Game Developers Conference 2005

West, Mick; Practical Hash IDs - Using 32-bit CRC hash as a unique identifier for game resources; Game Developer Magazine; December 2005


>