I’m hunting ghosts. Not the paranormal type. The PowerVR driver type. Since there is a performance cost associated with the creation and cloning of these hidden textures, and these can cause us to blow our GPU memory budget, I’d like to track these down and get rid of them.
What tools does ImgTech provide its users to tell them exactly when a ghost was created? Or, to query how many ghosts have been created since the application was started (which could be used to track them down)? Anything?
And if I were to profile for ghosts, what should I look for: excessively long texture update or FBO RTT buffer set calls (e.g. glTexSubImage2D or glFramebufferTexture2D)?
(By the way, I searched all of the PowerVR architecture guides, user manuals, specs, and whitepapers, and came up with 0 references for ghosts. And for readers that have no idea what I’m talking about here, see this).
Thanks Paul! This is great info – I’ll save this off.
The GL_VERSION string for our PowerVR drivers is:
[ul]OpenGL ES 3.0 build 1.2.WINEC7@2829345[/ul]
and it doesn’t report KHR_debug as supported. …that said, we’ve hit situations before where some extensions are supported but not advertised. Do you think there’s a possibility of that here (v1.2, so maybe not)?
Also, it would be really helpful if a future PVRVFrame release emitted these same KHR_debug ghosting/performance tips (simulating the PowerVR drivers’ “I need to ghost or block here” logic). Then folks developing software on desktop/Win32 for PowerVR chips could get early and immediate feedback during dev testing when they’ve coded up something that will hurt performance on PowerVR GPUs. It would also point directly to problem operations in the code when running on desktop (via PVRTrace output, or even better, breakpoints in the code in the message callback).
Better for devs. Better for maximizing performance on ImgTech PowerVR GPUs. I think this’d be a win-win.