[sldev] Texture caching

Steve steve at lindenlab.com
Tue Mar 20 19:10:51 PDT 2007

You would have to remove that line from teleporting (which should be 
fine), and bump up that time to say 3 minutes. Don't remove it entirely 
or you will have a massive memory leak. For the specific case of 
teleporting between regions with similar textures it might help. Let me 
know if it does, I would be happy to consider applying that change 
sometime after 1.14.0 ships.


Tateru Nino wrote:
> From the other side of the world it might be a lot more typical ;) I'm 
> curious as to the impact of maxing the 30 second bias configurable. Or 
> simply commenting that one line out of the teleport sequence. Or both.
> Steve wrote:
>> It's possible that the teleport delay is long enough that all of the 
>> textures get tossed out. This is not a typical situation so we have 
>> not actually tested it very much.
>> Tateru Nino wrote:
>>> Steve wrote:
>>>> Hi folks. Good to see other people looking at the texture pipeline 
>>>> quagmire. Some notes for you all:
>>>> 3. Even if a textures pixel coverage gets set to 0, we do not 
>>>> immediately discard the texture data. We only discard the data if 
>>>> we need room for more textures (in which case we discard the 
>>>> textures with the lowest priority), or if no object in view is 
>>>> using the texture *and* 30 seconds have elapsed.
>>>> 4. Tateru is absolutely correct in that caching textures to disk 
>>>> mostly just saves on network bandwidth. Unless you have a slow 
>>>> network connection, it can be almost as fast to load textures 
>>>> across the network as from a disk, especially if that disk is not 
>>>> especially fast or is fragmented. Decoding the textures takes quite 
>>>> a bit longer. However, if you have multiple CPUs and enable Client 
>>>> > Rendering > Run Multiple Threads, the decoding will be done on 
>>>> the second CPU and go much faster.
>>>> 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.
>>> Actually if you teleport from a simulator where the area around you 
>>> is built with a particular set of textures, and you teleport to 
>>> another sim, using those _same_ textures, you're pretty much 
>>> starting from scratch. Or if you teleport out and back in under 30 
>>> seconds.
>>> That's what actually got me thinking about this in the first place. 
>>> During one of my daily sets of rounds in SL, I teleport from site to 
>>> site where each site is, essentially, a duplicate - Some different 
>>> prim-work. Same textures. I'd arrive and think...why are these prims 
>>> all grey? But there they were, loading from the disk.
>>> Is the teleportation interval sometimes more than 30 seconds itself, 
>>> counting for discard bias?
>>> -- 
>>> Tateru Nino
>>> http://dwellonit.blogspot.com/

More information about the SLDev mailing list