O'Reilly logo

OpenGL Insights by Christophe Riccio, Patrick Cozzi

Stay ahead with the world's most comprehensive technology and business learning platform.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, tutorials, and more.

Start Free Trial

No credit card required

Improving Performance by
Reducing Calls to the Driver
S
´
ebastien Hillaire
25.1 Introduction
Rendering a scene can involve several rendering passes such as shadow map construc-
tion, light contribution accumulation, and framebuffer postprocessing. OpenGL is
a state machine, and each of these passes requires changing state several times. Ren-
dering requires two main steps:
1. Modify OpenGL states and objects in order to set up the assets used for ren-
dering.
2. Issue a draw call to draw triangles and effectively change some pixel values.
These two steps require multiple calls to the driver. The driver is responsible for
translating these function calls into commands to be sent to the GPU. The driver is
provided by the GPU vendor and could be considered as a black box where only the
vendor knows what is being done by each function call. At first, it seems reasonable
to think that the drivers are filling a FIFO command queue that will be used to render
the next frame. However, the drivers behavior can be very different depending on the
vendor and/or platform. For example, a GPU driver for desktop computers has to
take into account the wide variety of hardware that makes drivers a lot more complex
than their counterpart on consoles, for which the platform is entirely and reliably
known [Carmack 11]. Indeed, on such a platform, the driver can be specifically
optimized for the installed hardware, whereas on the PC, the API requires a higher
level of abstraction. Therefore, we should assume that each call to the OpenGL API
353
25
354 IV Performance
will result in costly driver operations such as resource management, current state
error checking, or multiple shared context threads synchronizations.
This chapter presents solutions that can be used to reduce the number of calls to
the graphic driver in order to improve the performance. These solutions allow us to
reduce the CPU overhead and hence increase rendering complexity.
25.2 Efficient OpenGL States Usage
Accessing and modifying OpenGL states can only be done through multiple calls to
the API functions. Each call can potentially consume a lot of processing power. As a
result, care must be taken to efficiently change OpenGL states using a s few API calls
as possible. In the OpenGL 1.0 days, state change operations could be accelerated
using display lists which stored precompiled commands that could be executed in
a single call. Despite being static, display lists were used as a fast way to change
OpenGL states. However, they were removed from the OpenGL 3.2 core profile but
are still available in the compatibility profile.
This section presents ways of detecting and avoiding unnecessary API calls. We
also present recent OpenGL features that allow us to increase the efficiency of each
call intended to change the current OpenGL states.
25.2.1 Detecting Redundant State Modifications
Debugging and optimizing an OpenGL application can be made easier by using
some specific existing software. gDEBugger [Remedy 11] is a free tool that can record
the OpenGL function call sequence for each frame independently. An important
feature of this software is the Statistics and Redundant Function Calls Viewer, as seen
in Figure 25.1, accessible using Ctrl+Shift+S. It allows us to count the number of
Figure 25.1. Using gDEBugger statistics to detect redundant OpenGL calls.

With Safari, you learn the way you learn best. Get unlimited access to videos, live online training, learning paths, books, interactive tutorials, and more.

Start Free Trial

No credit card required