324 IV Performance
always consuming 100% of the available processing power. Deliberately throttling
the frame rate to a more modest level and thus consuming less power can signiﬁcantly
extend battery life while having relatively little impact on user experience. Of course,
this does not mean that one should stop optimizing after achieving the target frame
rate: further optimizations will then allow the system to spend more time idle and
hence improve power consumption.
The main focus of this chapter will be on OpenGL ES since that is the primary
market for tile-based GPUs, but occasionally I will touch on desktop OpenGL fea-
tures and how they might perform.
While performance is the main goal for desktop GPUs, mobile GPUs must balance
performance against power consumption, i.e., battery life. One of the biggest con-
sumers of power in a device is memory bandwidth: computations are relatively cheap,
but the further data has to be moved, the more power it takes.
The OpenGL virtual pipeline requires a large amount of bandwidth. For a fairly
typical use-case, each pixel will require a read from the depth/stencil buffer, a write
back to the depth/stencil buffer, and a write to the color buffer, say 12 bytes of trafﬁc,
assuming no overdraw, no blending, no multipass algorithms, and no multisampling.
With all the bells and whistles, one can easily generate over 100 bytes of memory
trafﬁc for each displayed pixel. Since at most 4 bytes of data are needed per displayed
pixel, this is an excessive use of b andwidth and hence power. In reality, desktop GPUs
use compression techniques to reduce the bandwidth, but it is still signiﬁcant.
To reduce this enormous bandwidth demand, many mobile GPUs use tile-based
rendering. At the most basic level, these GPUs move the framebuffer, including the
depth buffer, multisample buffers, etc., out of main memory and into high-speed
on-chip memory. Since this memory is on-chip, and close to where the computa-
tions occur, far less power is required to access it. If it were possible to place a large
framebuffer in on-chip memory, that would be the end of the story; but unfortu-
nately, that would take far too much silicon. The size of the on-chip framebuffer, or
tile buffer, varies between GPUs but can be as small as 16 × 16 pixels.
This poses some new challenges: how can a high-resolution image be produced
using such a small tile buffer? The solution is to break up the OpenGL framebuffer
into 16 × 16 tiles (hence the name “tile-based rendering”) and render one at a time.
For each tile, all the primitives that affect it are rendered into the tile buffer, and once
the tile is complete, it is copied back to the more power-hungry main memory, as
shown in Figure 23.1. The bandwidth advantage comes from only having to write
back a minimum set of results: no depth/stencil values, no overdrawn pixels, and no
multisample buffer data. Additionally, depth/stencil testing and blending are done