On Mon, May 13, 2002 at 04:06:53PM -0400, Leif Delgass wrote: > On Mon, 13 May 2002, Ian Romanick wrote: > > > On Sun, May 12, 2002 at 06:18:58PM -0400, Leif Delgass wrote: > > > > > In working on AGP texturing for mach64, I'm starting from the Rage128 > > > code, which seems to have some problems (though the texture aging problem > > > could affect other drivers). My understanding is that textures in the > > > global LRU are marked as "used" and aged so that placeholders can be > > > inserted in a context's local LRU when another context steals its texture > > > memory. The problem is that nowhere are these texture regions released by > > > the context using them. The global LRU is only reset when the heap is > > > full. So the heap has to fill up before placeholders begin to get swapped > > > out. I've seen this when running multiple contexts at once, or repeatedly > > > starting, stopping, and restarting a single app. This isn't a huge > > > problem with a single heap, but with an AGP heap it means that card memory > > > is effectively leaked. Once the card memory global LRU is nearly filled > > > in the sarea with regions marked as "used", newly started apps will start > > > out only using AGP mem (with the r128 algorithm). Only if the app uses > > > enough mem. to fill AGP will it start to swap out the placeholders from > > > the local LRU and use card memory. > > > > If this is true, then I believe it is a bug in the r128 driver. IIRC, all > > of the space in the global texture heaps is freed when the context is > > destroyed. This is the way that the Radeon and MGA drivers work. The r128 > > driver follows the same model so it is /intended/ to work the same. > > It looks to me like this is a bug in all the drivers. Try grepping for > 'in_use' in the Mesa drivers. I don't see anywhere in _any_ of the > drivers where a context sets in_use to zero in a texture region in the > global heap.
Ah yes, in_use. That field is defunct. Texture regions are stolen on a pure priority basis. No distinction is made between regions owned by the current context or other contexts. > The local heap is destroyed when the context is destroyed, > but it doesn't touch the global heap. There are only two places where the > global LRU is modified. One is in UpdateTexLRU where the region is marked > as in_use, aged, and moved to the head of the list. The second is in > ResetGlobalLRU, where the list is (re)built and ages are reset. The Reset > function is only called from AgeTextures when the heap is full (which it > can detect because the Reset function leaves out one region when > rebuilding the list), which also forces TexturesGone to swap out > everything in the heap, including all of the placeholders. Hrm...ok. I'll look into this a bit tomorrow and get back to you. Your reasoning seems good, but for some reasons it doesn't grok with what I remember. It's been awhile since I've looked at this code, so my memory might not be so good. :) > > > One possible solution I'm playing with would be to use a context > > > identifier on texture regions in the global LRU rather than a boolean > > > "in_use" (similar to the ctxOwner identifier used for marking the last > > > owner of the sarea's state information). Then when a context swaps out or > > > destroys textures, it can free regions that it owns from the global LRU > > > and age them so that other contexts will swap out their corresponding > > > placeholders. The downside is an increased penalty for swapping textures. > > > Another problem is how to reclaim "leaked" regions when an app doesn't > > > exit normally? > > > > This is not needed. When texture space is freed in the global heap by one > > context, the other contexts will see that the state of those blocks in the > > global heap has changed from owned to free. > > This is assuming that the space is actually freed. Maybe it wouldn't be > necessary if you only swap or destroy textures when holding the lock. Is > DestroyContext called while holding the lock? The DestroyContext function in the driver is. It mucks around with the SAREA, so it had better be! :) [snip] > I understand the algorithm, that's not the problem -- it's the _second_ if > block. My point is that if, at the beginning of the function, the texture > is already allocated on the AGP heap (t->heap == t->memBlock->heap == AGP) > and is small enough to fit card memory, t->heap is changed to the CARD > heap unconditionally by the first line. However, since the texture > already has a memBlock in AGP, the second if block is not entered and > memBlock remains on the AGP heap, so t->heap == CARD, but > t->memBlock->heap == AGP. I'm saying that t->heap should only be changed > to the CARD heap if it doesn't already have a memBlock (i.e. it's new or > has been swapped out). Right. Currently, there is no promotion of textures from AGP to on-card memory. This is one piece of work that, after getting my initial patches in (sigh...), I had intended to do. -- Tell that to the Marines! _______________________________________________________________ Have big pipes? SourceForge.net is looking for download mirrors. We supply the hardware. You get the recognition. Email Us: [EMAIL PROTECTED] _______________________________________________ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
