I was recently asked about the best way to optimize rendering for mobile devices.  I thought it would be a good idea to share those same tips.  Most of these techniques apply to rendering in general, but these tips were given with OpenGL ES in mind.  Without further ado:

Before spending any time doing a rendering optimization - _especially_ if it involves a significant re-architecture of the engine - I try to measure the potential gain.

I always use a fixed scene with a known performance measurement before beginning optimization.  This way, you know exactly your gain or loss.  Always measure performance in milliseconds if at all possible.  When dealing with “FPS” it’s tough to get an objective measure of a performance gain or loss.  An optimization that takes your game from 20 ms to 15 ms translates to a gain of “17 fps” (50 fps to 66.66 fps), while the same optimization from 45 ms to 40 ms means your frame rate only changes slightly (22.2 fps to 25 fps), but that’s the same 5 ms gain – and 5 ms is _huge_ in GPU performance-land.

The first thing I like to do is to comment out the actual eglSwapBuffers() call.  This will measure all the CPU work (setting OpenGL state, draw calls, etc) but won’t actually draw anything.  This should give you a theoretical “best performance possible” for your current rendering engine, as if drawing everything was free.  If performance doesn't change much, or at all, it’s likely you have CPU side bottlenecks that need to be addressed.  Note that you may also need to remove any glFlush() / glFinish() calls as well.

Next on my list of candidates to measure is blending.  The mobile GPUs (especially the PowerVR series) are powerful, but tend to have a problem with fill-rate and blending.  Blending requires reading and writing to the frame buffer, and can often be a big performance hit.  This one is easy to test.  Using your performance test scene, simply call glDisable(GL_BLEND) instead of enabling it and measure the change in performance.  I also often set glBlendFunc(GL_ONE, GL_ZERO) just to be safe when testing this.

Related to blending is fill-rate.  Reduce the number of pixels you’re rendering, and measure the performance gain.  You should be able to do this simply by setting glViewport() to a smaller sub-region of the screen.  If your performance increases, it means you’re fill bound, which means pixel processing (including blending, pixel shaders, per-pixel lighting calculations, and large numbers of pixels being drawn and re-drawn) are the current bottleneck.

To measure the number of pixels that might be drawn over and over again, simply change all your draw calls to use a dark red texture, and change the blend mode to GL_ONE, GL_ONE.  This will show you where you’re overdrawing too much – dark is good, bright is bad.

Textures can also impact performance and memory.  Another quick test is to create, at engine start up, a single 2x2 RGB texture and use this in place of all your other glBindTexture calls.  This will tell you if you are texture fetch bound or not.  If performance changes a lot, consider decreasing resolution, mip-mapping (actually, you should be mip-mapping all the time anyways), and changing to compressed texture formats.

Regarding mip mapping, my favorite texture filtering mode for the mobile chips is bi-linear.  This means linear filtering for up-sampling and down-sampling, but point filtering for mip levels.  It’s high quality but performant.  The next higher quality version is tri-linear (which also filters between mip levels), but that really kills a lot of the mobile chips.  Heck, it even hurts on the PS3.  You set bilinear filtering like so:

glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MIN_FILTER, GL_LINEAR_MIPMAP_NEAREST);
glTexParameteri(GL_TEXTURE_2D, GL_TEXTURE_MAG_FILTER, GL_LINEAR);

Make sure you’re culling back faces – a lot of people miss this, and it results in things costing 2x as much to draw as they should (since the GPU is drawing the front side, AND the side you never see)

Vertex cache coherency can play a big role.  Using indexed triangle lists (i.e. glDrawElements as opposed to glDrawArrays can be huge – rather than setting 6 vertices for a simple quad, you only set 4, and pass in 6 indices into that array (something like {0, 1, 2, 0, 2, 3} for example, depending on culling and how your data is organized).  This means less data for the GPU to process, less redundant vertex data, and if you use a cache optimizer, you can re-organize your indices to keep the same vertices in the GPU cache as long as possible.

Lastly, setting the vertex data itself can have a large impact.  If you’re using the immediate mode GL methods (glVertex3f, glTexCoord2f, etc) then you’ll definitely get a big gain from vertex buffer objects.  Even if you don’t yet use VBOs, you can use a similar approach (create a vertex data array and set it with glVertexPointer, glTexCoordPointer, etc and draw with glDrawElements).

Texture atlases often come up as a good optimization.  I've only ever used a texture atlas for font rendering.  It’s the sort of low-level optimization that is often not needed.  Of course, you want to do the minimal amount of work, so you don’t want to bounce around setting different textures at random, and instead should bind a texture, draw all sprites using that texture, etc, but texture atlases are often more trouble than they’re worth IMO.

Regarding multi-texture – If you’re doing something in two or more rendering passes that can be done in a single pass with multi-texturing, multi-texturing is almost always faster.  Easy to test this, too – if you assume multi-texturing is free (even though it’s not totally free), just disable your subsequent rendering passes and measure the performance difference.  You just need to be careful about your target hardware.  OpenGL ES 1.1 requires only 2 texture stages (although many devices support more), so it’s something to keep in mind.  My engine only ever tries to use 2 stages max, because I don’t want to have to worry about compatibility with older hardware.  I believe first gen iPhone/iPod Touch uses the PowerVR chip that only supports 2 texture stages.

출처 : http://graphicsforgames.blogspot.kr/2011/04/optimizing-graphics-for-mobile.html