[Mesa-dev] [PATCH 2/2] mesa: remove bogus compressed texture size checks

[Brian Paul]

On 10/02/2012 12:57 PM, Eric Anholt wrote:
> Brian Paul<brianp at vmware.com>  writes:
>
>> A compressed texture image size doesn't have to be a multiple of the
>> compressed block size (only sub-images do).  Fixes issues when building
>> compressed mipmaps because we often wind up with non-block-size images
>> for the higher mipmap levels.
>>
>> Fixes https://bugs.freedesktop.org/show_bug.cgi?id=55445
>
> This patch is:
>
> Reviewed-by: Eric Anholt<eric at anholt.net>
>
> (I haven't thought through the implications of not calling the driver's
> TexImage for 0-sized -- do we rely on anything happening there that will
> get us into trouble at render time if 0-sized is used?)

In this case, prior to calling the ctx->Driver.TexImage() function 
we'd have called ctx->Driver.FreeTextureImageBuffer() to deallocate 
the old image.  So, logically, there shouldn't be any memory allocated 
for the image and the texture would likely be marked as incomplete for 
rendering purposes.

It occurs to me that we could leave dangling (or at least unused) 
texture memory lying around if we set the base mipmap level to 0 by 0 
with automatic mipmap generation turned on.  I believe we should free 
all the higher mipmap levels in that case, but I bet we aren't.  I 
could add a piglit test to explore that someday, but that's not 
important for the issue at hand.

-Brian