LPC2478 arm7tdmi 56mhz 8kb cache 32mb ram, jpeg decoding performance
Branimir Maksimovic
processor and jpeg decoding performance.
Friend of mine asked me if I can make assembler program for jpeg
decoding as he said open source c programs for jpeg decoding (from jpeg
site and what he can find) does not give satisfying performance.
He said decoding 800x600 jpeg pictures is very slow.
It would be hobby project for me (learning asm for arm7
architecture)
What can I expect? Is it possible to get significant speed
boost in assembly?
Compiler used is gcc for c programs.
Thx, Branimir.
Herbert Kleebauer
> Im interested if someone has experience with this controller or
> processor and jpeg decoding performance.
>
> Friend of mine asked me if I can make assembler program for jpeg
> decoding as he said open source c programs for jpeg decoding (from jpeg
> site and what he can find) does not give satisfying performance.
> He said decoding 800x600 jpeg pictures is very slow.
Take a look at http://www.bitlib.de/pub/jpeg/pfp.zip
There is a C source of a very simple jpeg decoder. The debug
version (pfpdebug.c) has some loops unrolled so it is, at least
on a 486, faster (this may depend on the CPU and compiler used).
> It would be hobby project for me (learning asm for arm7
> architecture)
Good luck. I don't think the ARM instruction set was designed
for assembly programming.
> What can I expect? Is it possible to get significant speed
> boost in assembly?
If you really try it, please report your results.
Branimir Maksimovic
>> boost in assembly?
>
> If you really try it, please report your results.
Thank you very much!
Branimir Maksimovic
> Branimir Maksimovic wrote:
>
>> Im interested if someone has experience with this controller or
>> processor and jpeg decoding performance.
>>
>> Friend of mine asked me if I can make assembler program for jpeg
>> decoding as he said open source c programs for jpeg decoding (from jpeg
>> site and what he can find) does not give satisfying performance.
>> He said decoding 800x600 jpeg pictures is very slow.
>
> Take a look at http://www.bitlib.de/pub/jpeg/pfp.zip
>
> There is a C source of a very simple jpeg decoder.
Thank you! Because I have 64kb of high speed cpu access
memory, to put there code, data and stack.
SDRAM of 32 MB is on external controller which is something
like usb key ;)
>
> If you really try it, please report your results.
I will if we don;t succeed to achieve time of 5 seconds per
picture.
Damn external memory ;)
Greets!
Herbert Kleebauer
> >> He said decoding 800x600 jpeg pictures is very slow.
>
> I will if we don;t succeed to achieve time of 5 seconds per
> picture.
>
> Damn external memory ;)
5 seconds for one 800x600 jpeg? There must be some infinite loop
in the code.
Alexei A. Frounze
5 secs for a 800x600 pic at 56MHz is ~600 clocks/pixel. A lot, but not
insane. I'd suggest to look into the algorithm/implementation and
memory I/O. Perhaps some reordering/caching and algo/impl improvements
can help.
Alex
Rod Pemberton
news:hd5sr3$coi$1...@news.eternal-september.org...
> ... he said open source c programs for jpeg decoding (from jpeg
> site and what he can find) does not give satisfying performance.
"JPEG image compression FAQ" listed a few packages. Has he tried them?
I've corrected the non-working links. The first two are just different
packaging.
From the Independent JPEG group:
http://www.ijg.org
http://www.ijg.org/files/jpegsr7.zip
http://www.ijg.org/files/jpegsrc.v7.tar.gz
ljpg
ftp://ftp.cs.cornell.edu/pub/multimed/ljpg.tar.Z
From Stanford mirror, JPEGv1.2.1.tar.Z:
http://peipa.essex.ac.uk/ipa/src/formats/jpeg/stanford/
http://peipa.essex.ac.uk/ipa/src/formats/jpeg/
Supposedly, the IJG djpeg is quicker, but it's a much larger package than
ljpg.
Rod Pemberton
Branimir Maksimovic
Os was dumped. When you do memcpy in linux buffer, you can see lines
comming out on LCD!
Actuall speed is 30 sec per 800x600 picture when executing from
external SDRAM ;)
So we have 512k flash rom and 64kb of ram free on local bus.
So task is to do maximum operations in that ram and
minimise use of 32 MB of sdram.
I think any algorithm will do, shorter the better.
Greets!
Branimir Maksimovic
>
> Supposedly, the IJG djpeg is quicker, but it's a much larger package than
> ljpg.
>
Thank you.
Greets!