Compressed but not mipmapped data (Streamline capture)

Hi guys,

I'm trying to narrow down the texture usage of a frame. Essentially, at the tail end of the frame I'm seeing a fair bit of compressed but NOT mipmapped texture data. Is it possible this is framebuffer compressed data used by post-processing? If so, it's safe to assume that fragment operations performed during that time are all post-processing related, am I correct? 

Cheers.

P.S. - Hope you're all coping well with the current work restrictions ..

This is from a Mali-G71 GPU

Parents
  • Hi JPJ, 

    Compressed in this case means some form of lossy offline compression at the API level (ETC, ETC2, ASTC). This could be post processing, if that is reading from a compressed API texture, but a lot of post passes only read from framebuffers which won't show up in this counter (even if they are compressed with our AFBC lossless compression). 

    HTH, 
    Pete

Reply
  • Hi JPJ, 

    Compressed in this case means some form of lossy offline compression at the API level (ETC, ETC2, ASTC). This could be post processing, if that is reading from a compressed API texture, but a lot of post passes only read from framebuffers which won't show up in this counter (even if they are compressed with our AFBC lossless compression). 

    HTH, 
    Pete

Children
No data
More questions in this forum