Re: [AD] Possible issue with the way allegro uses FBOs?

[ Thread Index | Date Index | More lists.liballeg.org/allegro-developers Archives ]


On June 21, 2010, Thomas Fjellstrom wrote:
> Somewhat recently the intel-gfx linux drivers received FBO support, and
> it seems to work.
> 
> Unfortunately with allegro's ex_bitmap_target example it gets a whopping
> 8-10fps, 2 more than the forced bitmap locking.
> 
> I found an gl fbo example on the web which seems to render at 50-60fps
> just fine. Here is the actual fbo code it uses:
> 
>      // init:
>      // create a framebuffer object, you need to delete them when program
>      // exits.
>      glGenFramebuffersEXT(1, &fboId);
>      glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fboId);
> 
>      // create a renderbuffer object to store depth info
>      // NOTE: A depth renderable image should be attached the FBO for
> depth // test. If we don't attach a depth renderable image to the FBO,
> then // the rendering output will be corrupted because of missing depth
> // test. If you also need stencil test for your rendering, then you //
> must attach additional image to the stencil attachement point, too.
> glGenRenderbuffersEXT(1, &rboId);
>      glBindRenderbufferEXT(GL_RENDERBUFFER_EXT, rboId);
>      glRenderbufferStorageEXT(GL_RENDERBUFFER_EXT, GL_DEPTH_COMPONENT,
>         TEXTURE_WIDTH, TEXTURE_HEIGHT);
>      glBindRenderbufferEXT(GL_RENDERBUFFER_EXT, 0);
> 
>      // attach a texture to FBO color attachement point
>      glFramebufferTexture2DEXT(GL_FRAMEBUFFER_EXT,
> GL_COLOR_ATTACHMENT0_EXT, GL_TEXTURE_2D, textureId, 0);
> 
>      // attach a renderbuffer to depth attachment point
>      glFramebufferRenderbufferEXT(GL_FRAMEBUFFER_EXT,
>         GL_DEPTH_ATTACHMENT_EXT, GL_RENDERBUFFER_EXT, rboId);
> 
> 	// draw:
> 
> 	// set the rendering destination to FBO
>      glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fboId);
> 
>     // clear buffer
>     glClearColor(1, 1, 1, 1);
>     glClear(GL_COLOR_BUFFER_BIT | GL_DEPTH_BUFFER_BIT);
> 
>     // draw a rotating teapot
>     glPushMatrix();
>     glRotatef(angle*0.5f, 1, 0, 0);
>     glRotatef(angle, 0, 1, 0);
>     glRotatef(angle*0.7f, 0, 0, 1);
>     glTranslatef(0, -1.575f, 0);
>     drawTeapot();
>     glPopMatrix();
> 
>     // back to normal window-system-provided framebuffer
>     glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, 0); // unbind
> 
>     // trigger mipmaps generation explicitly
>     // NOTE: If GL_GENERATE_MIPMAP is set to GL_TRUE, then
>     // glCopyTexSubImage2D() triggers mipmap generation automatically.
>     // However, the texture attached onto a FBO should generate mipmaps
>     // manually via glGenerateMipmapEXT().
>     glBindTexture(GL_TEXTURE_2D, textureId);
>     glGenerateMipmapEXT(GL_TEXTURE_2D);
>     glBindTexture(GL_TEXTURE_2D, 0);
> 
>     ....
> 
>     // draw rotating cube here
> 
> 
> Is there something allegro is or isn't doing that might explain the
> difference? If there is something we're doing wrong, it could improve
> performance on a /lot/ of integrated intel gpus.


Apparently ex_opengl uses an FBO in the same way the ex_bitmap_target 
example does. ex_opengl shows 350fps, where as ex_bitmap_target in "Direct" 
mode still shows 7-10fps

I /REALLY/ think this should be fixed. If I knew what was wrong, I'd fix it, 
but I don't. Someone who knows GL should look into this.

-- 
Thomas Fjellstrom
tfjellstrom@xxxxxxxxxx




Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/