Slow Binding of FBO, iPod Touch

Sorry if this has been covered before. I tried searching but came up with nothing. I found a similar thread which had the answer of “install PVRTune and find bottlenecks first”. Can I install PVRTune on this device (iPod touch 4th gen). I didn’t see iOS installation instructions (nor do I expect this to be possible, knowing Apple).


So, I’ll get down to my general question. In my current game, the “main” drawing loop is set up similarly to this. There is a “main view” which a draw method like below. It has a framebuffer, of which the color buffer is “presented to be displayed” at the end of each frame. In the draw method, this view calls the draw method on its “scene”. The frame buffer have a color render buffer and a depth render buffer attached to it.

Code:

-(void)draw

{

    GLint prevFBO;

    glGetIntegerv(GL_FRAMEBUFFER, &prevFBO);

    if ( prevFBO != frameBuffer )

    {

        glBindFramebuffer(GL_FRAMEBUFFERframeBuffer);

    }

    glClearColor(.2.2.21);

    glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

    glBindRenderbuffer(GL_RENDERBUFFERcolorRenderBuffer);

    [context presentRenderbuffer:GL_RENDERBUFFER];

    glBindRenderbuffer(GL_RENDERBUFFER0);

}


The game currently runs at 60 FPS. Now, I am wanting to add some motion blur to some aspects of it. So, to do the motion blur effect, I am rendering the scene (well, most of it) to a texture and then using that texture to render some quads with the blur effect. How the effect is done right now is not what I'm posting about. I'm posting because as soon as I try to render to a texture my FPS drops significantly.

Just simple biding the frame buffer (that has a texture attached to the color attachment) in the scene's "draw" function and then binding the previous FBO right after it drops my FPS from 60 to 33. This is without even rendering to the texture or changing much.

The texture is 1024 x 1024. Some code is below.

Code:
-(void)draw
{
    GLenum attachments[] = { GL_COLOR_ATTACHMENT0, GL_DEPTH_ATTACHMENT };

    GLint prevFBO;

    glGetIntegerv(GL_FRAMEBUFFER_BINDING, &prevFBO);

    

    if ( prevFBO != renderTextureFBO )

    {

        // Tell openGL that we no longer need the depth and color

        // for the current FBO. No need for it to resolve (store) info to RAM

        // on FBO switch.

        glDiscardFramebufferEXT(GL_FRAMEBUFFER, 2, attachments);


        // Bind new FBO

        glBindFramebuffer(GL_FRAMEBUFFER, renderTextureFBO);

        glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);

    }

    

    // Tell openGL that we no longer need the depth and color

    // for this FBO. No need for it to resolve (store) info to RAM

    // on FBO switch.

    glDiscardFramebufferEXT(GL_FRAMEBUFFER, 2, attachments);


    // Restore previous FBO

    glBindFramebuffer(GL_FRAMEBUFFER, prevFBO);

    // ...... Previous draw code........//

}


I know that binding new frame buffers is like making a "new scene" and that the attached buffers can read from/write to RAM when binding new FBOs and this can cause some performance drop. Adding glClears like I have is supposed to negate most of the "read from RAM" performance hit. Even adding glDiscardFramebufferEXT with both attachments (which should get rid of the "write to" performance hit) still nets me only 37 FPS.

So, to summarize. Adding the binding of a new frame buffer which has a 1024x1024 texture and depth buffer attached to it (even without rendering to the FBO) causes my FPS to go from 60 to 37 with all the optimizations I can think of. I am unsure why something which I expect to not take much time, drops my FPS like crazy and the glBindFrameBuffer call (just putting timers around it) takes 6.5 ms.

I downloaded the SDK and noticed the "fractal" demo does something similar (renders to a texture and then uses that texture to draw the scene) and that demo gets 60 FPS on the device. So, I'm confused as to what I'm doing wrong or how I can begin to analyze my problem.

Hi,

Apologies for the delayed reply.

It’s hard to say without testing the problem, but it may be the case that the iOS GPU driver ignores the glDiscardFramebufferEXT() hint to discard the colour buffer and writes colour data out to memory anyway. If you are bandwidth limited, the cost of writing the cleared tile colour data to system memory could explain the drop in performance.

Have you tried to reduce the size of the FBO you are clearing to see how this affects performance? Have you tried to reduce the bandwidth overhead of the rest of your scene’s render, e.g. forcing all textures to 2x2?

Unfortunately, PVRTune is not supported on iOS.

Regards,
Joe