Tile-Based Deferred Rendering

PowerVR SGX series hardware uses a technique known as tile-based deferred rendering (TBDR). When you call OpenGL ES functions to submit rendering commands to the hardware, those commands are buffered until a large list of commands is accumulated. The hardware renders these commands as a single operation by dividing the framebuffer into tiles and then drawing the commands once for each tile, with each tile rendering only the primitives that are visible within it. The key advantage to a deferred renderer is that it accesses memory very efficiently. Partitioning rendering into tiles allows the GPU to more effectively cache the pixel values from the framebuffer, making depth testing and blending more efficient.

Deferred rendering also allows the GPU to perform hidden surface removal before fragments are processed. Pixels that are not visible are discarded without sampling textures or performing fragment processing, significantly reducing the calculations that the GPU must perform to render the tile. To gain the most benefit from this feature, draw as much of the frame with opaque content as possible and minimize use of blending, alpha testing, and the discard instruction in GLSL shaders. Because the hardware performs hidden surface removal, it is not necessary for your app to sort primitives from front to back.

Some operations under a deferred renderer are more expensive than they would be under a traditional stream renderer. The memory bandwidth and computational savings described above perform best when processing large scenes. When the hardware receives OpenGL ES commands that require it to render smaller scenes, the renderer loses much of its efficiency. For example, if your app renders batches of triangles using a texture and then modifies the texture, the OpenGL ES implementation must either flush out those commands immediately or duplicate the texture; neither option uses the hardware efficiently. Similarly, any attempt to read pixel data from the framebuffer requires that preceding commands be processed if they would alter that framebuffer.

Best Practices for both OpenGL ES 2.0 and OpenGL ES 1.1

These practices apply to OpenGL ES apps on SGX Series 5 hardware:

• Avoid operations that modify OpenGL ES objects already in use by the renderer because of previously submitted drawing commands. When you need to modify OpenGL ES resources, schedule those modifications at the beginning or end of a frame. These commands include glBufferSubData, glBufferData, glMapBuffer, glTexSubImage, glCopyTexImage, glCopyTexSubImage, glReadPixels, glBindFramebuffer, glFlush, and glFinish.

• To take advantage of the processor’s hidden surface removal, follow the drawing guidelines found in Do Not Sort Rendered Objects Except Where Necessary For Correct Rendering in OpenGL ES Programming Guide.

• Vertex buffer objects (VBOs) provide a significant performance improvement on the PowerVR SGX. See Use Vertex Buffer Objects to Manage Copying Vertex Data in OpenGL ES Programming Guide.

• Do not use separate stencil buffers. Instead use a combined depth/stencil buffer.

• Use Core Animation rotations of renderbuffers to rotate content between landscape and portrait mode. For best performance, ensure that the renderbuffer’s height and width are each a multiple of 32 pixels.

OpenGL ES 2.0 on PowerVR SGX Series 5 Hardware

Table 1-2 provides a high-level summary for OpenGL ES 2.0 platforms.

OpenGL ES 1.1 on PowerVR SGX Series 5 Hardware

OpenGL ES 1.1 is implemented on PowerVR SGX Series 5 hardware using customized shaders. Whenever your app changes OpenGL ES state variables, a new shader is implicitly generated as needed. Because of this, changing OpenGL ES state may be more expensive than it would be on a pure hardware implementation. You can improve the performance of your app by reducing the number of state changes it performs. For more information, see Be Mindful of OpenGL ES State Variables in OpenGL ES Programming Guide.

Table 1-3 provides a high-level summary for OpenGL ES 1.1 platforms.