- December 31, 2014 at 9:10 pm #31921
On PVRVFrame 3.3, KHR_debug is advertised. However, eglGetProcAddress( “glDebugMessageCallbackKHR” ) fails (returns a NULL pointer). Same thing with eglGetProcAddress(“glDebugMessageCallback” ), even though that’s not the name for a KHR extension function.
Digging into PVRVFrame 3.3’s libGLESv2.dll for clues, I find “_glDebugMessageCallback@8” (i.e. “glDebugMessageCallback()”, with C naming and an explicit stdcall calling convention: i.e. __declspec(dllexport) void __stdcall)).
So why can I not query this function with eglGetProcAddress() using PVRVFrame 3.3?
As an aside, I note that in the PVRVFrame 3.4 libGLESv2.dll, the glDebugMessageCallback() is C++ name-mangled (“?glDebugMessageCallback@@YGXP6GXIIIIHPBDPBX@ZPAX@Z”). What’s going on there?January 5, 2015 at 11:39 am #39307
This is a bug caused by a disagreement between EGL and GLES with regards to the ‘KHR’ suffix.
Unfortunately I don’t think we have a workaround for aquiring the function pointers but it will be fixed in the next release. We’ve also added visualizations to the GUI for debug groups and stuff and generally given KHR_debug some overdue attention.