[sldev] Multithreading, Garbage collection, Caching

[Strife Onizuka]

A couple years ago I came across a comparison of several different JPEG2000
Codecs. Kakadu scored the worst. I've seen bits of the Kakadu change log and
it has improved drastically since that comparison.
http://www.compression.ru/video/codec_comparison/jpeg2000_codecs_comparison_en.html

On 3/18/07, Douglas Soo <doug at lindenlab.com> wrote:
>
> The KDU time-slicing functionality is a bit of functionality that I hacked
> on top of the Kakadu decoder - it took a minor bit of work (a day or two)
> to do so - it may take the same amount of effort to do the same with
> OpenJPEG.
>
> Unfortunately for us, thread schedulers seem to run at a coarse enough
> granularity on most OSes (10ms or greater) such that you essentially have
> to do cooperative multithreading if you're going to get any sort of
> consistent frame rate when you have more threads than CPUs - that's why we
> have the slightly misnamed "Run Multiple Threads" switch - it probably
> should be "Run Multiple Threads Simultaneously" or "Use Multiple Cores",
> really.
>
> OpenJPEG when I last touched it (a few months ago) was around an order of
> magnitude slower than Kakadu for decoding JPEG2000 - which is about the
> same as when I first evaluated them in 2001 (and chose to use Kakadu).
>
> It is likely that that is why the OpenJPEG thread is always churning -
> Kakadu eventually finishes decoding all the textures to an "acceptable"
> level of quality - it may be the case that OpenJPEG never works its way
> all
> the way through all of the textures.  Or, there could be a bug somewhere
> as
> well?
>
> It seems like some of you guys are working on improving this state of
> affairs?
>
> - Doug
>
> --On Sunday, March 18, 2007 4:51 PM -0500 Callum Lerwick <seg at haxxed.com>
> wrote:
>
> > On Sun, 2007-03-18 at 15:57 +0100, Dale Glass wrote:
> >> В сообщении от 18 марта 2007 14:59 Laurent Laborde
> >> написал(a):
> >> > As far as i know, the JPEG2000 decoding cost a lot of cpu time in
> >> > SL. What about multithreading this ?
> >
> >> It already is.
> >
> > This is one of the improvements of the First Look codebase. Its the only
> > way OpenJPEG is usable, as KDU apparently has a feature where you can
> > tell the decode thread to run for a number of milliseconds and return
> > whether or not the texture is fully decoded.
> >
> >> Image decoding seems to be in a separate thread. But that's not as
> >> much of a benefit as you'd think, as the client is not constantly
> >> decoding stuff, only while loading new data.
> >
> > Actually with OpenJPEG in a busy area, it seems to work nonstop. I don't
> > know if this is just OpenJPEG being slow or a bug as well. I suspect
> > that the "texture swappyness" tuning is completely non-optimal for
> > OpenJPEG. Does swapping texture detail levels in and out of OpenJPEG
> > cause j2k re-decodes? That may be what I'm seeing.
>
>
>
> --
> Douglas Soo
> Studio Director
> Linden Lab
> 1100 Sansome
> San Francisco, CA 94111
> doug at lindenlab.com
>
> _______________________________________________
> Click here to unsubscribe or manage your list subscription:
> /index.html
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20070318/39b0add4/attachment-0001.htm