The StreamLine for G76 calculate overdraw with ($MaliCoreWarpsFragmentWarps * 16) / ($MaliCoreTilesTiles * 256), and Mali Pixels with $MaliGPUTasksFragmentTasks * 1024.
$MaliGPUTasksFragmentTasks means that the number of 32x32 pixel tasks processed by the GPU fragment queue. $MaliCoreTilesTiles means that The number of tiles processed by the shader core. And$MaliCoreWarpsFragmentWarps means the number of fragment warps created.
I want to know what the difference between these three and these. Thanks.
Hello, I moved this question to the Graphics forum, where you are more likely to get a response.
The "Mali Pixels" counter is the total number of pixels produced by the GPU. The $MaliGPUTasksFragmentTasks counts the total number of 32x32 pixel regions shaded by the GPU in each sample period, so we just scale this counter by 1024 to get the pixel count.
The "Overdraw" counter computes the number of shaded fragments per pixel. For this we need to know the number of fragment threads ($MaliCoreWarpsFragmentWarps * 16) and the number of pixels (estimated as $MaliCoreTilesTiles * 256) because Mali tiles are (normally) 16x16 pixels each. For tool implementation reasons these are computed as per-core metrics, which is why a different computation of pixels is used than the "Mali Pixels" above.
It would be equally valid to do ($MaliCoreWarpsFragmentWarps * 16 * $MaliConstantsShaderCoreCount) to get a total number of fragment warps for the whole GPU, and then divide by ($MaliGPUTasksFragmentTasks * 1024). We actually start to compute overdraw this way for the newer GPUs, because tile size is more variable so using number of tiles as a proxy for the per-core pixel count is no longer accurate.
Thank you for your reply!
And I have another question.
Can I calculate Overdraw by($MaliCoreWarpsFragmentWarps * 16 * $MaliConstantsShaderCoreCount / resolution / fps)?
In my example, my phone‘s screen resolution is 1080*2340, but the render buffer size is 720*1560 on Graphics analyzer. If the above formula works, what does the resolution use?
Not really; you need to know the number of pixels in each sample in Streamline, which is variable because pixels are not uniform complexity.