[opensource-dev] Openjpeg/KDU the cold hard metrics

[Robin Cornelius]

Hi everyone

I have been doing some direct comparison between KDU and Openjpeg and
have some metrics to share with the rest of you (in case you have not
seen them already flying around on #opensl/ or AWG chat)

https://spreadsheets.google.com/ccc?key=0AiSrUP47_VxIdFY4Mi1VUkdnaXJsSVpldGRPZXoxc3c&hl=en#gid=0

The tests were done in a test harness using the LLImage class from the
viewer. 296 Typical SL textures which were complete were used, Each
texture was decoded to discard level 0 (fully) and the timing was only
done for the call to decode(). This was repeated 10 times to average
out some CPU load jitter and the results entered on to the
spreadsheet.  I did some variations on openjpeg 1.3 with builds on
VC2005 and 2008 and some different SSE and optimisation settings, I
also did a test with the Openjpeg V2 code from SVN, although I had to
remove 5 textures from the test to prevent this from crashing.

The SSE results are interesting, my CPU is an AMD Athlon II X4 64 bit
quad core but with 2005 and 2008 SSE2 slows down the decode
process,and 2008 also does a better optimisation job than 2005. I'm
still not 100% sure why the build of openjpeg supplied by imprudence
is better than my builds on 2005. I've also not done any tests on
linux, but the basic pattern of KDU being way faster than openjpeg 1.X
and 2.X being faster than 1.X i do not expect to change much, the only
thing that might change is ups and downs for various optimisations and
extra CPU instructions such as SSE behaving differently under gcc.

Openjpeg 2 is really looking like its made a massive improvement in
its speed, but currently its very unstable, as I said it crashes with
5 of my test textures (which appear to be perfectly normal RGBA
textures of common dimensions). Its also crashing with encode for
bakes and as far as i know it has issues/is not complete to handle
truncated streams either, all of which make usage in SL right this
moment not possible.

I think openjpeg 2 is where opensource effort should be directed as
its not _that_ far behind KDU for raw decode speed (compared to OJP
1.X) currently and yes I know the new KDU can use multiple cores, but
so what, we can run multiple decode threads, its nots if we are
decoding a GB image so that extra boost is probably not that
significant for the type of SL usage. So this brings us to the state
of Openjpeg 2.0, Now i know Dzontaz and Callum have done quite a bit
with Openjpeg of various versions in the past, if either of them are
watching do they have any insites to the current state of OJP 2.0 for
SL usage (or does anyone else), as very little has happened in
Openjpeg svn for a long while now I fear if we want this to work we
may have to fix it and supply the patches upstream ourselves. I
believe at one point Dzontas was using OJP 2 for download but OJP 1
for upload when testing it.

Regards

Robin