ARM Mali 400 performance analysis using the DS-5 Streamline

As I said before, Streamline isn't going to help answer questions about idle time. It's a performance profiler - you can't profile "nothing running" - all of the counters are zero.

The cause of (1) and (2) are probably the same thing. Serialization means idle time and things not overlapping.

Usual suspects:

• Window system fences for framebuffers not being released by the previous user of the buffer (normally the display controller or compositor).
• Vsync and less than 3 framebuffers buffers
• Application CPU load is too high (e.g. CPU limited) - doesn't look like it in your case
• Application calling sleep()
• Application using glFinish, glReadpixels, or waiting on an OpenGL ES level synchronization primitive and draining the rendering pipeline.

Less likely suspects:

• Kernel not processing interrupts quickly enough (e.g. another driver is disabling IRQs, and not re-enabling them for a long time).

HTH,
Pete

As I said before, Streamline isn't going to help answer questions about idle time. It's a performance profiler - you can't profile "nothing running" - all of the counters are zero.

The cause of (1) and (2) are probably the same thing. Serialization means idle time and things not overlapping.

Usual suspects:

• Window system fences for framebuffers not being released by the previous user of the buffer (normally the display controller or compositor).
• Vsync and less than 3 framebuffers buffers
• Application CPU load is too high (e.g. CPU limited) - doesn't look like it in your case
• Application calling sleep()
• Application using glFinish, glReadpixels, or waiting on an OpenGL ES level synchronization primitive and draining the rendering pipeline.

Less likely suspects:

• Kernel not processing interrupts quickly enough (e.g. another driver is disabling IRQs, and not re-enabling them for a long time).

HTH,
Pete

Thanks Peter Its useful information