Fast Way to Clear a Texture

[henniman]

Hi,

i want to clear a texture. It comes from a pool, and it may have some previous image content. I tried to do this hardware side using FBOs, but to my surprise this turned out very cpu intensive ( GF9600M ):

fbo->Bind();
glDrawBuffer(GL_COLOR_ATTACHMENT0_EXT);
fbo->AttachTexture(GL_COLOR_ATTACHMENT0_EXT, GL_TEXTURE_2D, clear_texture );
glClear(GL_COLOR_BUFFER_BIT);

Is there another fast way to clear a texture to eg. the current clear color?

Best

[BionicBytes]

You could try a couple of differnt approaches.

Bind the FBO and then use glClearBufferiv
or use glCopyTexSubImage2D (test to see which is faster).

Or a different approach altogether and use CUDA.
A similar discussion regarding the efficent clearing of Buffer Object has come up before on these forums See here

[trinitrotoluene]

If your gl implementation support timer query, you can verify the time taken in nanoseconds to clear your texture.

//------in init function
 GLuint timerObject;
 glGenQueries(1,&timerObject);
//-----------------
 
 glBeginQuery(GL_TIME_ELAPSED,timerObject);
fbo->Bind();
glDrawBuffer(GL_COLOR_ATTACHMENT0_EXT);
fbo->AttachTexture(GL_COLOR_ATTACHMENT0_EXT, GL_TEXTURE_2D, clear_texture );
glClear(GL_COLOR_BUFFER_BIT);
 
glEndQuery(GL_TIME_ELAPSED);
 
GLint available = 0; 
 
 while (!available) {
            glGetQueryObjectiv(timerObject, GL_QUERY_RESULT_AVAILABLE, &available);
        }
 
 GLuint64 timeElapsed; //time elapsed in nanosecond 
 
glGetQueryObjectui64v(timerObject,GL_QUERY_RESULT,&timeElapsed);
 
//print timeElapsed

[henniman]

i have put the code in a display list. now it looks a little bit better, performance wise. still wondering - is there some software fallback here?

[kyle_]

You could try issuing glTex[Sub]Image2D from pixel buffer with enough 'black' set aside. Requires additional memory of size of largest mip level though. Will avoid fbo altogether.

[Dark Photon]

Yeah, 2nd that PBO recommendation.

FBO binds/reconfigs can be expensive if you're not careful (you're not binding textures with different resolutions and/or iformats on that FBO are you?; if you are fix that and retry; give us more data on yout texture and perhaps we can advise on speed-ups). And you definitely want to avoid uploading from the CPU. Prob best you can get is do something that's totally on the GPU and which pipelines well.

Consider keeping a "clear" texture and then blit from that to the target texture. Should all happen on the GPU, and should pipeline very well. You can do this via an intermediate PBO. Even better, skip a step and just keep the "clear" contents in a PBO (big enough for your largest texture's base map) and blit to the texture. Using EXT_direct_state_access APIs, you can prob even avoid the buffer and texture binds.

[dukey]

why not have a second texture that is already 'cleared' ;p

[henniman]

actually no, it is a single texture bound to the fbo, its size is 1024x1024 and it is quite standard RGBA / UNSIGNED_BYTE, so nothing special there.

i thought this approach is totally on the GPU side, is there some CPU side action when an fbo is unbound? this would require a data round trip GPU -> CPU -> GPU or am i getting something wrong here?

[henniman]

@dukey: no, the texture comes from a pool to keep gpu memory footprint low

[henniman]

[SOLVED] -- well, kind of. I am using a pbo to stream the black, luckily i can record which portions of the image are already filled, so i have to streeam only a few pixels the 'black' via glSubTexImage.

The performance consumption is close to nil now, but this is mostly related to the small amount of pixels.

@Dark Photon: when you say 'FBO binds/reconfigs can be expensive' - and many people report performance drops when using/binding/rebinding lots of FBOS - what exactly happens here? What is the pitfall? To me, an FBO is just a pointer to memory, and when the image is drawn, the memory is already written to, so there is nothing left to do?