Dear ARM forum,
I am using the DS-5 Streamline to analyze my application performance on ARM MALI 400.
I am seeing that, GPU vertext processor activity for 3 milliseconds followed by a in-active period of 13 milliseconds then followed by 34 milliseconds GPU pixel proessor activity.
Questions:
1. I am trying to under stand , why there a so much of in-active period? How can I analyze this period for the performance impact?
2. Streamline has provided many performance measuring events, but there is a very poor documentation on , what is this event capturing and how to make use of it for GPU performance analysis?
3. I want to measure the GPU Vertex processor performance in - How many triangles it is processing in one frame, how much time it consumed for that.
GPU Pixel processor performance in - How many pixels processed in one frame,how much time it consumed for that.
4. Is there a document to discuss on analyzing all the events for performance analysis.
Thanks,
Ravinder Are
GPU vertex processor activity for 3 milliseconds followed by a in-active period of 13 milliseconds then followed by 34 milliseconds GPU pixel processor activity.
If you are debugging the inactive period, why do you think the GPU performance counters are going to help? If the GPU is inactive, then by definition all of the GPU counters will be zero for that period ...
Assuming you are running on something like Android, the most likely reason for a long idle delay is that the driver is waiting for a framebuffer fence from SurfaceFlinger. The GPU can run vertex processing early, because it doesn't need a buffer to render into, but can only render into the framebuffer when the fence is signaled by the window system (otherwise we may corrupt a buffer which is still being scanned out on to the screen).
This incoming fence is outside of the Mali driver's control, so check that your system is correctly configured with triple buffering, and that your display controller or compositor stack is correctly signalling fences.
HTH,
Pete