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 _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges