On Sun, 12 May 2002, Keith Whitwell wrote:
> > > Just a small expansion on this. The texture management solution is
> > > weak. If two clients each had a small texture, it would be quite
> > > possible that they both would have fit in texture memory and no texture
> > > swapping would be required. Doing that would have required more advanced
> > > texture management that realized certain regions were in use by one
> > > client or another. We still don't have that yet. In a grand scheme
> > > regions of texture memory would be shared between 2D and multiple 3D
> > > clients.
>
> We have this for other drivers - there's a linked list of regions in the sarea
> that let drivers know for each 'chunk' of texture memory whether it has been
> stolen by another client or not.
>
Good timing, I was just composing a message about this. Maybe you can
help me...
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.
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?
I've also found what looks to me like a bug in the Rage128 driver in
UploadTexImages. The beginning of the function does this:
/* Choose the heap appropriately */
heap = t->heap = R128_CARD_HEAP;
if ( !rmesa->r128Screen->IsPCI &&
t->totalSize > rmesa->r128Screen->texSize[heap] ) {
heap = t->heap = R128_AGP_HEAP;
}
/* Do we need to eject LRU texture objects? */
if ( !t->memBlock ) {
Find a memBlock, swapping and/or changing heaps if necessary...
}
Update LRU and upload dirty images...
The problem I see here is that setting t->heap before checking for an
existing memBlock could potentially lead to a situation where t->heap !=
t->memBlock->heap. So in my code I've deferred changing t->heap = heap to
inside the 'if' block where we know there is no memBlock. Again this
situation can only occur if there is an AGP heap. Is there a reason for
this behavior in the Rage128 code that I'm missing, or is this a bug?
--
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
