glDebugMessageInsertKHR - Memory leak (PVRVFrame 10.1)

PowerVR Insider
,
1

While making use of the EGL debug context support in PVRVFrame 10.1 (in PowerVR SDK 3.5), I noticed that there was persistent memory growth of ~40MB/sec.

I tracked it down to calling glDebugMessageInsertKHR() in an EGL debug context under PVRVFrame 10.1 (for reference, see KHR_debug). That is, inserting debug markers in the GL object stream under the PowerVR GLES emulator was the cause of the growth. When an EGL debug context is enabled, I call this many times per frame.

Could you please look into this leak and fix it in the next release of PVRVFrame? Debug markers are useful in PVRTrace to cross-correlate GL call sequences with actual code. If you’d like an example .pvrt file with these markers in it, let me know and I’ll upload one

(BTW, I should note: merely creating an EGL debug context and possibly calling glObjectLabelKHR() to assign English-descriptions to OpenGL object handles did not appear to cause persistent memory growth. That’s not too surprising because these don’t involve calls which are made every frame.)

2

Well spotted, thank you. Our PVRVFrame lead is investigating the memory growth now.

3

Thanks!

(I just have to complement you guys. You’re the most responsive GPU vendor development team I’ve ever worked with!)

4

Hi Dark_Photon,

If there’s no debug callback set then messages are pushed onto a message log, so it’s normal for the memory to go up in this case. You can store up to GL_MAX_DEBUG_LOGGED_MESSAGES in the log and they’ll stay there until they’re popped with glGetDebugMessageLog. In PVRVFrame the capacity is 1024 but I think something like 64 is more typical on a real device.

So perhaps what you’re seeing is not actually a leak. You could try setting a message callback to prevent messages from being stored in the log.

5

Thanks for the suggestion, but unfortunately that’s not it. I’ve actually had a message callback set (via glDebugMessageCallbackKHR) since I started using the KHR_debug support. That was the first KHR_debug feature that I added support for.

(My hope was that ImgTech’s GPU drivers were, like NVidia’s, feeding back performance warnings and other useful tips that could be used to optimize our application. So far I haven’t seen any indication PVRVFrame does this though, and the early Rogue 6 GLES drivers on our delivery platform don’t support KHR_debug.)