Compressing OpenGL ES textures

The 80s called, and they want lazy programming back. Remember “Mr. Mom”? Michael Keaton is talking about rewiring the house, and Martin Mull asks if he’s going to use all 220V, and Keaton responds “Yeah, 220, 221, whatever it takes.” Not knowing what’s inside can make you look silly.

Such is the case with OpenGL ES. Taking a look at how the device actually supports graphics can mean big differences in results. A key area of differentiation is how texture maps are stored, and the support for that in hardware and software. Storing uncompressed or lightly compressed stuff works, but is not very efficient – modern implementations rely on texture compression algorithms to get faster results with less bandwidth and better memory utilization.

One reason the graphics on Apple smart devices are so beautifully consistent is TextureTool, native support in the iOS SDK for compressing textures into the PVRTC format. In and of itself, that isn’t remarkable until adding that PVRTC is supported directly in hardware in the Imagination Technologies PowerVR SGX family of GPUs found in Apple devices. Hardware acceleration for software features almost always wins, and if an accelerator is available it should be utilized. One choice for texture compression in iOS, everyone and everything optimizes for it, and all is well.

Now move over to the Android camp for comparison. There are several texture compression formats in play, and a given phone may or may not have hardware acceleration for them. With underlying support in OpenGL ES, all Android versions since Froyo support ETC1, and most GPU hardware supports it (or ETC2). There are four other formats supported in OpenGL ES 3.0:

ATITC, found in Qualcomm Adreno GPU and AMD implementations (yes, as in ATI);
DTXC, also known as S3TC, favored by NVIDIA, Microsoft et al (yes, as in DirectX);
ASTC, developed by ARM for its Mali GPU;
PVRTC, for Imagination PowerVR SGX implementations.

(image courtesy Intel)

Are you beginning to sense why Android graphics benchmarking results vary so wildly? (Before going off on the visual quality compression produces, let’s take into consideration there is a lighting difference between the left and right side of that image. What I’d like to see is slices of the left eye side by side, and the other formats.)

The naïve Android developer plows into this like they are heading out to body surf waves at Newport Beach, thinking they will get decent results just from watching what other people are doing. It’s harder than it looks. I was reading a game developer forum discussing the merits of ETC1 versus the other texture compression schemes, and the non-conclusive response was startling: if you pick a format not supported in hardware, what you get is software decompression on load using CPU, not GPU, cycles. Ouch. “That may explain our loading times” might be the understatement of the decade. Even Apple advises app developers to check for texture compression file extensions before using them.

The good news is we have general agreement on OpenGL ES for mobile devices, and using some form of texture compression. If you are an Apple developer, the choice of PVRTC is clear for the foreseeable future. If you are developing for Android, Windows, or other environments, PVRTC is one of several options. Selecting a texture compression scheme is more than a software decision, hitting four dimensions that can make or break an implementation: visual quality, memory footprint and bandwidth, power consumption, and overall performance – all functions of a GPU and software support working together.

I have an interesting assignment: to take an objective look at PVRTC, combining information from Imagination Technologies and third party sources. We’ll start with some background: four high-level discussions of some of the issues involved.

Imagination’s overview of PVRTC:
PVTRC: the most efficient texture compression standard for the mobile graphics world

Apple’s OpenGL ES programming guide:
Best Practices for Working with Texture Data

The Android view of OpenGL ES including texture compression:
OpenGL ES | Android Developers Guide

A good overview written by an Intel intern (with some “consider the source” caveats):
Android Texture Compression

Future posts will look at how PVRTC works, what it clearly does well (example: producing small files), where there is some debate (example: visual quality on some images and different algorithms), and more. I’d be happy to hear from those with experience on these issues, and other useful resources we should be looking at.

lang: en_US

Share this post via:

• 
• 
• 
•