Threaded View

Update of FB attached texture is ultra-expensive

Hi All,

I have recently experienced something I want to share with the community...

Well, it is well known that textures attached to a framebuffer object should not be updated using glTexSubImage*(). Simon Green mentioned in his presentation for the GDC 2005: "Try to avoid modifying textures used as rendering destinations using TexImage, CopyTexImage etc." But how bad is this?

I've been developing a terrain engine for years. There is a well defined texture update procedure using glTexSubImage3D(), since texture arrays are used. Everything worked perfectly. But I wanted to add copping form one layer to the other. That involved FBOs usage. After the first successful start of the application (should I mention that nothing works at first start ) a tremendous slowdown shocked me. My first guess was frequent texture attachments caused it, but making multiple FBOs (one for each layer) and attaching texture at the initialization time didn't change anything. Frame rendering time didn't changed (about 18-20ms, GPU time on my laptop with 8600M), but the application was almost frozen. After moving probes through the code, I finally found the problem. Texture update! Believe it or not, update time increased 5 orders of magnitude. Instead of 0.035ms, update time jumped to 109-192ms.

Maybe I'll try to update some temporary 2D texture with glTexSubImage2D() and then draw part of it in the FBO for a particular layer, but it will be probably slower than it is now (without FBOs).

In the meantime, could anyone shade some light on the problem of ultra-expensive texture update if it is attached to a FBO?