• State Accepted Answer
  • Locked Locked
  • Replies 2 replies
  • Subscribers 137 subscribers
  • Views 21755 views
  • Users 0 members are here
Options
Related
How was your experience today?
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Mali texture workload/usage rate issue in Streamliner

JPJ

Hi,

I'm struggling to understand the connection between a spike I'm seeing in the Mali Texture Workload Property Rate and (a) overlapping texture unit utilization and (b) subsequent L2/external reads. There seems to be very little activity texture unit utilization during that spike and L2 and external memory reads I'd expect happen after. I'm probably missing something essential here, so it would be great if you could shed some light on this. I've outlined the spike with a red rectangle, and a red vertical line showing the L2/external reads. This output is from a Mali-G71 (if relevant).

Cheers

Parents
  • +1

    Hi JPJ, 

    The region in the red rectangle is just showing workload property percentage of operations issues, rather than percentage of maximum processing load. In this case that's showing that in that period of time most accesses are compressed and mipmapped, but outside of that period of time none are. This isn't too uncommon - 3D passes nearly always read from lossily compressed textures (ASTC, ETC2, etc) and are nearly always mipmapped. Later render passes tend to read from framebuffers rendered earlier in the frame, which are not lossily compressed or mipmapped.

    The high bandwidth spike under the red line typically indicates one of two things:

    * Render passes which are downsampling an earlier pass (e.g. if you are doing a 2:1 downsample then you need to read 4 texels of input for each pixel of output).

    * Render passes which are accessing a lot of unique textures and/or samplers, so bandwidth is spent loading descriptors rather than just on texture data.

    Given the spike happens immediately after the 3D pass, if I had to guess I'd say it's a downsample pass. Downsampling before post-processing is relatively common, and the spike looks like ~6-8 bytes per read, which fits for 2:1 downsample in each axis reading from a losslessly compressed framebuffer.

    HTH, 
    Pete

Reply
  • +1

    Hi JPJ, 

    The region in the red rectangle is just showing workload property percentage of operations issues, rather than percentage of maximum processing load. In this case that's showing that in that period of time most accesses are compressed and mipmapped, but outside of that period of time none are. This isn't too uncommon - 3D passes nearly always read from lossily compressed textures (ASTC, ETC2, etc) and are nearly always mipmapped. Later render passes tend to read from framebuffers rendered earlier in the frame, which are not lossily compressed or mipmapped.

    The high bandwidth spike under the red line typically indicates one of two things:

    * Render passes which are downsampling an earlier pass (e.g. if you are doing a 2:1 downsample then you need to read 4 texels of input for each pixel of output).

    * Render passes which are accessing a lot of unique textures and/or samplers, so bandwidth is spent loading descriptors rather than just on texture data.

    Given the spike happens immediately after the 3D pass, if I had to guess I'd say it's a downsample pass. Downsampling before post-processing is relatively common, and the spike looks like ~6-8 bytes per read, which fits for 2:1 downsample in each axis reading from a losslessly compressed framebuffer.

    HTH, 
    Pete

Children