optimizing iPhone OpenGL ES fill rate

Question

I have an Open GL ES game on the iPhone. My framerate is pretty sucky, ~20fps. Using the Xcode OpenGL ES performance tool on an iPhone 3G, it shows:

Renderer Utilization

Answer 1

I wanted to chime in with an additional answer, change the Framebuffer backing to be a 16bit format as opposed to a 32 bit format.

if ((self = [super initWithCoder:coder])) 
    {
    eaglLayer = (CAEAGLLayer *)self.layer;
    eaglLayer.opaque = YES;
    eaglLayer.drawableProperties = [NSDictionary dictionaryWithObjectsAndKeys:
                                            [NSNumber numberWithBool:NO], 
                                            kEAGLDrawablePropertyRetainedBacking, 
                                            kEAGLColorFormatRGB565,  //kEAGLColorFormatRGBA8 = large frame buff 32bit  // kEAGLColorFormatRGB565 = 16bit frame buffer.
                                            kEAGLDrawablePropertyColorFormat, 
                                            nil];        
}

What woke me up to this was the XCode profiler. It kept complaining about using to large a frame buffer, eventually I found it in my init section. http://developer.apple.com/library/ios/#documentation/iPhone/Reference/EAGLDrawable_Ref/EAGLDrawable/EAGLDrawable.html . That single change allowed my games on iPad, Retina, and iPods to go to 60 FPS. I have yet to re-release them with this change as I just found it out 3 days ago :) but I do not think I plan to release at 60fps, 30fps is just fine for casual games, and I found that my sound effects cut the frame rate down, so either resample, play the sfx in another thread, or other solutions to keep that frame rate up if I decide to go with 60fps.
Don't forget to discard the buffers that are not used to display..

if (fiOSver >= 4.0f) {
    const GLenum discards[]  = {GL_DEPTH_ATTACHMENT_OES};
    glDiscardFramebufferEXT(GL_FRAMEBUFFER_OES,1,discards);
}

[m_oglContext presentRenderbuffer:GL_RENDERBUFFER_OES];

Answer 2

In a similar situation (porting a 2D Adventure game to the iPad). My 3GS version was running more or less locked at 60FPS, put it on iPad dropped it (and my jaw) to 20fps.

Turns out ONE of the little gotchas involved is that the PVR cards hate GL_ALPHA_TEST; on the PC that actually has a slight positive effect (especially on older intel chips), but they're death on fillrate on the iPhone. Changing that to

 glDisable(GL_ALPHA_TEST);

gave me an immediate 100% boost in FPS (up to 40 FPS). Not bad for one line of code.. :)

Allan

Answer 3

The biggest performance killer on the iPhone platform is the number of draw calls and state changes. If you're doing more than 20ish draw calls or state changes, you're going to run into a performance wall.

Batching and texture atlases are your friend.

Answer 4

Look to Apple's "Best Practices for Working with Texture Data" and "Best Practices for Working with Vertex Data" sections of the OpenGL ES Programming Guide for iPhone OS. They highly recommend (as do others) that you use PVRTC for compressing your textures, because they can offer an 8:1 or 16:1 compression ratio over your standard uncompressed textures. Aside from mipmapping, you seem to be doing the other recommended optimization of using a texture atlas.

You do not appear to be geometry-limited, because (as I discovered in this question) the Tiler Utilization statistic seems to indicate how much of a bottleneck is being caused by geometry size. However, the iPhone 3G S (and third-generation iPod touch and iPad) support hardware-accelerated VBOs, so you might give those a shot and see how they affect performance. They might not have as much of an effect as compressing textures would, but they're not hard to implement.

Answer 5

By my past experience with openGL ES on old windows mobile devices with processing speed around 600mhz usually reducing the rendering window resolution increase the speed of rendering.

as my tests lately i figured out that i need performance monitoring while rendering frame by frame to collect how many fps can display with current performance and what resolution currently applied

i hope it is a good practice to keep a monitoring algorithm in place of rendering view to balance resolution and frame rate while running a game rendering engine.

depending on the amount of frame rate you wanted, you should sacrifice the rendering view resolution, to perform best and degrade gracefully on most devices with varying hardware and software performence.

you may need to control the resolution menually like explained in this article.

http://www.david-amador.com/2010/09/setting-opengl-view-for-iphone-4-retina-hi-resolution/

Answer 6

Given that the Renderer Utilization is basically at 100%, that indicates that the bottleneck is filling, texturing, and blending pixels. Techniques intended to optimize vertex processing (VBOs and vertex formats) or CPU usage (draw call batching) will likely not help, as they will not speed up pixel processing.

Your best bet is to reduce the number of pixels that you are filling, and also look at different texture formats that make better use of the very limited memory bandwidth available on the first generation devices. Prefer the use of PVRTC textures wherever possible, and 16bit uncompressed textures otherwise.