Section C.2. Avoid Software Rendering

C.2. Avoid Software Rendering

OpenGL doesn't guarantee hardware acceleration. Even on platforms that allow the application to request hardware-accelerated pixel formats specifically, such as Apple Mac OS X and Microsoft Windows, OpenGL may fall back to software processing if the hardware is incapable of rendering geometry with the current state settings. Furthermore, OpenGL doesn't provide a direct mechanism to query how effectively your application is utilizing graphics hardware.

If your application is using full software rendering, performance will vary depending on the type of rendering operations your application performs but in general will be unacceptably slow. This is usually caused by a system configuration problem or a nonaccelerated pixel format. The following tips will help ensure that your application uses hardware acceleration:

• OpenGL developers are usually on the leading edge of graphics technology and commonly install the very latest graphics-card device drivers on their systems. Many OpenGL vendorssuch as 3Dlabs, ATI, and NVIDIAprovide prerelease drivers to registered developers.

  Make sure that your system has the latest available OpenGL device drivers. Work with your OpenGL vendor to obtain them and ensure that they're installed correctly.

• Ensure that your application asks for only the minimum required capabilities when creating a pixel format or rendering context. If you're using GLUT, remove any unnecessary constants from the parameter to glutInitDisplayMode().

• On systems that allow you to configure the desktop, set the default desktop color depth as high as possible, such as 32-bit. On Linux platforms, use the glxinfo client to obtain detailed information about GLX and OpenGL support.

• Check developer documentation and white papers, available from most OpenGL hardware vendor Web sites. Such documentation generally will enumerate performance pitfalls on the latest hardware and device drivers, as well as optimal rendering techniques.

OpenGL implementations can use software, or a combination of hardware and software, if the underlying hardware can't fully support application commands for any reason. Given the maturity of OpenGL, this is much less of a concern when using modern OpenGL hardware than it was with earlier devices but is still a concern for the very latest features. Again, OpenGL provides no direct mechanism to query for this situation.

To identify commands or groups of commands that might not be accelerated, take timing measurements around suspicious blocks of code, or use one of several third-party software performance tools to identify slow blocks of code. When you've identified commands that take exceptionally long to execute, experiment with OpenGL state settings or command parameters. You might try the following:

• If using a command that takes double-precision floats, such as glMultMatrixd(), and there is an equivalent command that takes single-precision, such as glMultMatrixf(), try the single-precision variant.

• If performance of an equivalent code block is acceptable, determine what state is different between the two blocks of code.

These are just suggestions to get you started. The general idea is to tinker with the code until you find a way to eliminate or minimize the performance hit. Providing general solutions for this type of problem is impossible, because the reasons it can occur are innumerable and vary from one OpenGL implementation to the next.

In conclusion, often, the question of whether application commands are fully hardware accelerated is irrelevant. More important, you must ask, "Is it fast enough?"