With a support entitlement you can also get direct access to our team of highly-qualified Arm experts 24-hours a day
Open a support case
I am using Streamline 6.8.0, with gator daemon on a non-rooted Samsung Galaxy S8 Exynos. Streamline is connecting and capturing correctly, and I am trying to use the built-in Bifrost G71 profile, as I was used to do with the Midgard ones on S7.
Unfortunately, many of the pre-configured charts have a warning that they cannot find the corresponding counter. (I have tried all of the available ones).
Is it possible that counters have changed names? Is there an updated Streamline profile that I could use?
PS: I am attaching some screenshots that show the problem:
With the currently shipping drivers user-space gatord doesn't support the GPU Utilization charts unfortunately; these are only available when using gatord alongside the gator.ko kernel-space integration. This is fixed on the last driver release, as we've added support to expose this information to user space, but we have no control over when/if this update will land on shipping devices.
Thanks! Would it be fair to add a chart using Fragment Cycles / GPU cycles as an indication of the "Fragment Activity" ?
Hi Lorenzo,It depends what you want to measure."Fragment Cycles / GPU Active Cycles" gives you a percentage of the GPU workload which is running fragment processing, but the GPU may still be idle a lot of the time so still underutilized."Fragment Cycles / TARGET_GPU_FREQ", where TARGET_GPU_FREQ is a statically defined constant you'll need to choose yourself, will give you a feel for how much GPU headroom you have spare (or whether you are over-using). The trick to make this work in the Streamline charts is the $ZOOM built-in variable which contains the current GUI zoom level bin size in seconds, so if you have an 400MHz GPU target your expression would be one of:
$MaliJobManagerCyclesGPUCycles / (400000000 * $ZOOM) * 100
$MaliJobManagerCyclesVertexTilignComputeCycles / (400000000 * $ZOOM) * 100
$MaliJobManagerCyclesFragmentCycles / (400000000 * $ZOOM) * 100
Each of these returns a percentage where 100% would indicate you are using all of the available performance at the target frequency, less than 100% indicates you have spare performance, and more than 100% indicates that you are over-using vs your target.
That's a great way of doing it. I did not know the $ZOOM built-in variable, that will change my game.
On the device I have, I can find the max frequency of the GPU like this:
dreamlte:/ $ cat /sys/devices/platform/13900000.mali/asv_table
GPU, vol, min, max, down_stay, mif, int, cpu
546, 662500, 78, 99, 5, 1794000, 400000, 1690000
455, 650000, 78, 85, 9, 1540000, 400000, 1456000
385, 643750, 78, 85, 1, 1352000, 400000, 1248000
338, 637500, 78, 85, 1, 1014000, 267000, 949000
260, 637500, 78, 85, 1, 421000, 178000, 0
I guess the max frequency could be lowered by the system in certain situations like thermal throttoling, but that's probably as good as it gets.