Detecting Ghosts

This topic contains 7 replies, has 3 voices, and was last updated by  Dark_Photon 2 years ago.

Viewing 8 posts - 1 through 8 (of 8 total)
  • Author
    Posts
  • #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).

    #51010

    So no tips on tracking down texture ghosting at all?

    #51013

    PaulL
    Admin

    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.

    #51034

    Ok, thanks. If you come up with anything later w.r.t. tracking these down, please let me know!

    #51083

    pauls
    Member

    Hello Dark_Photon,

    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

    #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.

    #51145

    pauls
    Member

    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!
    Paul

    #51149

    Thank you!

Viewing 8 posts - 1 through 8 (of 8 total)
You must be logged in to reply to this topic.