This article provides insight into scaling the fidelity of graphics to get the most out of the underlying GPU, a unique selling point when differentiating your application from the crowd.
As the capabilities of mobile devices accelerate, scaling the fidelity of graphics to get the most out of the underlying GPU has become a unique selling point when differentiating your application from the crowd. To give you an insight into how this can be done across the wide range of devices available today, this article will provide you with a number of useful app development and optimization recommendations.
Imagination started the PowerVR Insider program almost a decade ago at the beginning of the mobile graphics revolution, to ensure that developers have all the requisite tools and utilities, coupled with a developer support organization that has ongoing partnerships with mobile gaming/multimedia companies such as Epic Games, EA Games, Havok, Metaio, and Unity.
At Imagination, for instance, we’ve seen examples where apps would search for strings being returned by the GPU driver and assume it would be a lower end core from that GPU family. This essentially meant that the same level of effects and details would be displayed for all platforms based on the lowest common denominator from that family of GPUs.
An example of a popular basketball game running on very similar devices but displaying different levels of effects
So let’s take a look at the underlying GPU hardware inside some of the devices that recently began shipping worldwide to not only understand the significance of detecting the graphics processor correctly but to ensure you make the most out of the GPU in your target platforms. If you want to know more about one of the most popular mobile GPU architecture available on the market, this recording of Gordon MacLachlan's presentation at AltDevConf describes some of the specific features of Imagination’s high performance, low power Series5/5XT and Series6 GPU families.
The rest of this article contains some recommendations (in no particular order) that should help developers correctly detect the GPU inside any Android device.
One way of making sure your app is designed to work correctly across the widest range of devices is to use a database of devices that is stored either in the cloud or embedded within the application. This database should contain performance numbers for specific devices or computing platforms, and may be updated from various websites that publish benchmark results.
For example, GLBenchmark has a collection of devices and development platforms that cover multiple operating systems (see below).
The Archos 80, 97, 116 Platinum Series (Allwinner A31 with PowerVR SGX544MP2)
There are also websites like GSMArena.com, PDAdb.net or phoneArena.com that offer in-depth reviews, detailed specifications and user comments which provide developers with information regarding the right GPU configuration, frequency and supported APIs and, just as importantly, the number of available extensions.
Onda V818 mini (Allwinner A31s with PowerVR SGX544MP2)
A selection of GLBenchmark results for PowerVR SGX544MP-based devices
Android phones and tablets come in many shapes, sizes and OS releases.
When developing on the Android platform, there are two ways to determine specific characteristics of different devices: by querying the Android Package Manager and GPU driver (feature detection) or by checking different members of the Android.os.Build object (device detection).
On Android platforms, feature detection will return certain standardized strings which SoC vendors don’t usually change.
However, if a particular app has been written just based on device detection mechanisms with certain assumptions regarding the build and manufacturer specifications, then the query revealing the device on which the app is currently running might mislead the application into setting the wrong performance parameters.
For example, the most popular Android-based tablets are by far the five members of Amazon’s Kindle Fire family. For these devices, Amazon currently leverages three distinct chipsets from Texas Instruments based on the OMAP4 architecture: OMAP4430, OMAP4460 and OMAP4470.
Amazon Kindle Fire HD 8.9” (Texas Instruments OMAP4470 with PowerVR SGX544SC)
An older app targeting just android.os.Build.MODEL = ‘Kindle Fire’ will obviously miss all the newer models which have a different naming scheme. Similarly, by addressing only a certain android.os.Build.MANUFACTURER string such as ‘Amazon’, your app will ignore hundreds of millions of devices which have a very capable GPUs but are not manufactured by Amazon.
We therefore recommend you develop your apps to rely mainly on feature detection. Feature detection can be performed in several different ways, primarily through the OpenGL ES2 graphics API, but also via other methods such as querying the Android Package Manager or performing reflection. This will allow you to target a huge range of devices and form factors.
Relying on device detection should only be done when absolutely necessary and when a thorough understanding of the respective platform is presumed. Certain risks are always introduced when performing device detection in your app; therefore we advise you to proceed with caution.
Samsung Galaxy S 4 (Samsung Exynos 5 Octa with PowerVR SGX544MP)
As a general rule, this type of code should be integrated only when you clearly wish to provide apps with certain added functionality for a newer chipset or upcoming flagship devices, like the Samsung Galaxy S 4.
Finally, if any of the above seems too complicated to implement or requires too much development work, a simple solution is to give the user multiple choices in quality and/or performance. This would create a similar situation to that in the PC gaming market, where certain expectations must be met in terms of educating and guiding users.
You could, for example, create two or three pre-set levels of graphical effects and let the user turn them on or off as he sees fit.
Ideally, you would pick a lower-level quality point where everything should run at a decent frame rate and with a limited number of effects. This involves basic OpenGL ES 1.1/2.0 functionality and would run well on single-core, lower frequency GPUs.
A popular FPS running on two very similar devices, but displaying different levels of effects on different operating systems
As you move towards console-quality graphics, allow the user to enable extra effects that require higher performance from the graphics subsystem, and let them decide if the resulting performance is acceptable.
Android currently supports a range of CPU and GPU architectures, implemented in different combinations across various chipsets.
A unique selling point for low-power, high-performance graphics processors has been their ability to be integrated alongside a wide range of mobile CPU architectures and products, including ARM, x86 and MIPS.
Users expect their applications to run smoothly and efficiently across any of their Android-based devices, be it a smartphone, tablet, smart TV or any other embedded device.
A simple way for developers to ensure their app is optimized to support any combination of CPU and GPU is to include a simple benchmark as part of their preloading sequence. As an example, an application could use our PowerVR Graphics SDK tools to recognise that the Series5/5XT USSE unit is maxed out during the benchmark run, so simpler shaders should be used on the device.
Another example is an embedded benchmark like the one inside Epic Citadel which allows developers to get an accurate estimation of any system’s performance. This is due to the way in which some current applications are written, where developers make certain assumptions based on a fixed list of hardware characteristics.
PVRTune can be used during benchmark development
For example, don’t assume that a return of certain strings by the GPU driver means it must be a specific graphics core. As it might well now be a multicore GPU, you don’t want to limit the level of effects and details to the lowest common denominator baseline if the device has a multiprocessor-based SoC – you’d be effectively crippling your apps graphics performance.
Using PVRScope to find performance spikes and to generate reports on overall performance while an app is executing
Even more importantly, by hard-coding queries would completely ignore the current generation of GPUs, which are part of a different family and have a different naming scheme.
Think about the rendering potential your app might be missing out on:
Most GPU families range anywhere from 5x to 100x in terms of performance compared to a single core GPU.
The multicore GPUs include updated, unified scalable shader engines which typically extend the feature set and performance of previous generations by doubling the floating point throughput capabilities and increasing the pipeline scalability.
Newer GPUs are based on unified scalable clusters, with each cluster integrating up to 16 pipelines and each core scaling up to 8 clusters.
GPU cores also include memory bandwidth optimizations and power-efficient technologies like advanced texture compression standards, lossless compression, and software microkernels that manage all higher level events at the GPU level.
By ignoring all of these improvements and changes in hardware specifications, games are effectively missing out on exploiting huge gains in performance!
Another well-known fact is that mobile platforms have a wide range of design characteristics that can directly influence performance, such as:
- Memory type and speed: Is it DDR3, DDR2 or LPDDR3? Is it single channel or dual-channel?
- Number and type of CPU cores: Is it latest-generation quad core or previous generation dual core?
- Number and type of GPU cores, rated frequencies: Is it a single core GPU running at 600MHz or a dual-processor GPU running at 300MHz?
- Display resolution: Is it a 4K x 2K, 10.1” display or a 9.7” screen with a Retina-like resolution (2048 x 1536 pixels)?
The only way to determine the impact of certain system-wide choices is to write a straightforward set of simple benchmarks that test the major performance-affecting characteristics of a platform. It involves some extra effort, but we have already seen the technique implemented in a number of recent applications.
No matter which of these options you choose to implement, it is important to keep in mind that Android’s online store, Google Play, offers a return policy on any purchased app and dedicated feedback sections where users tend to get quite vocal about unsuccessful purchases. So make sure you design your app to its full potential!
Although North America currently has the largest number of smartphone and tablet users, research from Forrester predicts that the Asia-Pacific region will grow by 20% in 2013, mainly driven by local semiconductor companies like AllWinner or MediaTek and OEM vendors such as ZTE, Onda, Ramos, Oppo, etc. As a result, developers must understand that the mobile space is evolving in unique ways which have begun to alter certain traditional market balances.
Focusing only a certain Android platform might sound like a good idea at first, especially if a particular company is providing a significant financial incentive to encourage this approach. But in the long run, it is not a sustainable option, especially in a dynamic, fast-paced mobile world where things can change very quickly. Developing for a broad base can ensure longevity for your app.
The best approach is to study the market carefully and understand the advantages of all – or, at the very least, the most popular - hardware GPU and CPU architectures and products. This will help you shape your application in a more robust and flexible way that adheres to a fair and well-documented set of guidelines.
Read more about:
BlogsYou May Also Like
.png?width=300&auto=webp&quality=80&disable=upscale)
