Detecting Ghosts (part 2)

This is a follow-on question to this thread:
[ul][li]https://www.imgcommunity.local/forums/topic/detecting-ghosts/[/li][/ul]

We have a set of textures we redraw using FBOs. We’d like to be sure that the driver doesn’t ghost them.

If we issued a sync object after each read submitted for one of these textures, and then on submitting a write request checked whether the most recently-submitted sync object for that texture was signaled, would that be a valid test for ghost creation?

(This is in absence of a PowerVR driver or emulator that warns on ghost creation, in an attempt to emulate this.)

Thanks.

Hi Dark_Photon,

[blockquote]We have a set of textures we redraw using FBOs. We’d like to be sure that the driver doesn’t ghost them.[/blockquote]
The driver will only ghost textures that are modified by the CPU. Ghosting will not occur for FBOs, as the GPU can ensure that the draw operations for render pass A are completed before render pass B reads pass A’s attachment data.

Hope this helps,
Joe

[blockquote]The driver will only ghost textures that are modified by the CPU.[/blockquote]

Thanks Joe! That’s good news. That obviates some work we were thinking about doing.

However, could we used the described technique to detect ghosting instigated by CPU updates?

That is:

  1. Use a sync object to track the last read request for a texture through the pipeline.
  2. Then when we request a write for that texture, check whether the sync object associated with that last read request was signaled.
  3. If not flag a “Texture %d was ghosted” warning.

Thanks.

Hello Dark_Photon,

I think what you describe makes sense.

My understanding from what you describe:

  1. Make a fence on the render reading/writing the texture on GPU (pipeline) side. Aim to add this fence at swapbuffers stage to avoid unnecessary TA kicks.
  2. Check this fence before modifying the texture on the CPU
  3. Either wait for it to finish (wait on fence + performance cost) or risk the chance of ghosting by modifying it (memory loss).

Thanks,
Paul

I appreciate you getting back to me on this, Paul. Will put this in the queue to implement.