Brian Paul wrote:
Crap. I missed an aspect to this. The texmem manager explicitly free's the data pointed to by texObj->DriverData when the texture's swapped out of VRAM.
I'll fix things up ASAP.
OK, I think I've got it right now.
A longer term issue is still open: Do we really want to delete the driver data hanging off texObj->DriverData when we swap out a texture? Wouldn't it be better to simply mark it as swapped out?
Okay, DriverData just points to the driTextureObject associated with the texture (the gl_texture_object). The only time when that gets deleted is in driDestroyTextureObject. That is only called from the driver's DeleteTexture handler or when a "dummy" texture is being swapped out. The "dummy" textures are used for the regions of memory owned by some other process / GL context.
That said, something is still wrong because the assertion in r200DeleteTextures fails in glxinfo when the context is destroyed. There seems to be some funny interaction between driInitTextureObjects and NewTextureObject. I suspect we could eliminate the need for driInitTextureObjects by having r200NewTextureObject call r200AllocTexObj. That would make r200BindTexture a no-op (or just 'assert(texObj->DriverData != NULL)' in the first if-statement).
I'll have to look at it more tomorrow.
------------------------------------------------------- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn -- _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
