Hi
I’m experiencing unreasonable slowdowns using TexSubImage2D. Here is the scenario :
Configuration :
P4 2.4C, Win2000 SP4
Radeon 8500 64MB DDR (built by ATI), Catalyst 4.2
I have a renderable texture class working, implemented without extensions, ie just using the back buffer & CopyTexSubImage. The problem is when I want to clear this texture (eg reset it to black). For this I would like to use TexSubImage2D, but this where problems begin. I use the following code
void CRenderableTexture:: Clear()
{
unsigned char * tex = new unsigned char[4*m_TexWidth*m_TexHeight];
for (int i=0; i<m_TexWidth*m_TexHeight; i++)
{
tex[4*i] = 0;
tex[4*i+1] = 0;
tex[4*i+2] = 0;
tex[4*i+3] = 255;
}
glBindTexture(GL_TEXTURE_2D, m_TexID);
glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, m_TexWidth, m_TexHeight, GL_RGBA, GL_UNSIGNED_BYTE, tex);
delete [] tex;
}
Ok there are some obvious optimizations to make, but wait a minute. I wrote a dummy Clear2 method to see if there is a difference :
void CRenderableTexture:: Clear2()
{
unsigned char tex[4];
glBindTexture(GL_TEXTURE_2D, m_TexID);
glTexSubImage2D(GL_TEXTURE_2D, 0, 0, 0, 1, 1, GL_RGBA, GL_UNSIGNED_BYTE, tex);
}
Now to the figures.
For a 1024*1024 RGBA8 renderable texture:
With no Clear at all : 80 FPS
With Clear used once per frame : 5 FPS
With Clear2 used once per frame: 5 FPS (just as slow, but replacing only 1 texel and no array stuff)
Things get even more funny with a 2048*2048 texture. With the same dummy Clear2 method once per frame, I get around 0.5 FPS.
I’m totally clueless about what’s going on…
Some information about the rendering loop :
begin render to texture (ie set viewport to match renderable texture size & clear backbuffer)
*** clear the texture ***
draw some stuff
end render to texture (ie grab the backbuffer & set the viewport back to match the window size)
draw a screen-aligned quad with the renderable texture
In my app, the texture should not be cleared every frame. I just threw it in to measure precisely how much time it took. In fact, I just want to clear it when the window is resized, but it is so slow that it produces a noticeable delay before the app becomes responsive again.
I am at the point where I start suspecting a driver problem. And even with this in mind, I don’t see why a 1024*1024 texture can’t be updated at reasonable rates (not to mention the 1-texel update which is no faster than the plain replacement of the whole texture).
Thanks for any clue, idea, whatever…