Closed NogginBops closed 2 years ago
This function will return the following severity levels to parameter GLuint* severities.
Refer to specification for details -
The GLuint and GLenum are typecasted from unisigned int, so should not be any concerns of conversion from application side. typedef unsigned int GLenum; typedef unsigned int GLuint;
So application will get the Glenum as expected here. The IHV vendors will be returning severity levels as mentioned above.
This is more of a issue is more in relation to #517. I know how the function works and how it's not a problem in c. But it's a problem in many bindings generators for other programming languages.
I suggest trying to contact Jaakko Konttinen, who is listed as the extension contact. I believe they're still at AMD, 12 years on. I am fairly sure none of the other listed contributors to the extension are still at AMD but if you can't reach the contact, we can ask around inside Khronos to see if anyone at AMD feels ownership over this extension.
We have approved extension - GLARB debug_output.txt https://www.khronos.org/registry/OpenGL/extensions/ARB/ARB_debug_output.txt
which has listed these parameters to enum severities. uint GetDebugMessageLogARB(uint count, sizei bufSize, enum sources, enum types, uint ids, enum severities, sizei lengths, char* messageLog);
We have discussed this in working group, and we dont have issues to keep it to GLuint or change to GLenum severities.
To be clear, the WG doesn't have an issue with the GL_AMD_debug_output extension changing from GLuit to GLenum if that's acceptable to AMD.
Yes, this is acceptable to AMD.
The function
GetDebugMessageLogAMD
fromGL_AMD_debug_output
is defined as follows:Shouldn't the
severities
argument be of typeGLenum
? This would match every other definition of this function from other extensions.As they are
typedef
ed as the same type is it possible to change this?