On Wed, Mar 20, 2002 at 09:44:22PM +0000, Keith Whitwell wrote:
> Michael also implemented agp support for radeon with a similar simplistic
> strategy, but ran into some issues looking at tcl and/or mesa-4-0. I think
> these turned out to be artefacts rather than anything serious. In any case I
> think he decided to wait on some forthcoming reorganization of the texture
> management code in all the drivers... (nudge nudge, wink wink)
Currently I'm doing this
a) Add textures to card local unless 'useagp' is true (and user wants agp
texturing - not implemented this yet)
b) If we need to swap out textures
i) If there are old texture(s) that weren't used on the last frame
swap them (i.e current LRU)
ii) Otherwise, set the useagp flag, swap textures from the front of
the list (utah-glx + agp, if you do use agp, you don't actually
swap)
c) At swapbuffer time, reset useagp flag if texture bytes used this frame <
texture bytes used previous frame.
d) At BindTexture , if the texture is resident in agp and the sum of
it's size and the texture space we used on the last frame < the amount
of card local mem we've got and useagp is false, swap it out of agp (i.e
try to detect when we no longer need agp textures for overflow and get
them put back in local card)
It seems to work quite well with limited testing so far.
In RTCW, high textures, quite a few places on the maps drop to 5 or 6
fps. This gets closer to the frame rates that using normal textures gets
(not using agp and some of those 5fps get to ~20fps, a win, but it's
still swapping a lot of textures). AGP seems a big win over swapping
from either end of the list (although it might be possible to improve
the uploading so the MRU case is better?)
I'm fine tuning things at the moment (It seems too aggressive at
swapping textures back in from agp)
Comments welcome on the approach.
> Anyway, it sounds like this has now been done twice: maybe someone should
> commit something...
I'll post some code tomorrow, just need to tidy it up and make
the agp->local mem a bit smoother.
--
Michael.
_______________________________________________
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
