ualcomm's support for OpenGL ES makes 3D graphics development for today's wireless terminals much easier than ever before. With an interface that's standard across a wide variety of platforms including Brew, Symbian, and Windows CE, OpenGL-ES promises to power a wide variety of games and user interfaces in the future. The previous article shows you how to get set up with Qualcomm's implementation of OpenGL ES for Brew. This article expands upon those topics and shares some performance tips provided by Qualcomm and other developers at this year's Brew Developer Conference in San Diego.

The State of OpenGL-ES on Brew-enabled Handsets Today
As I write this, OpenGL ES is available only on the latest mid-to-high-end handsets, those powered by the MSM6550 platform. The MSM6550 has an ARM9 core and considerable digital signal processing capabilities. In addition, it has a 3D graphics core provided by QUALCOMM onboard. This core provides hardware-accelerated pixel and vertex processing in hardware within the MSM6550.

Because the solution is an internal on-chip one, the bottlenecks aren't where you'd expect in older mobile 3D graphics solutions. Instead of being limited by a bus to an external graphics controller, the core limitation is the vertex and pixel processors themselves. This results in significantly faster performance, but you still have to take care to keep the pipeline full (more on that in a moment). Peak benchmarks as I write this are quite good—Qualcomm reports smooth shading of 241kTri/sec (falling to 228 kTri/sec for texturing and 135 kTri/sec for texturing and lighting combined).

Although OpenGL ES is likely to be on a specific MSM6550-powered handset, there's no guarantee, so be sure to check device data sheets at the Brew extranet carefully when targeting your application. Because of these two points, OpenGL ES isn't ubiquitous on Brew handsets… yet. Over time this should improve as more handsets running on the MSM6550 are released, and as Qualcomm seeds later-generation processors with similar or better graphics hardware to handset manufacturers.

Because the solution is in hardware, you must make sure you're adequately loading the graphics hardware. Sending too few vertices at a time to be rendered is a waste of the hardware's capabilities. At worst, you can actually stall the pipeline. It's recommended that you send over sixty vertices per render command (assuming your model as that many to render). This is too few—fewer than thirty on current hardware—to stall the pipeline entirely. Thus, it's important to prepare an adequate scene in advance and keep the pipeline running in order to prevent pipeline stalls and the resulting rendering hiccups that can occur.

The implementation of OpenGL ES includes an early depth test, so you don't need to worry about trying to optimize your scene to get the best hidden-vertex removal performance. Instead, you should render the scene from front to back, and let the implementation’s depth test sort things out.

While all of this runs in hardware, remember that the hardware is a shared resource—the graphics hardware shares the digital signal processor (DSP) with the audio hardware. If you're planning on playing audio while rendering graphics, be sure to use an appropriate audio format so you don’t overload the DSP. This is something that requires some testing to get right.