ARB_debug_output maturity

How does ARB_debug_output currently compare to the D3D debug runtime? Do the two major vendors offer similar diagnostic capability?

I haven’t used OpenGL in a few years, but I have the choice to move back to it for my current client. I don’t really need Linux or Mac compatibility, but it would be nice not require Windows Vista or 7. I’ve been stuck in D3D land for so long that the debug runtime has spoiled me. I don’t want to go back to glGetError. Speed of development is the most important thing to me right now.

i can only speak for the nvidia platform and to be honest: useless in its current state. you just get the exact error returned as glGetError would give you. no additional information and no performance hints. the only benefit is when you break on your error callback you can easily find the OpenGL call generating the error. but that is currently it. very sad.

gdebugger is real handy. It can do stuff like pause your app on an opengl error.

Not even implemented on AMD! And AMD designed this AMAZING extension :stuck_out_tongue:

This extension has a huge potential, it’s really required to make something out of it!

I can also speak only for NV implementation.

  1. Debug_output is more useful than glGetError because:
    1.1. Callback function is called immediately after error is casted, so you don’t have to insert glGetError on zillion different places in the code. As Chris already said, it certainly alleviates error locating.
    1.2. Along with error code, debug_output provides description. Usually description is not useful, because vendors still don’t use it in most cases. But few days ago, I have noticed some interesting descriptions, which, frankly, I didn’t understand. :slight_smile:
  2. Debug_output enables casting custom errors (not just errors generated by GL).

Generally, it is very interesting mechanism, but it is not widely used. Furthermore, until vendors start to describe errors more precisely, information gather with this extension will be on the level of glGetError.

I wouldn’t say it is not implemented on AMD. Although it is a little bit annoying, this is how I handle it…


if(GLEW_ARB_debug_output)
{
 glDebugMessageCallbackARB(&DebugCallbackARB, NULL);
}
else if(GLEW_AMD_debug_output)
{
 glDebugMessageCallbackAMD(&DebugCallbackAMD, NULL);
}

this is how I handle it…

That seems rather unlikely to work, since the two extensions use different function pointer prototypes.

Come on, so what?

glDebugMessageCallbackARB(&DebugCallbackARB, NULL);
glDebugMessageCallbackAMD(&DebugCallbackAMD, NULL);


static void CALLBACK DebugCallbackARB(GLenum source, GLenum type, GLuint id, GLenum severity, GLsizei, const GLchar* message, GLvoid*)
{
 OutputDebugMsgARB(source, type, id, severity, message);
}

static void CALLBACK DebugCallbackAMD(GLuint id, GLenum category, GLenum severity, GLsizei, const GLchar* message, GLvoid*)
{
 OutputDebugMsgAMD(id, category, severity, message);
}

Come on, so what?

Sorry; missed that. AMD and ARB do look very similar…

I haven’t been using GLEW for a long time, and I’m not sure if it handles GL rendering context regularly (I read that there are some problems). In order to use debug_output WGL_CONTEXT_DEBUG_BIT_ARB flag must be set.

It would be unnatural for AMD not to support its own extension (GL_AMD_debug_output), but the question is if GL_ARB_debug_output is supported.

Both extensions are virtually the same (AMD extension is promoted to ARB). ARB version differentiate source and type of the error, while AMD combines them in a single parameter - category. Also, ARB extension enables synchronous/asynchronous debug output.