Issues

Issue #607 resolved

Utilize GL_KHR_debug to provide meaningful runtime optimization & use suggestions

Alex Szpakowski
created an issue

It would be really cool to use the functionality of the OpenGL KHR_debug extension (also part of core OpenGL 4.3) to output hints/tips/debug information to lovers, with the ability to toggle it on and off.

This would only work well if the information made available can reliably be filtered into something useful to lovers (messages about the use of deprecated OpenGL functionality won't help anyone except for LÖVE developers, for example).

It should also be noted that KHR_debug is very new and only supported on modern nvidia drivers currently, as far as I know. ARB_debug_output also exists and is slightly more widely supported, but it's a subset of KHR_debug and requires an explicit debug OpenGL context to be created, which would have to be hacked into the LÖVE window creation code.

Comments (8)

  1. vrld

    Seconded. Maybe it's also possible to use KHR_debug where available and fall back to ARB_debug_output where it isn't.

  2. Alex Szpakowski reporter

    SDL2 supports creating a debug context without any hackery (provided the system/drivers support it as well). According to the KHR_debug spec, implementations technically aren't required to provide debug information if a debug context isn't created, so it would be a good idea to do that even when KHR_debug is supported.

    I believe KHR_debug has more functionality than ARB_debug_output for providing "pretty" names for things.

  3. Alex Szpakowski reporter

    Status update: AMD has beta drivers which now support KHR_debug and ARB_debug_output. Older AMD drivers have AMD_debug_output but its API is a little different and the messages it produces are more limited.

    The Mesa driver in Linux supports ARB_debug_output. Unfortunately Mac OS 10.9 does not (for now.)

    Due to the fact that the content of debug messages varies widely between all vendors, I don't think it makes sense to "parse" the messages into something very lovely. Combined with the fact that internal LÖVE code can/will trigger debug messages, I almost feel like this would be better as an internal LÖVE development thing rather than an external API.

    Perhaps a sweet spot could be found where only certain debug messages are enabled
    for lovers, but LÖVE developers can choose to have more.

    I made a test implementation a little while ago, but it's not exactly pretty.

  4. Jason McKesson

    it's a subset of KHR_debug and requires an explicit debug OpenGL context to be created, which would have to be hacked into the LÖVE window creation code.

    Technically, KHR_debug is not require to work at all if you don't use a debug context. Yes, the functions will be there, but they aren't required to actually do anything. Such as report errors and the like.

    I agree that it doesn't really make sense to expose rendering debug messages to users.

  5. Log in to comment