Part of the Khronos Group
OpenGL.org

The Industry's Foundation for High Performance Graphics

from games to virtual reality, mobile phones to supercomputers

Page 1 of 2 12 LastLast
Results 1 to 10 of 12

Thread: GL_ARB_Debug_Output - what do you need ?

  1. #1
    Junior Member Newbie
    Join Date
    Apr 2009
    Posts
    28

    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:
    http://www.opengl.org/registry/specs...bug_output.txt

    Thanks,
    Karol

  2. #2
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,128
    If you could talk with Graphic Drivers Developers[..]


    Are you among these elite few?

  3. #3
    Junior Member Newbie
    Join Date
    Apr 2009
    Posts
    28
    Yes, I am, and I want to make your life easier

  4. #4
    Senior Member OpenGL Pro Aleksandar's Avatar
    Join Date
    Jul 2009
    Posts
    1,145
    May we ask what company is about?

  5. #5
    Senior Member OpenGL Pro
    Join Date
    Jan 2012
    Location
    Australia
    Posts
    1,117
    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

  6. #6
    Junior Member Newbie
    Join Date
    Apr 2009
    Posts
    28
    @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!

  7. #7
    Member Regular Contributor malexander's Avatar
    Join Date
    Aug 2009
    Location
    Ontario
    Posts
    319
    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."

  8. #8
    Senior Member OpenGL Pro
    Join Date
    Apr 2010
    Location
    Germany
    Posts
    1,128
    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?

  9. #9
    Senior Member OpenGL Pro
    Join Date
    Jan 2007
    Posts
    1,201
    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.

  10. #10
    Senior Member OpenGL Guru
    Join Date
    May 2009
    Posts
    4,948
    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.

    Quote Originally Posted by malexander View Post
    - 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).
    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.

    Quote Originally Posted by malexander View Post
    - 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
    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.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •