[sldev] Texture caching

Jason Giglio gigstaggart at gmail.com
Tue Mar 20 13:58:05 PDT 2007

Steve wrote:
> If you're looking for a problem to solve, I would think about this 
> scenario for a system with 256+ MB texture RAM:
> 1. Log in to region A. Stay there long enough for a bunch of textures to 
> load. Generally this will be < 128MB.
> 2. Teleport to region B and stay long enough for textures to load. Stay 
>  > 30 seconds.
> 3. Teleport back to region A.
> The system will have forgotten about all of the textures in region A, 
> even though it could have kept them around because texture RAM would not 
> have filled up. The reason we don't just keep them around is that it 
> becomes something of a bookkeeping nightmare. If you teleported to a 
> region C in between, the textures in region A would need to be 
> discarded. Also, if region A, B, and C all have a bunch of small 
> textures, we might teleport to regions D, E, and F and never need to 
> discard any of those textures. However, each texture carries additional 
> system RAM and CPU overhead, so tracking tens of thousands of textures 
> is problematic in itself.


I think my goal will help with that.  I believe I mentioned this briefly 
before but I want to replace LRU with ARC.  ARC can make better choices 
about what textures to retain.  It is better than LRU under just about 
any workload, with no performance tuning needed.  Cache hit rates can be 
increased by 100% or more!

As a first step toward this I plan on adding cache hit rate tracking so 
we have a metric to work against to measure performance gain or loss.


More information about the SLDev mailing list