On Thu, 29 Sep 2011 20:54:42 -0600, Brian Paul <bri...@vmware.com> wrote: > On 09/29/2011 08:37 PM, Eric Anholt wrote: > > On Thu, 29 Sep 2011 14:24:46 -0600, Brian Paul<brian.e.p...@gmail.com> > > wrote: > >> From: Brian Paul<bri...@vmware.com> > >> > >> This hasn't been needed so far since none of the core Mesa code paths > >> that call ctx->Driver.AllocTextureImageBuffer() are used with the > >> state tracker. That will change in upcoming patches. > >> Note that this function duplicates some code seen in the st_TexImage() > >> function. That can be cleaned up later. > > > > I'll note that I found it useful within our driver to have > > AllocTextureImageBuffer succeed even if there was data that hadn't been > > Free()d. > > > > If in general Alloc just freed existing memory (or reused it if it was > > well-sized already), we wouldn't need to be so careful about > > FreeTextureImageBuffer()ing in mipmap gen or teximage. Just a thought. > > I'd rather leave it as-is for now. I'll revisit this in the future, > no doubt. > > BTW, one thing I have in the back of my mind is to someday try to > remove the Alloc/FreeTextureImageBuffer() hooks and instead use a > (de)allocator system based on complete mipmaps (see > GL_EXT_texture_storage). I have a patch for that extension that I'm > sitting on until after the current batch of changes is finished.
I'm very interested!
pgphmxJd9Jf5C.pgp
Description: PGP signature
_______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
