OpenGL in Qt 5.1 – Part 4

OpenGL Debug Output

The traditional way to debug OpenGL is to call glGetError() after every GL function call. This is tedious, clutters up our code, and doesn’t warn about performance issues or other non-error situations. In the last couple of years various debug extensions have been proposed and have proven their usefulness. These have very recently been unified into the GL_KHR_debug extension for both OpenGL and OpenGL ES.

KDAB engineer Giuseppe D’Angelo has exposed the functionlity of the GL_KHR_debug extension via the new class QOpenGLDebugLogger which will also be part of Qt 5.1. The QOpenGLDebugLogger class can be used to either request previously logged messages from OpenGL or to emit a signal each time OpenGL logs a message. The QOpenGLDebugLogger::messageLogged() signal can be connected up to a slot where you can respond to the message appropriately, say by outputting using qDebug(), handling the error etc.

The signal can be emitted either asynchronously for minimal performance impact on your running application, or synchronously and with a larger performance impact. Although the synchronous approach has a cost, it does have one massive advantage. Setting a break point in a slot connected to the messageLogged() signal will allow you to break execution and see the stack and the exact OpenGL function call that caused the error or
warning. This is incredibly useful when debugging OpenGL applications and not a glGetError() call in sight!

Using the above mechanism, OpenGL is also able to provide informational messages to us as well as errors. These may include data about where particular vertex buffer objects reside (GPU or CPU memory), if the correct usage hint has been given for a buffer object, or if we are violating it and causing the driver grief resulting in performance issues. All of these and more are now trivially available to us. It is even possible for your application or Qt to inject their own messages into the OpenGL logging system and we can filter based upon message type, severity etc.

About KDAB

KDAB believes that it is critical for our business to invest into Qt3D and Qt, in general, to keep pushing the technology forward and to ensure it remains competitive. Unlike The Qt Company, we are solely focused on consultancy and training and do not sell licenses.

Excellent post. Though I miss the lively discussions with Grumpy OpenGL from Part 1 & 2. Yes I know he was kind of rude, but he asked useful questions. It’s important to have the option to just use Qt for the OpenGL context versus using these helper classes, and to understand the trade-offs about when and how to use each…

It would also be good to understand more about how Qt OpenGL helpers relate to using Qt with ANGLE versus desktop OpenGL. My understanding is that the Qt OpenGL helpers are based on OpenGL ES 2.0, which means they focus on ANGLE.

Most of all, it would also be great to see more info on how to use raw opengl, and how to mix Qt helpers with raw opengl… And if you do this, then how to make sure you can build for both ANGLE and desktop OpenGL… Or is there an easy way to have one build which uses desktop OpenGL when advanced features are supported (on the OpenGL implementation), but uses ANGLE for compatibility mode.