Erik,
First of all, thanks for your message. I entirely agree on every word of what
you said. If you think there is something we can do to persuade Intel on how
useful it is for the SA community to have access to the IPP library source code,
please let me know.
Paco.
> On Thu, Mar 15, 2001 at 03:25:46PM +0100, Francisco Gómez-Molinero wrote:
> > We are working with the SA1110 for image processing applications. We
> > have come across the performance library of Intel. Although the
> > primitives in the library give good performance, they are very much
> > oriented to implementing image decompression. Is anybody out there
> > working in image compression primitives for the SA and willing to share
> > experiences? In particular, is any forward DCT application available
> > somewhere?
>
> We have discussed the IPP (Intel Performance Primitives) library on the
> Intel StrongARM Linux summit in New York, and according to a lot of
> people the IPP library is potentionally useful, but comes with the
> wrong license that makes it incompatible with GPL'ed programs. I think
> we convinced the Intel handhelds division (the guys behind the
> StrongARM and XScale) to release the IPP library with source code under
> a more open license, but so far we have failed to convince the people
> behind the library itself.
>
> Of course the usual Open Source arguments apply to this library, but
> there are some more:
>
> - Intel's core business is to sell CPUs. Selling more CPUs means more
> money for Intel. If there is software that makes a CPU more useful,
> give it away.
> - Giving away the library is good for Intel's PR. Yes, there is a risk
> that the library will be ported to non-Intel CPUs, but there is still
> "Intel" in the name of the library.
> - You can't trust the results from closed source software. I've seen
> this more than once: we upgraded a closed source image processing
> package, and couldn't reproduce our results. Quite an embarrassing
> experience from a scientific point of view. The IPP library is closed
> source, so it can't be used in *any* academic environment.
> - To be useful in an academic environment, I also miss implementation
> details. For exmple, what's the noise that each function adds? How is
> it implemented? There are quite some ways to implement a certain
> algorithm, and there is no way for me to find out if Intel used the
> smart way. For an example, read about "random number generators" in
> "Numerical recipes in C".
> - Intel claims to have the smartest algorithm designers on the planet.
> We think we can prove them wrong with our FFT implementation. I am
> from a video processing group and we have quite some good algorithm
> experts as well. I'm sure your group also has some. Intel should
> *use* the knowledge from those people by giving away the IPP source
> and let people contribute to it. For a business case, ask Compaq
> about running Linux on the iPaq.
> - In some cases you can gain quite some speed by folding some
> algorithms together into a single function. For example: in RF
> channel coding, where the combination of the error correction encoder
> with the first stage of the FFT can pretty much make the ECC function
> "free" as loads, stores and cache reloads are eliminated. Same for a
> H.263 decoder: folding the YUV-->RGB mapping and RGB-->palette
> mapping into a single function made the decoder four times as fast
> because we could *calculate* the correct palette entry instead of
> having to use two lookup tables (that trashed the cache).
>
> Wookey, Nicolas Pitre and me tried to convice Stewart Taylor (one of
> the IPP head architects) after his presentation on Linux World Expo,
> and we are currently trying to get in touch with the IPP people
> directly, but they are quite hard to reach.
>
> Anyway, to answer your original question: I am not aware that there is
> an optimised forward DCT library. If the source was available, you
> could have used the IDCT function as a skeleton for a DCT function and
> contributed your code back to Intel. Now you have to write it yourself
> from scratch. I'd call this a loose-loose situation.
>
> Erik
>
> --
> J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
> of Electrical Engineering, Faculty of Information Technology and Systems,
> Delft University of Technology, PO BOX 5031, 2600 GA Delft, The Netherlands
> Phone: +31-15-2783635 Fax: +31-15-2781843 Email: [EMAIL PROTECTED]
> WWW: http://www-ict.its.tudelft.nl/~erik/
--
-----------------------------------
Paco Gomez-Molinero
Technical Director
Visual Tools S.A.
Xaudaro, 13 bis
28034 Madrid
SPAIN
Tel: +34 91 7294844
Fax: +34 91 3585236
email: [EMAIL PROTECTED]
http://www.vtools.es/
_______________________________________________
http://lists.arm.linux.org.uk/mailman/listinfo/linux-arm
Please visit the above address for information on this list.
