- September 24, 2015 at 12:35 pm #50946
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).October 2, 2015 at 12:37 am #51010
So no tips on tracking down texture ghosting at all?October 2, 2015 at 10:51 am #51013
Apologies that none of us got back to this one for so long. Currently there aren’t any recommendations regarding ghosting.
I believe PaulS was looking into a more complete answer other than a flat ‘no’, but he has been especially swamped with other support duties recently.October 5, 2015 at 6:17 pm #51034
Ok, thanks. If you come up with anything later w.r.t. tracking these down, please let me know!October 6, 2015 at 5:42 pm #51083
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.
PaulOctober 7, 2015 at 2:00 pm #51091
Thanks Paul! This is great info — I’ll save this off.
The GL_VERSION string for our PowerVR drivers is:
- OpenGL ES 3.0 build 1.2.WINEC7@2829345
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.October 7, 2015 at 5:11 pm #51145
Unfortunately 1.2 does not support KHR_debug.
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.
Thank you for your feedback!