[sldev] Reformatting Textures for the cache

Skal Tura skaltura at gmail.com
Thu Mar 22 00:38:39 PDT 2007


Dzonatas wrote:
> I see some have suggest to store the textures in a different format.
>
> What I suggest is to store the textures in a minimal format, like if the
> texture normals takes 102Kb to store then squish it down to 5Kb. That
> way we can get more textures cache, and we won't be looking at gray
> cities. Yep, they won't be high detail, but they'll give us a nicer view
> quicker.

Effectively making some of the problems even worse, nice!
As a surplus element of destroying the idea of cache :)

1Gb = 1024Mbytes = 1048576Kbytes
With 70Kbytes average per texture: 14979 textures can be stored.

Now i wonder do i want to wait every and single time for decoding, then
fetching the textures
from server and again decoding ...

Now what would actually benefit? Store them as raw, uncompressed data or a
format which is
faster to decode :) Or actually make the system use the resources available,
which it doesn't
right now. (CPU time Very rarely hits 100%, and often 1Gb of free ram etc.)

I wouldn't mind having a 10Gb cache, if it would be any help at all.
As it is currently, decoding anyways takes so much time that cache doesn't
really matter,
to me atleast.


As for not emptying texture cache from memory when teleporting etc. This
shouldn't be so
hard to do, a basic idea would be store for each texture MD5 hash, last
accessed and accesses total in this session, and use that data to decide
which textures to scrap from
memory IF user specified maximum memory usage limit is reached.

Don't know, is there multiple decoding threads being ran simultaneously? If
not, there should be, just make even upto 32 threads or so, and either make
them lower priority or start new threads if CPU usage below 100%... Making
usage of both might be a safe bet :)

And do remember that we will at some point see over 100 cores per cpu and
that you don't need a core for each thread ;)

Your idea would be good if hdd space was a limiting factor, what it really
isn't.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070322/e4455e26/attachment.htm


More information about the SLDev mailing list