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).
On newer drivers (1.4+) we do insert messages into KHR debug for ghosting.
The message for texture ghosting will be:
“The Texture is being modified by a glTex[Sub]Image*() or glTexStorage*() while it is still in use somewhere, such attempts introduce performance penalty”
For VBO ghosting it will be:
“The Buffer Object is being modified while it is still in use somewhere, such attempts introduce performance penalty”
In most cases we stall for VBO modification instead and there will not be a message.
Note that the performance cost of KHR debug and platform differences will all affect ghosting.
Please let me know the GL string for your test platform so I can check your driver revision will have the correct messages.
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.
I can only suggest using a Nexus Player with 1.4+ drivers. This may not be suitable given the platform will behave differently.
I believe we could cover some of these cases as PVRTrace static analysis rules. I will discuss your PVRVFrame/PVRTrace suggestions with the team. I agree it would help developers avoid costly paths.
