Optimize for Thermal

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

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

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:

• Broad brush:
  • Running complex 3D content at native 2560x1440 is often overkill - can you run at 1080p or even 720p?
  • Do you need to run at 60FPS - for complex 3D games a consistent 30FPS is often preferable?
• Fine tuning:
  • Use texture compression and/or reduce resolution, etc as suggested by McGeagh (bandwidth is expensive).
  • One vertex is considerably more expensive than one texel - aggressively optimize geometry meshes (get good locality, good vertex reuse in meshes, remove unused attributes, use fp16 attributes, keep triangle sizes reasoanbly large), and if needed subsitute geometry with meta-geometry techniques such as normal mapping.

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.

HTH,
Pete