c++ - glDebugMessageCallback 更详细的信息

Question

我到处都读到 glDebugMessageCallback 是解决错误的更好解决方案，所以我实现了它。到目前为止，一切都很好。我确实得到了关于正在发生的事情的更详细信息。目前在 NVIDIA 上看起来是 f.e.像这样:

DebugLog: In source API, type OTHER, id 131185, severity : NONE,message Buffer detailed info: Buffer object 3 (bound toGL_VERTEX_ATTRIB_ARRAY_BUFFER_BINDING_ARB (0), andGL_ARRAY_BUFFER_ARB, usage hint is GL_STREAM_DRAW) will use VIDEOmemory as the source for buffer object operations.

真的很好，确实 - 但是，我错过了一件事 - 我不能在这里指出这到底发生在哪里。

如果我将旧式方法与这样的宏一起使用:

#define CHECK_GL_ERROR() CheckGLError(__FILE__, __LINE__)和glGetError()

它远没有那么详细，代码也很乱——但是!我可以更轻松地追踪到线路或称它发生了，至少在调试自己时是这样。

当然，如果我将日志级别降低到更严重的程度，可能也更容易识别来源，因为有问题的功能较少，但是，根据代码，我发现找到特定的代码有点不精确功能。

所以我现在的问题是 - 有没有办法告诉回调到底触发了什么，函数或者代码中的行，就像在旧方法中一样(也就是说，现在不添加手动断点/调试) ??

我会发现这非常方便，特别是考虑到这样一种情况，即可能只是使用该软件的人可以仅为我无法重现的问题向我提供日志。

PS:有人能告诉我“id”是什么意思吗？我找到了很多教程和解释，也阅读了文档，但我仍然看不出调试有什么用。

Answer 1

有两种方法可以帮助您确定错误的来源:

首先，您可以glEnable(GL_DEBUG_OUTPUT_SYNCHRONOUS) 确保在产生错误的函数范围内抛出错误。当您现在在错误回调函数中设置断点时，您将通过调用堆栈查看错误的来源。

第二:OpenGL 允许您将名称和范围与每个 OpenGL 对象相关联。这允许您指定名称，比方说，一个缓冲区。看看here了解更多详情。