PDA

View Full Version : Fast Way to Clear a Texture



henniman
04-02-2012, 06:24 AM
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
04-02-2012, 09:42 AM
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 (http://www.opengl.org/discussion_boards/ubbthreads.php?ubb=showflat&Number=291934&page=1)

trinitrotoluene
04-02-2012, 10:15 AM
If your gl implementation support timer query (http://www.opengl.org/registry/specs/ARB/timer_query.txt), 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
04-03-2012, 09:36 AM
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_
04-03-2012, 09:55 AM
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
04-03-2012, 05:26 PM
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
04-04-2012, 12:29 PM
why not have a second texture that is already 'cleared' ;p

henniman
04-05-2012, 02:46 AM
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
04-05-2012, 02:47 AM
@dukey: no, the texture comes from a pool to keep gpu memory footprint low

henniman
04-09-2012, 07:54 AM
[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?

Dark Photon
04-10-2012, 05:47 AM
what exactly happens here? What is the pitfall?
We don't know what exactly happens here under-the-hood. It's abstracted. All I'm saying is that the outward behavior is that changing the formats or resolutions that an FBO is rendering to can be (or or at least used to be; haven't reverified recently) an expensive operation. The term often thrown around is there is a lot of driver "validation" for this path, though we don't know how much is validation and how much is just reconfiguring the pipeline (possibly resulting in some pipeline bubbles that wouldn't otherwise have been there).