[sldev] Texture caching

[Tateru Nino]

Well, I'm sans a functioning build environment at the present time. 
Anyone want to try this and report?

Steve wrote:
> 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.
>
> -Steve
>
> 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/
>>>>   
>>
>

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