[sldev] Re: Reformatting Textures for the cache

[Kamilion]

On 3/26/07, Dale Glass <dale at daleglass.net> wrote:
> В сообщении от 26 марта 2007 11:36 Callum Lerwick написал(a):
> > Is it still not clear that reinventing the wheel here is not a
> > productive idea? Because that's what you're doing. You're
> > reinventing a filesystem on top of a filesystem. Hundreds of
> > thousands of man hours have gone into refining and optimizing
> > filesystem efficiency in Linux and BSD and *cough* other operating
> > systems, based upon decades of accumulated research and experience
> > in the field of computer science.
> I've got to agree here. Writing a good filesystem is a very complex
> task in itself. We're definitely not going to come up with something
> of the quality of say, ReiserFS or NTFS here. Rather it'll be more
> like the VFS: slow, inefficient, and with bugs that pop up once in a
> while.
>
> Once we start working on VFS defragmenters, I think that should be a
> sign that we should consider moving the code into the kernel ;-)

*laughs his ass off* -- Sounds like colinux.
>
> I should also note that most compressed formats like tar and .zip are
> completely unappropiate for the purpose, as their structure doesn't
> allow for efficiently writing to them.
Point taken; modern drives and hardware will only get faster over
time, so simply relying on the filesystem itself to handle the dirty
work and adding a little speedup with the directory splitting should
cover all use cases; I mean, SL FL works pretty freaking good on my
celeron 600Mhz, as long as I've got a decent geforce card in there!
Textures load a heck of a lot faster than the old vfs cache system
ever did. There's also a decent bit of difference if you watch the
difference between the two processes in Process Explorer; the old VFS
system seems to use a lot more kernel time than FL does. Kernel time
is bad -- preemption can only take place in certain places; if at all.
And multithreading is always a good idea; especially since likely
we'll be seeing more and more processors like Cell that SL's
Opensource viewer can/will be ported to/compiled on.

-- Kamilion Schnook