On Mon, 13 May 2002, Keith Whitwell wrote: > 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. 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. To see this > > happening, you can enable the Print[Global,Local]LRU functions in > > UpdateTexLRU, restart X, then repeatedly start, stop and restart the > > texenv Mesa demo. Each time you restart, you'll see a new placeholder in > > the local LRU if the problem is there. If I'm right, this should be > > happening in all the drivers. Can someone test this on the Radeon driver? > > > > > > 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? > > Also note that the space can be taken even if it isn't freed, for the reasons > I described in the previous email. >
I understand that, but my issue was that it's only freed when the heap fills up. If the global LRU card heap is full except for the last region, but the texture we're uploading is larger than that, we could end up switching to AGP memory, even if there was space no longer in use by another context in card memory. Depending on the size of the AGP aperture and the texture requirements of the app, you might end up never freeing the card memory until an app runs that has a texture that can go into the last region. If you know that the space is free as soon as the other context stops using it, there would be less potential for wasted card memory. -- Leif Delgass http://www.retinalburn.net _______________________________________________________________ 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
