robust ARB_debug_output example?

[Brandon J. Van Every]

I compiled G-Truc's 4.3.0.0 samples, but the handling of ARB_debug_output is wrong. Somehow GLEW doesn't utilize a debug context and glGetStringi is an insufficient safeguard. It'll say an extension is present, without enforcing the caveat "but only in a debug context." So the app believes GLEW set up glDebugMessageControlARB, but it segfaults. I'm using an NVIDIA GeForce 8600M GT on 64-bit Lubuntu 12.04 Linux, driver version 295.49. glewinfo shows ARB_debug_output as one of these "OK [MISSING]" extensions. I filed a bug about all of this, referring to someone else's discussion of the GLEW problem. I haven't figured out a fix, or even if it can be fixed with GLEW, and I'm bored worrying about that particular sample code.

So, what I'd like is, an example of ARB_debug_output that actually works / is robust. Meaning working buildable code, not a tutorial. Gracefully handles the (likely!) case that the driver doesn't offer the extension unless hurdles A, B, and C are jumped. I'm currently downloading large 3d engine projects to see if their test suites qualify. Do you know of anything that you're sure works? Then at least I can prove that it's not the driver, this is what's supposed to happen, here's an API stack that actually works in the real world, etc.

[thokra]

Leith's report is fairly old. Have you tried a newer version of GLEW(yes, I'm aware you're probably using the dated repository version - but that doesn't prevent you from downloading and building with a newer version) or to get the address of the function yourself with glXGetProcAddress?

[Brandon J. Van Every]

Actually I compiled and installed GLEW 1.9, since I knew that G-Truc's examples had 4.3 code in them, and 1.9 would be necessary. I also saw no evidence of movement on the GLEW debug context issue when I perused the sources and the developer mailing list, so the "old" comment may still be valid. I'm not interested in debugging G-Truc's code anymore. Do you know of any robust, known good, off-the-shelf ARB_debug_output code per my request?

[Alfonse Reinheart]

GLEW has nothing to do with the creation of debug contexts; that's the responsibility of whatever you're using to create your context. All GLEW does is load functions and extensions.

Maybe you're looking in the wrong place. How are you creating your window?

[Brandon J. Van Every]

Please read the links I provided. They lay out the GLEW issues and I don't feel like repeating them. Also, it's not "my" window. I'm asking for known good working code, other than G-Truc's code.

[thokra]

Also, it's not "my" window.

So you stole it? If you want a robust example and don't tell us if you setup your surface and context yourself or if you're using stuff like SDL, Qt, FreeGLUT you can't expect much.

Do you know of any robust, known good, off-the-shelf ARB_debug_output code per my request?

No. But the spec tells you everything you need to know and reading it won't take you long. If GLEW doesn't do, use glXGetProcAddress directly. BTW, what's wrong with groovounet's stuff? Debug output isn't a miracle. Skimming the groovounet's sample I can't say it looks faulty.

On another note, why is it likely NVIDIA's binary blob will fail providing access to the extension? The blob is fast, stable and except for some obvious disregarding the spec it's also pretty reliable.

[Brandon J. Van Every]

So you stole it?

It's someone else's legally licensed code. I've put enough energy into debugging it already. 4 bugs filed, none acknowledged so far. Positive side, the author came out with 4.3 stuff quickly. Negative side, most examples depend on handling ARB_debug_output properly and it simply won't work out of the box on certain drivers. His release notes did say something about "Windows only," but I don't really believe that. All the interfaces build and at least one of the samples actually works. Relevant WGL_* and GLX_* flags have identical numerical values, GLUT is supposed to shield one from that anyways. I think he really means, he's only been testing on Windows. I tried shuffling the GLEW init after all the window create / window destroy / window create dance and that didn't help. So I'm inclined to take that email about the GLEW init problem at face value.

If you want a robust example and don't tell us if you setup your surface and context yourself or if you're using stuff like SDL, Qt, FreeGLUT you can't expect much.

I did tell you. You can download and build the G-Truc sample code same as I can / did. If you want to reproduce the bug I've found, or even fix it, feel free. If you think that sounds boring, well I totally understand. Why do you think I asked for something else?

On another note, why is it likely NVIDIA's binary blob will fail providing access to the extension?

Because the extension says, "For performance reasons it is recommended, but not required, that implementations restrict supporting this extension only to contexts created using the debug flag as provided by WGL_create_context or GLX_create_context." Looks like NVIDIA chose that approach. So apps have to handle the creation and use of debug contexts perfectly, or they'll blow up. Not so easy with GLEW.