[sldev] Texture caching

Tateru Nino tateru.nino at gmail.com
Tue Mar 20 18:57:40 PDT 2007


 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/
>>   

-- 
Tateru Nino
http://dwellonit.blogspot.com/



More information about the SLDev mailing list