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.
- 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).[/quote]
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.
- 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 :)[/QUOTE]
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).
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.
please implement KHR_debug
For Windows and Linux please. I checked out KHR_debug on Windows with an NVIDIA GPU (due to Ubuntu lacking the GL 4.3 beta blob on Linux as of yet) a few days ago and the messages are quite informative regarding stuff like invalid enums and such. However, you get bombarded with the error each frame if you just use the callback. If there are any ways to keep the info around while being able to manage the flood of messages please tell.
I want to add another item to the wish list: redundant state changes. gDEBugger tracks it, so could the driver and spit out the command, possibly some info on the arguments and the current state to get a clue of where the call was possibly made.
Also, I noticed that KHR_debug on NVIDIA informs of a
if you call glUseProgram() and some stages could not be compiled or linked - as the quote says. I noticed that when a geometry shader was accidentally attached but didn’t have any source and thus could not be compiled.
So, to summarize my personal wishlist:
[li]info on pipeline stalls, maybe as a ratio or even more informative if possibly (performance) [/li][li]info on redundant state changes (performance) [/li][li]info on shader program correctness (debug) [/li][/ul]
Thanks everyone for suggestions, I will pass them to OpenGL dev team and we will see what we can do