st/mesa: fix texture deallocation bug
authorBrian Paul <brianp@vmware.com>
Tue, 2 Feb 2010 02:04:16 +0000 (19:04 -0700)
committerBrian Paul <brianp@vmware.com>
Tue, 2 Feb 2010 02:04:16 +0000 (19:04 -0700)
commitbdf975e9ad25ee65d796a3c1ce3f2afbd2889c4e
treebf4490e93f71642dc0965de15cafe71a937cffdd
parent04b14e26a24f824ce63c2398665e173d563f0b24
st/mesa: fix texture deallocation bug

This fixes a bug reported by Christoph Bumiller on mesa3d-dev.

When a texture is first created as RGBA, then re-defined with
glTexImage(internalFormat=GL_DEPTH_COMPONENT) we failed to deallocate
the original texture.  When this texture was bound as a FBO surface,
the depth/Z surface format was RGBA instead of Z.  Depending on the
driver this led to a failed assertion or FBO validation failure.

This patch does three things:

1. Remove ancient code that mysteriously tested if we were replacing
the smallest mipmap level and tested if the texture was not a cube map
texture.  I can't see any reason for those tests.

2. Move the width=height=depth=0 test to after the code which frees
texture data.  Calling glTexImage with width=height=depth=0 and data=NULL
is a way to free a single mipmap level.

3. Update the code comments.

There are no apparent conform, glean or piglit regressions from this change.

(cherry picked from commit 43e4b584227534e30e487e7fb7e99d6501cbcd85)
src/mesa/state_tracker/st_cb_texture.c