[sldev] Texture caching, pipeline, memory

[Dzonatas]

Good point to wait to the next branch, like 1.15 to implement newer 
texture cache and pipeline renderer.

One thing of note is that when SL started, it was mainly accessible to 
those who had fast DSL lines. The general public at the time didn't have 
fast DSL. It wouldn't even support dial-up. However now, I see LL saying 
that it needs to support win 98 and computer with only 256Mb.  I just 
went priced systems last week and a PC with at least 1GB mem, 3.06Ghz+, 
200GB drive, Gforce 7 series, and built-in surround sound can be had for 
less than $500. I didn't include the monitor in that and meant to keep 
it a sepate issue. That's a pretty decent system to have at the price. 
Unless your strapped for money, it is very affordable. I think that is 
the base system we should shoot for and give up the win 98, 256Mb, with 
50GB hard drive.

In about 5 years, I believe the video card won't be as big as it is 
today. It is already touted and planned to have multi-core processors on 
the desktop. The only reason that they kept the multi-core technology 
held back today is because programs wouldn't make much use of them. 
Also, AMD is going with the hybrid multi-core and graphics-core, and 
intel is set out to make new parallel processor instructions. These are 
factors to consider to know what direction is worthwhile.

I believe memory and matrix math is something we surely won't need to 
stress about in 5 years. 32 bit processors will max their linear memory 
at 4GB and force the new wave of 64 bit computing. As soon as people 
start to demand more than 4GB memory, 32 bit systems are going to be 
hecka cheap.

Like ZOMG, i see these littel iPod and MP3 players with more GBs of 
memory than your typical desktop computer. People are going to start to 
wonder why!

I hope LL accepts patches from us to optimize and nitpick the hell out 
of the 1.14.x branch. For the 1.15 branch, assume at least 1GB of memory 
can be dedicated to SL.

I've seen some of the cutting-edge graphics drivers, and they are 
already far ahead on the multi-core/multi-thread issues.

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/
>>>>   
>>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>
>

--