OpenGL Insights

A Real-Time Profiling Tool

Lionel Fuentes

35.1 Introduction

As time goes on, video games are becoming more complex, presenting rich environ-

ments, a high level of interaction with the player, gorgeous graphics, physics sim-

ulation, etc. To push the hardware to its limits, developers need to have a precise

knowledge of the time taken by the executed tasks, their distribution on the avail-

able hardware threads, and the dependencies each task has on the completion of

the others. To this end, we focus in this chapter on the use of the time counters

present on CPUs and modern GPUs to provide a real-time and easy-to-use profiler

that is directly embedded into the application. We discuss the role of such a tool in

the context of video game development and how it can benefit both developers and

artists.

The proposed tool works by manually marking in the code the beginning and

ending of the sections that are to be measured. At runtime, we record time stamps

that correspond to the boundaries of the measured sections and display them in

a simple and minimal graphical interface. The time interval between two matching

time stamps is represented by a colored rectangle whose length represents the amount

of time needed for completion of the associated task. We use platform-specific high-

precision timers to measure the time spent on the CPU side and the OpenGL ex-

tension ARB

timer query on the GPU side. The target is the consumer multicore

PC/Mac device featuring one GPU.

503

35

504 VI Debugging and Profiling

35.2 Scope and Requirements

The final goal is to give developers and artists a general look at the time consump-

tion for the different threads of the application, be it on the CPUs or on the GPU.

The tool can be used to search for bottlenecks and synchronization problems in the

targeted application. We aim at fulfilling the following requirements:

• Accuracy. We want our measurements to be as accurate as possible. We

also want to minimize the perturbations due to our measurements and debug

display.

• Real time. Coupled with a live update system of in-game assets, this system

enables artists to tune the quality of their models, textures, and sound settings

in order to fit in the imposed time constraints. Having a real-time profiler also

enables us to analyze how the application’s performance is impacted during its

execution.

• Ease of use. User-friendliness is an important element, as it makes the tool

accessible not only to developers but also to artists. We also want the tool to be

easy to use on the developer side because making it easy to place markers in the

code will result in more markers being inserted and better granularity in the

measurements. Finally, we want the data to be displayed in a useful manner,

making it easy to spot synchronization problems and performance bottlenecks

and identify whether we are CPU-bound or GPU-bound.

• Portability. The proposed tool is embedded inside the game engine itself,

and the display is done using the same renderer the game is based on. As

a consequence, the time querying functions a re the only platform-dependent

part. Having a portable profiling tool gives a uniform and coherent feeling

across all supported platforms, thus making profiling easy when switching to

a new, unknown platform. While it doesn’t replace a fine platform-specific

external debugger like gDEBugger [Graphic Remedy 10, AMD 11], at the

time of switching to a new platform, all previously developed functionality is

immediately available and no learning curve is needed.

• Small. We want the profiler to be enabled and displayed throughout the

whole development process so that developers can keep track of the evolution

of time consumption and detect performance problems as soon as possible.

This can only be done if the space taken on the screen is minimal.