By definition, mobile application scenarios must be power efficient. The reason for this is simple: they run from a battery. The target is to allow a consumer to enjoy the full functionality of a device for as long as possible from a single charge. This means that any usage scenario must be practical and useful, and not just something which burns through battery life thus leaving an unhappy consumer carrying around an unusable device.
In terms of mobile GPU compute, any compute scenario must be a practical, useful GPU compute scenario. The key characteristics explained in my previous article immediately come to mind: only consider tasks suitable for the GPU. This ideally means parallel compute tasks with minimal divergence and not serial divergent tasks, a perfect representation of ensuring that we are using the appropriate compute resource for the right task.
But even the task itself has to be practical and the overall usage scenario of the device has to be practical.
When running a game with console-quality graphics, using GPU compute for some physics calculations does not make sense. While physics are parallel and have limited divergence, in this usage scenario the GPU is already very busy delivering stunning graphical quality to a high resolution screen, hence further loading (or perhaps more accurately overloading) the GPU with a physics task will typically just lead to an overall reduced consumer experience (e.g. lower framerate and/or lower image quality).
On the other hand, when snapping multi-megapixel pictures with your mobile phone camera, you may want to run some image enhancement routines. Loading this onto the GPU makes sense, as this is a parallel non-divergent type of task. Additionally, during the processing, the user is basically just waiting to see his picture and hence the GPU will not be very busy – apart from probably just showing an idle/waiting animation in the GUI.
So two different scenarios both pass the type of processing check but only one passes the practical usage scenario.
There are other usage scenarios that pass the processing type check but may be at odds with the practical check. Video encode and decode fall somewhere in this grey area, where most devices have dedicated resources for executing these tasks in the form of hardware blocks (video processing units). For example, PowerVR VPUs (essentially, fixed function hardware) are far more power and bandwidth efficient than using a programmable, generalized compute resource such as a PowerVR GPU. However, for platforms that do not include dedicated hardware resources for video transcoding, video transcoding using GPU compute might be a more realistic and efficient way of performing these tasks compared to, for example, using the CPU.
A failed usage scenario for mobile would be extreme types of compute which require massive processing time and precision, e.g. folding molecules or other scientific tasks. These fail the practical check as these are things you should never even consider doing on a mobile device. While you may want to view the results on your mobile device, this type of compute should be run on dedicated servers in the cloud.
Most compute usage scenarios for mobile battery-powered devices, at least in the near-term, will be practical, common-sense usage scenarios dominated by image and video post-processing and camera vision type of tasks. All of these meet the checks for types of compute as well as the practicality requirement.
A basic rule to remember: just because a task is parallel and non-divergent doesn’t mean that it should run on a mobile GPU – it must always be a sensible usage of your valued battery life.
If you have any questions or feedback about Imagination’s graphics IP, please use the comments box below. To keep up to date with the latest developments on PowerVR, follow us on Twitter (@ImaginationTech) and subscribe to our blog feed.
