Leif Delgass wrote:
On Fri, 31 Jan 2003, Ian Romanick wrote:Leif Delgass wrote:I see the problem you're talking about here. You are correct. I misunderstood where you meant to set t->heap to heap. I now see that you meant to set it after the CALLOC in the 'if ( in_use )' block. Duh. :)There are also a few failing assertions related to placeholder texture objects. In driTexturesGone, we need to set t->heap = heap or else the assertion that t->heap != NULL fails in driDestroyTextureObject when destroying a placeholder.
Right. I should have been more specific there (the actual patch would have been more clear ;) ). Do you see what I mean now about the
Yeah. You know what they say...a patch is worth 2^10 words. :)
assertions on tearing down the context? A placeholder _does_ have aPart of the confusion was over "placeholder." There is a dummy object bound to each texture target (see driInitTextureObjects in texmem.c, line ~908). When you said placeholder, this is the the object that my brain thought of. You are correct.
memBlock, which matches the corresponding global region marked as in use. It's in the same block you refer to here that it's added to the
texture_objects list. Also, a placeholder can be moved to the
swapped_objects list in driAllocateTexture (another place an assertion can
fail in driSwapOutTextureObject if the placeholder's t->heap == NULL). The driver's DeleteTexture callbacks on teardown won't remove any
placeholders from these lists, just the "real" textures that have
corresponding gl_texture_object structs (t->tObj).
The objects that are actually called placeholders can be on the the texture_objects list, but I don't think it should ever be on the swapped_objects list. It seems illogical that one process would track the textures in another process that were kicked out. That's just silly. That said, it does seem that this will happen. It seems like this could be a memory leak. The placeholder textures on the swapped_objects list will just sit there until the context is destroyed.
I think we need to add a flag to dri_texture_object that says "this is a placeholder." If an object is a placeholder, it does not get put on the swapped_objects lists. Instead, it gets destroyed. That flag could also be used to help implement the optimization you were talking about in an earlier message.
After looking at all the code, I couldn't understand why none of those assertions were never triggered. Here's the coup de grace: radeonDestroyContext never gets called. I tried a bunch of different things, but if I set a breakpoint after hitting the _mesa_test_os_sse_exception_support signal, my breakpoint never gets hit.
I'm going to have to investigate this some more...
-------------------------------------------------------
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
