Hi All,
I have done some benchmarking on OMAP4 running Ubuntu for various versions of libjpegs. Benchmarks were collected with modified version of djpeg that prints out ms time taken for decoding. Sample used for benchmarking is a 12MP image downloaded from a photography website. Here are the results:
*Non Optimized libjpeg-turbo(5 runs):* Decoding Time for Run 1: 2022 ms Decoding Time for Run 2: 2029 ms Decoding Time for Run 3: 2165 ms Decoding Time for Run 4: 2027 ms Decoding Time for Run 5: 2150 ms * Median Decoding Time: 2029 ms*
*Linaro's NEON Optimized libjpeg-turbo done in last cycle (5 runs)* http://git.linaro.org/gitweb?p=people/mandeep-ti/libjpeg-turbo-1.1.0_linaro.... Decoding Time for Run 1: 1634 ms Decoding Time for Run 2: 1634 ms Decoding Time for Run 3: 1636 ms Decoding Time for Run 4: 1739 ms Decoding Time for Run 5: 1738 ms * Median Decoding Time: 1636 ms* *Mans Rullgard's libjpeg based of libjpeg 6b (5 runs)* http://git.mansr.com/?p=libjpeg%3Ba=summary Decoding Time for Run 1: 1101 ms Decoding Time for Run 2: 1081 ms Decoding Time for Run 3: 1081 ms Decoding Time for Run 4: 1125 ms Decoding Time for Run 5: 1089 ms * Median Decoding Time: 1089 ms
libjpeg-turbo trunk version that has NEON patches (5 runs). * http://libjpeg-turbo.svn.sourceforge.net/viewvc/libjpeg-turbo/* * Decoding Time for Run 1: 1068 ms Decoding Time for Run 2: 1065 ms Decoding Time for Run 3: 1093 ms Decoding Time for Run 4: 1066 ms Decoding Time for Run 5: 1067 ms *Median Decoding Time: 1067 ms*
So basically libjpeg-turbo as of now is pretty much as optimized as anything out there. As a part of my last cycle work I also produced additional color conversion routines that I will submit to libjpeg-turbo project after that libjpeg-turbo should be best library to go (given that it is also highly optimized for Intel processors).
Thanks & Regards, Mandeep * *
On 24 June 2011 17:09, Zach Pfeffer zach.pfeffer@linaro.org wrote:
We've got a BP for this:
https://blueprints.launchpad.net/linaro-android/+spec/linaro-android-try-lib...
On 23 June 2011 03:30, Alexander Sack asac@linaro.org wrote:
On Thu, Jun 23, 2011 at 3:30 AM, Christian Robottom Reis kiko@linaro.org wrote:
Hi there,
I took a look at the AOSP libjpeg code which is included in
git://android.git.kernel.org/platform/external/jpegduring my flight back home (which incidentally had been diverted and landed me in Rio de Janeiro; not sure if I celebrate or cry) and noted the following things:
There is a v6 implementation of the fast IDCT algorithm which lives in armv6_idct.S.
The commit which adds this implementation was added October 2010, and there haven't been any changes since.
The code that selects the decoder IDCT implementation in jddctmgr.c always uses that implementation if ANDROID_ARMV6_IDCT is defined.
Google have an "ashmem" backing store implementation, and have code to enable tile-based mode. It's a fairly non-intrusive change to use ashmem since it just replaces jpeg_open_backing_store.
The code is pretty much standard libjpeg without any structural changes to it.
There isn't any NEON code in this branch.
Mans has an optimized version here:
http://git.mansr.com/?p=libjpeg%3Ba=summary
I don't know if he's submitted this to AOSP or not.
This suggests to me that a simple drop-in of libjpeg-turbo might be actually easy to do, and that there is probably a significant performance benefit to be achieved. One thing to keep in mind is that this code still supports armv6, so we'd probably want to preserve that.
sounds good. Seems like a great starter project for MM WG to get their hands dirty on android.
They could have three builds:
- plain LEB
- LEB with mans optimized libjpeg
- LEB with libjpeg-turbo
Then benchmark all three and keep AOSP community posted on our intent, progress and results.
--
- Alexander