[sldev] Texture caching
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
>>> 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
More information about the SLDev