[sldev] Reformatting Textures for the cache

[Tim Shephard]

I have to say after looking at first look a bit I think a file system
approach is pretty constraining.

That might work for netscape mail or something, but if you're
implementing a complex four level cache (low rez compressed,
compressed, no compression) and you want to read only bits of data at
a time rather than the whole file (or email, in the netscape example),
you may want to open/close that one file many times over before you've
completely used it.

Wouldn't it be easier just to have one big blob that you keep open and
read from different parts at your pleasure without any OS constraints
getting in the middle?

We'll see.  In the current implementation, as Tofu Linden says, we are
CPU bound so there is little chance of straining the file system.   As
far as I can tell, the file system cache is meaningless in the current
implementation .. all it does is save on bandwidth.

I think if we move to a more sophisticated 4 layer cache though,
issues with this approach will start to arise, but until then there is
no reason to be concerned.




On 3/22/07, Tim Shephard <tshephard at gmail.com> wrote:
> On 3/22/07, Jason Giglio <gigstaggart at gmail.com> wrote:
> > Tim Shephard wrote:
> > >> /cache/6c/48/94/6c489466-3058-6475-6b1b-e5fc1d49f1f3.tga
> > >>
> > >
> > > You want to open a file for every texture you need to decode?  Yiiikes.
> >
> > That is how it works now, and it's a lot faster than the crappy VFS.
> > The textures are not relational data, a relational database would be a
> > stupid addition.
> >
> Really?   Yoiks.   Isn't the limit on XP 512 open file handles?   Stay
> away from those big clothing stores I guess..
>