glFramebufferTexture2DEXT slow

The problem: glFramebufferTexture2DEXT seems to be taking an unreasonably long time.

I am creating a framebuffer object initialially (once):

GLuint fbo;
glGenFramebuffersEXT(1, &fbo);
throw(“Invalid frame buffer object”);
glBindFramebufferEXT(GL_FRAMEBUFFER_EXT, fbo);
glViewport(0,0,width, height);

then creating a new texture to render to for each frame:

GLuint texHandle;
glGenTextures(1, &texHandle);
glBindTexture(GL_TEXTURE_RECTANGLE_NV, texHandle);
glTexImage2D(GL_TEXTURE_RECTANGLE_NV, 0, GL_FLOAT_R_NV, width, height, 0, GL_RED, GL_FLOAT, 0);
//Where data is a float array of size width * height.
glTexSubImage2D(GL_TEXTURE_RECTANGLE_NV, 0, 0, 0, width, height, ret.second, GL_FLOAT, data);

I am then attaching the output texture to the same FBO each time:


throw(“error- frame buffer to texture binding incomplete”);

The program is running correctly, but running very slowly. When profiling I found it was
the glFramebufferTexture2DEXT function (that which attaches the output texture to the FBO each time)
which is taking the time, 0.15 seconds for a 1000x1000 image.

Is this what we be expected or am I doing something wrong?

I remember that I had a similar problem a year ago or something.
glFramebufferTexture2DEXT took a similar amount of time like it does in your program, however this only happened if there was already a texture object attached to the same attachment point.

I solved the problem with a simple workaround: before attaching the new texture object to the FBO, i first used glFramebufferTexture2D with texture id 0 to detach any previously attached texture.

Note that I used GL_TEXTURE_2D and never tried GL_TEXTURE_RECTANGLE_NV with FBOs, so it might be another problem.


Do you experience the same problem if you use the sized internal formats GL_FLOAT_R16_NV and GL_FLOAT_R32_NV?

Related thought that might be your problem. Only bind textures with the same format and resolution to an FBO. If you need different formats or resolutions, use different FBOs, one for each permutation.

Years ago when I was having similar troubles, an NVidia guy tipped me off to this tweak. Essentially there’s a lot of work involved in reconfiguring an FBO if you change its format/res.

No luck im afraid, detaching the frame buffer seems to make an extremely slight difference, but that may be me being hopeful. I’ve also tried R16 and R32 but no change.

At the moment I am doing the same off-screen calculation to the same size and type texture again and again (as way of a test) so I don’t think different formats or resolutions is the problem.

Any other ideas?

Thanks to everyone.

Does anyone have a link to the glFramebufferTexture2DEXT function spec, i’ve found it mentioned in the framebuffer object spec but not actually explained. what does this function does?

It seems the takes a long time the first time this function is run with a new texture (thus having two textures always on the GPU and alternating the destination would solve the problem, think this is or atleast similar to the pingpong technique), but out of interest why is this so? Is it formatting?

Haven’t seen a man page. There’s a decent description in the NVidia FBO Whitepaper (pg. 21).

Dunno. You don’t want to be creating a new texture to render to each frame, which you said you were. You want a pool, and you just grab the next unused texture and use it.

Also, it’s possible that by telling the GPU to use the texture too quickly you force a pipeline stall waiting on rendering of the texture to finish. Or you force a stall by trying to re-render to the texture too quickly when the GPU is still using the texture for rendering (the latter sounds like it might explain your problem, if the check is done there).

sanity check, make sure youre not got auto mipmap creation enabled, which can hugly increase texture creation time

though then again i believe GL_TEXTURE_RECTANGLE_NV + mipmaps is a no go

glTexImage2D(GL_TEXTURE_RECTANGLE_NV, 0, GL_FLOAT_R_NV, width, height, 0, GL_RED, GL_FLOAT, 0);

ild guess is not gonna be on the fast path, perhaps change over to a more standard texture format (even if u use more memory) it can make a huge difference performancewise