This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Mali hw counters not matching Streamline's built-in Mali Bifrost G71 profile

Hi,

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?

Thanks,

Lorenzo

PS: I am attaching some screenshots that show the problem:

  • Hi Lorenzo, 

    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. 

    Cheers, 
    Pete

  • 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.

    Cheers, 
    Pete

  • 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.