8
$\begingroup$

Whenever I make semantic or syntax errors in OpenGL, either I get a black screen or the program crashes. I looked up on internet on how to do error handling in OpenGL and in the documentations I found glGetError(). To my understanding, glGetError() will return one or more error code(s) if I call it after calling a "normal" OpenGL function, provided I have made some error. Also I have to call it in while loop to get all the errors.

I have multiple problems with this. One I can't find the line number on which the error has occurred, second it doesn't tell me properly why the error occurred (not a big problem though) and lastly I have to include a while loop after each OpenGL function call.

Here's an example,

unsigned int buffer = 0;
glGenBuffers(1, &buffer);
glBindBuffer(GL_ARRAY_BUFFER, buffer);
glBufferData(GL_ARRAY_BUFFER, 8 * sizeof(float), vertices, GL_STATIC_DRAW); 

Now if I write it with glGetError(), it would look something like

unsigned int err = 0;
glGenBuffers(1, &buffer);
while( !(err = glGetError()) ){
    std::cout << err;
}  
glBindBuffer(GL_ARRAY_BUFFER, buffer);
while( !(err = glGetError()) ){
    std::cout << err;
}  
glBufferData(GL_ARRAY_BUFFER, 8 * sizeof(float), vertices, GL_STATIC_DRAW); 
while( !(err = glGetError()) ){
    std::cout << err;
}  

Surely this isn't the way to go, right ? The source code looks so ugly.

How do I do proper error handling with OpenGL ?

My graphics card supports OpenGL 4.4 and I am using C++ .

$\endgroup$
4
  • $\begingroup$ I partially answered to a similar question recently. See computergraphics.stackexchange.com/a/5773/182 $\endgroup$ Dec 6, 2017 at 2:45
  • $\begingroup$ shouldn't that read while ( err = glGetError() ) ) $\endgroup$ Feb 6, 2020 at 13:54
  • $\begingroup$ It returns GL_NO_ERROR which I assumed to have value 0, when there is no error, that's why I had != there. In any case it should be while((err = glGetError()) != GL_NO_ERROR). $\endgroup$ Feb 21, 2020 at 17:42
  • $\begingroup$ I like the way The Cherno wrote his error handling code and he goes through it really clearly. youtube.com/… . I will however be using glDebugMessageCallback once I can figure it out:) $\endgroup$ Jul 10, 2021 at 8:43

3 Answers 3

13
$\begingroup$

Yes, there is a better way! 😊 OpenGL 4.3 and later support the glDebugMessageCallback API, which allows you to specify a function in your app that GL will call to issue a warning or error. In this function you can do whatever you like, such as setting a breakpoint in the debugger, or printing the error to a log file. This way you only need to setup the callback during initialization—much nicer than putting glGetError calls everywhere.

To turn on this functionality your GL context also needs to be a "debug context", which is specified by setting a flag when you create the context. The details will depend on which OS / windowing system / framework you're using. A debug context might be slower (on the CPU) than a regular context, but that's the price you pay for more detailed debugging info, kinda like turning optimizations off in the compiler.

See also this wiki page for more information. There's a bunch of other debugging-related functionality. For instance you can give human-readable names to textures, buffers, framebuffers, etc using glObjectLabel, which will then (I assume) be used in error messages. There are also APIs for turning off certain messages or categories of messages, in case you get spammed by warnings that you don't care about or some such.

$\endgroup$
1
  • $\begingroup$ With the ARB_debug_output extension it is possible to use glDebugMessageCallback even with OpenGL 4.0. $\endgroup$
    – Wendelin
    Jul 13, 2021 at 10:44
8
$\begingroup$

While Debug Output is good, and manual glGetError usage is adequate, it's often better to employ a more dedicated tool for finding exactly where OpenGL errors came from.

RenderDoc is probably the most up-to-date tool for this process, but there are quite a few in various states of functionality. These tools can also give you a detailed log of every OpenGL call you've made.

$\endgroup$
0
1
$\begingroup$

If you can't go to OpenGL 4.3 (or your implementation doesn't support glDebugMessageCallbacks), you can simplify your code in a number of ways.

The first is to move the calls to glGetError() into a function like this:

void checkGLError()
{
    GLenum err;
    while((err = glGetError()) != GL_NO_ERROR){
        std::cout << err;
    }  
}

That reduces your code to:

unsigned int buffer = 0;
glGenBuffers(1, &buffer);
checkGLError();
glBindBuffer(GL_ARRAY_BUFFER, buffer);
checkGLError();
glBufferData(GL_ARRAY_BUFFER, 8 * sizeof(float), vertices, GL_STATIC_DRAW); 
checkGLError();

However, calling glGetError() frequently can hurt performance, so it's best to conditionalize it so it only gets called in debug builds by doing something like this:

#if DEBUG
#define checkGLError() debugCheckGLError()
#else
#define checkGLError()
#endif

Then name the actual function debugCheckGLError(). It will get called in debug builds but not release builds.

$\endgroup$
4
  • $\begingroup$ I used the debug macro with the other other answer. Thanks. $\endgroup$ Dec 4, 2017 at 16:23
  • 1
    $\begingroup$ You can go even further with the macro and do something like this: github.com/bkaradzic/bgfx/blob/… so your code just becomes: GL_CHECK(glGenBuffers(1, &buffer)); and reports everything you need. $\endgroup$ Dec 6, 2017 at 2:47
  • $\begingroup$ I don't understand while( !(err = glGetError()) Why the ! ? Shouldn't it be: while(err = glGetError()) so that it loops and outputs error messages? Otherwise, isn't it an infinite loop that repeatedly displays 0 on the first successful call? $\endgroup$
    – Wyck
    Mar 4, 2020 at 5:49
  • $\begingroup$ @Wyck Yes, you are correct. I've updated it to make it more explicit by comparing it to the proper error value. $\endgroup$ Mar 7, 2020 at 21:07

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.