[sldev] Multithreading, Garbage collection, Caching

[Douglas Soo]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.secondlife.com/pipermail/sldev/attachments/20070318/c4ada1c1/attachment.pgp