Hi,
I'd like to know ways to profile for thermal. Our game performance is reasonable in a S6 but it overheats in a fews minutes. Is there an api to trottle CPU/GPU or a tool to profile the operations that are contributing more to overheat.
Hi philira,
The ability and location of changing the processor clocks (throttle the CPU/GPU) is not controlled by us, but the SoC vendor.
As I have an S6 with me, here is what you can find from probing the /sys/ filesystem:
/sys/devices/14ac0000.mali/ asv_table clock core_availability_policy core_mask debug_level down_staycount driver dvfs dvfs_governor dvfs_max_lock dvfs_max_lock_status dvfs_min_lock dvfs_min_lock_status dvfs_table gpu_status highspeed_clock highspeed_delay highspeed_load hwcnt_bt_state hwcnt_dvfs hwcnt_gpr hwcnt_tripipe misc modalias norm_utilization perf polling_speed power power_policy power_state subsystem time_in_state tmu trace_dump trace_level uevent utilization utilization_stats vol wakeup_lock
/sys/devices/14ac0000.mali/
asv_table
clock
core_availability_policy
core_mask
debug_level
down_staycount
driver
dvfs
dvfs_governor
dvfs_max_lock
dvfs_max_lock_status
dvfs_min_lock
dvfs_min_lock_status
dvfs_table
gpu_status
highspeed_clock
highspeed_delay
highspeed_load
hwcnt_bt_state
hwcnt_dvfs
hwcnt_gpr
hwcnt_tripipe
misc
modalias
norm_utilization
perf
polling_speed
power
power_policy
power_state
subsystem
time_in_state
tmu
trace_dump
trace_level
uevent
utilization
utilization_stats
vol
wakeup_lock
As you can see, you have the visibility of the GPU frequencies, among a lot of other useful things, on the S6 device.
However, you cannot modify these files, unless you have root access to the device.
Android is not designed in a way to let a standard (non-rooted) application to change frequencies, and with good reasons.
The same goes for the CPU:
/sys/devices/system/cpu/ cpu0 cpu1 cpu2 cpu3 cpu4 cpu5 cpu6 cpu7 cpufreq cpuidle kernel_max modalias offline online possible power present uevent
/sys/devices/system/cpu/
cpu0
cpu1
cpu2
cpu3
cpu4
cpu5
cpu6
cpu7
cpufreq
cpuidle
kernel_max
offline
online
possible
present
Please note that not all devices will have these sysfs entries in the same location, if at all. They do not exist for standard applications to modify.
Regarding your original question related to how to reduce thermal throttling, and assuming you do not have access to the processor frequencies, then the main cause for heat in a mobile device is bandwidth.
If you can reduce bandwidth in your application, this should help. Tools such as ARM DS-5 Streamline do have the ability to profile the bandwidth and let you know whether this is a concern for the particular device you are running it on. Note that each device will have a different limit regarding bandwidth.
Ways to reduce bandwidth can be found in our optimisation guide, for example one method I can suggest to do this is to use ASTC. This gives incredible reduction in bandwidth while still retaining excellent image quality, and can be applied to just about every texture format your application can possibly have.
We at ARM feel very strongly about not just low power, but thermal limits, and particularly in the GPU, we do a lot to help reduce bandwidth. To name a few, Transaction Elimination and AFBC all help with this problem.
I hope that helps you understand what you can do to help alleviate your thermal constraints.
If you have any further questions, feel free to ask them!
Kind Regards,
Michael McGeagh
tool to profile the operations that are contributing more to overheat.
On the whole the thermal load is purely a function of workload - every Watt of power into the GPU has to comes out as heat, and if your load is sufficiently high to push up the GPU operating frequency then your voltage goes up (energy efficiency per operation is proportional to V^2) which exacerbates the problem. Also remember that device battery life and heat are basically coupled, so if your game is getting the device really warm then you are also sucking the battery down pretty fast, so reducing load can improve play times between charges.
There are some differences in energy cost - texturing is more expensive than a simple maths operation, for example - but on the whole thermal issues just come down to trying to do too much in a mobile form factor (GPUs inside sealed boxes with no airflow are in a pretty unforgiving thermal environment). Things to consider:
HTH, Pete
Hi mcgeagh and peterharris,
Thanks for this insightful reply. +1 for the reference to the optimisation guide.
Just out of curiosity.
1) Oculus VR api allows to set cpu/gpu levels. How does it do?2) As long as I use mipmapping, texture resolution won't matter for bandwidth ok? (since the lower resolution mips will account to improve memory access locality). The problem with large texture would be the space they would take in VRAM memory. is that correct?
1) Oculus VR api allows to set cpu/gpu levels. How does it do?
There is no standard API for GPU frequency control (i.e. nothing like CPUFreq on Linux), so presumably this is a platform specific part of their stack which must be ported to target a specific device.
2) As long as I use mipmapping, texture resolution won't matter for bandwidth ok? (since the lower resolution mips will account to improve memory access locality). The problem with large texture would be the space they would take in VRAM memory. is that correct?
It's certainly a "good thing" to use mipmaps - both for bandwidth and visual quality - but your choice of largest level can impact bandwidth especially if you are rendering on devices with very high resolutions - i.e. the mipmap selection is impacted by the ratio of texel size to pixel size, so smaller pixels mean you need smaller texels.
If a game has a mipmap chain which is 512x512, 256x256, .... then it may well be lower bandwidth than a mipmap chain which is 1024x1024, 512x512, .... simply because that 1024x1024 level may get used in places where the 512x512 level was used in the original case and will be 4x the bandwidth cost. For pixels which are using samples from L1 or below (256x256) in the original case, then you are correct - it won't make any difference.