GL_ARB_Debug_Output - what do you need ?
If you could talk with Graphic Drivers Developers about GL_ARB_Debug_Output extension, what type of messages you would ask them to be printed out by driver? What use cases should this extensions consider? What debug messages would be most important for you?
Please write concrete use cases, all suggestions will be taken into notice!
More info about extension itself:
If you could talk with Graphic Drivers Developers[..]
Are you among these elite few?
Yes, I am, and I want to make your life easier
May we ask what company is about?
Currently many gl functions generate a single error like GL_INVALID_ENUM for several error conditions. Any additional information that could clarify the error would be useful.
To be honest the most useful thing to me would be a symbolic debugger for shaders
@Aleksandar: I'm working at Intel on our graphic drivers.
@tonyo_au: Thanks for sharing some info with us.
I'm encouraging everybody to give more examples!
Here's my short list that I'd like to see these adopted by all GL implementers:
- Performance warnings: There seems to be quite a few more caveats with Intel GPUs than with discrete GPUs, such as which texture formats are actually HW-accelerated. I've seen this getting better throughout the generations, but any that are still suboptimal or unsupported should have an message stating this, plus maybe a suggested alternate format (eg, use 8b BGRA instead of 8b RGBA).
- If Intel supports GL_ARB_debug_label, please integrate the debug label into any messages about a particular object that has a label set. If this isn't supported, please add support for it
- Nvidia's latest driver reports GL errors quite nicely. For example, "GL_INVALID_ENUM error generated. TexImage: invalid <target> enum value."
If possible, at percentage of stalling would be nice to see as a ration between (time in stall) / (time at work).
While we're at it, do you know how geometry shaders going for the Gallium driver?
Anything to help analyzing TDRs under Windows. It need not even be Windows-specific; if the display driver hangs and if it was something I did that caused it, I'd like to know what.
GL_INVALID_OPERATION errors generated by rendering commands are exceedingly difficult to track down. They can be caused by a large number of factors. You should make it abundantly clear exactly what state, objects, state within those objects, etc needs to be looked at.
Also, always name the function when you spit out an error.
Technically, ARB_internalformat_query2 should cover these cases; you can query the preferred pixel transfer format and so forth. But if they're not able to implement it yet, then yes, I agree we should get performance warnings for it.
Originally Posted by malexander
Small point: there is no GL_ARB_debug_label. It was a preliminary extension, which was folded into KHR_debug (ie: it's all one big debugging extension now).
Originally Posted by malexander
Oh, and on-topic: Intel, please implement KHR_debug
Speaking of KHR_debug, use the debug names for objects whenever possible in your debug messages.
Last edited by Alfonse Reinheart; 09-20-2012 at 09:39 AM.