• State Accepted Answer
  • Locked Locked
  • Replies 2 replies
  • Subscribers 137 subscribers
  • Views 8126 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

Midgard shader cycles outside TriPipe

JPJ

Hi,

I'm looking at some limited data captured on Streamline (due to the device making only a few counters available - GPU: Mali-T720). When looking at the Mali Shader Cycles, although the large part of the time is spent on TriPipe cycles, there's parts where it's not. Where could these cycles be spent?

Cheers!

Parents
  • +1

    Hi JPJ, 

    You have three behaviors I can see here:

    • There is some ramp time at the start and the end of the rendering. The ramp here is somewhat artificial - it's just an artifact of the fact that we only have a 1ms sample rate, so you get interpolated values for things that are only active for a fraction of a time slice. 

    • You get some dip between the vertex and fragment stages. This stage handover is managed in software, scheduled though the kernel driver, so there will always be some small dip while that CPU work gets schedule, unless there is another render pass running in parallel which can hide the bubble. 

    • The dips ~60% of the way though don't seem related to CPU scheduling (tri-pipe drops, but the fragment cycles doesn't). This is usually indicative of tiles containing no shading workload. This normally caused by depth shadow maps, where tiles are either empty (no shadow casters) or have depth values that can be resolved entirely at early-zs without running a shader program (common case for opaque geometry).


    Cheers, 
    Pete

Reply
  • +1

    Hi JPJ, 

    You have three behaviors I can see here:

    • There is some ramp time at the start and the end of the rendering. The ramp here is somewhat artificial - it's just an artifact of the fact that we only have a 1ms sample rate, so you get interpolated values for things that are only active for a fraction of a time slice. 

    • You get some dip between the vertex and fragment stages. This stage handover is managed in software, scheduled though the kernel driver, so there will always be some small dip while that CPU work gets schedule, unless there is another render pass running in parallel which can hide the bubble. 

    • The dips ~60% of the way though don't seem related to CPU scheduling (tri-pipe drops, but the fragment cycles doesn't). This is usually indicative of tiles containing no shading workload. This normally caused by depth shadow maps, where tiles are either empty (no shadow casters) or have depth values that can be resolved entirely at early-zs without running a shader program (common case for opaque geometry).


    Cheers, 
    Pete

Children