I'm trying to validate the frame rate I'm seeing in my streamline capture. I have annotated my code to show when data processing occurs every frame so that I can measure it in the timeline, but I want to make sure the number of cycles per pixel makes sense. For example, my 4 core GPU is running with a 1 GHz clock, 4000 M cycles/second, and I have a frame that I am drawing with a 1280x800 resolution. It looks like I'm seeing a frame rate of about 250 Hz which means that 4000 M cps/((1280x800pixels)x250) = 15.625 cycles/pixel as my budget. When I look at the counters in the GPU Counter reference guide I see Pixels shaded by the GPU as $MaliGPUTasksFragmentTasks * 1024.see: https://developer.arm.com/documentation/102626/0100/?lang=en#md457-mali-g78-performance-counter-reference__gpu-activityI also see the cycles per pixel as: $MaliGPUCyclesGPUActive / ($MaliGPUTasksFragmentTasks * 1024) in the same document.When I look at these over a frame time in streamline I get the number of pixels as 4.419M and the Cycles per pixel as essentially 1.
Questions:1. Where does the 1024 come from when calculating the Pixels? Also how does this relate to my number of pixels per frame which is around 1/4 of this?2. The number of cycles per pixel is much lower than the budget, but is this even correct? (not incredibly experienced with video sw)Any help is appreciated.Thanks!
andyostler said:Where does the 1024 come from when calculating the Pixels?
The counter counts tasks, and each task covers a region that is 64x64 pixels in size.
andyostler said:Also how does this relate to my number of pixels per frame which is around 1/4 of this?
This counts the total number of rendered pixels (render-to-texture, as well as render to final swapchain image). If this doesn't match, are you sure you are measuring what you think you are?
andyostler said:The number of cycles per pixel is much lower than the budget, but is this even correct?
As above the cost in Streamline includes all pixels (render-to-texture and screen), so you need to factor in the number of render-to-texture pixels you are rendering each frame too.
HTH, Pete
thank you for your reply, this is very helpful! Can you explain what the difference between those two types of rendered pixels is?
For some applications each frame is constructed using multiple rendered images, only the final one making it to the screen. Pixel count measured by the hardware counters is the sum of everything, not just the final output image.
Thank you. do you know if there is some way to validate frame rate we are seeing based on the resolution and clock speed?