Mobile GPU compute must be practical GPU compute

Picture of Kristof Beets
Aug 15, 2013  |  2 min read

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.

Examples of practical and impractical mobile GPU compute applications

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.

GPU compute_impractical examplesBiomedical simulations and weather pattern distributions are some examples of impractical use cases for mobile GPU compute

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.

GPU compute_practical examplesImage processing, camera vision and augmented reality applications are some examples of practical use cases for mobile GPU compute

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.

Share this post

About the Author
Picture of Kristof Beets

Kristof Beets is VP of Technology Insights at Imagination, where he drives the alignment of the technology roadmaps with market trends and customer needs as part of the IMG Labs Research organisation. He has a background in electrical engineering and received a master’s degree in artificial intelligence. Prior to joining the Labs Team he was part of the Business Development and Product Management Teams. Before this he worked on SDKs and tools for both PC and mobile products and ran the Competitive Analysis and Demo Teams as a member of the PowerVR Developer Relations and Ecosystem Teams. Kristof has written numerous articles and whitepapers which have been published in the ShaderX and GPU Pro Series of books and online by the Khronos Group, Beyond3D, 3Dfx Interactive and of course Imagination. Kristof has spoken at GDC, SIGGRAPH, Embedded Technology and MWC among others.

More from Kristof Beets

Read Next