A few remarks about IPP

[marc_ba]

Hello there,

I've been using and testing IPP (video coding) on many platforms for about 2 months now, and here are my firstimpressions :

Pros:

- Performance is really quite impressive, for many functions. I won about 40% on my application.

- Quite easy to use / build custom DLL

- Good behaviour under Windows / Linux.

- Very active support !

Cons:

- Found a bug in H.263+ db filter using SSE2 optims.

- Many functions don't exist for XScale whereas IPP are intended to be cross-platform.

- Many functions have the same name on PC's and XScale but don't make exactly the same job (quantification in H.263 for instance).

- Other functions don't have the same name ... but do the same job !

- HUGE restriction on PocketPC : every reconstruction functions only take 64-bit aligned pointers as inputs; It means that these functions are impossible to use with motions vectors that are not aligned on 8x8 block ! Actually, these functions are usable only for INTRA or skipped blocks (i.e without motion vectors) and make the dll crash if datas are not 64 bit aligned (whereas it should return an error code).

- Documentation is hardly understandable for some functions, or is incomplete (again, the H.263 quantif does half the job as it doesn't restrict values in the normative range -127;127). It's not a problem if we know that it doesn'tbut it becomes a problem when it's not documented. I spent 24 hours trying to understand the way InterpolateLumaH264 worked but I gave up ...

- Very bad performance on AMD (but I can understand that ;) )

- It would be great to be able to add version number to the custom built dll ...

But this is still good job. I sincerely hope the new version will bring corrections, especially regarding naming conventions, XScale portability and XScale 64bit aligned data problem ...

Best regards,

Marc

[Vladimir_Dudnik]

Hi Marc,

thank you for the good words and double thanks for the critics because it gives us a chance for improvements.

Regarding cons, you mentioned:

bug in H.263 filtering was fixed already,you need wait for the next release.

Version info in custom DLL:

you needto insert ippGetLibVersion function into your custom DLL just like any other functions you use.

And we will work to improve the other things:)

Regards,
Vladimir

[peter2]

> Very bad performance on AMD (but I can understand that ;) )
One of the reasons we still maintain our own codebase for MMX/SSE/SSE2. Looking at the code under VTune I can even point parts of code that must be rewritten to run much faster on AMD (and even a bit faster on P-IV). I realize Intel would like to protect its brand, but this way forces IPP users to look for something better.

[marc_ba]

Unfortunately, I agree with you. We also have to maintain MMX code because we don't want to loose all our AMD customers ! And if we have to maintain this kind of code, I have to say it becomes harder to be IPP enthusiast ...

[nlj]

I am a beginer and it was great to read the comments/experiences by Marc.

Wanted to ask a question, with reference to the experiences/comments in Marc's original mail.

It is related to the 2nd and 3rd point mentioned by
Marc under the 'Cons' list.

Is it that, even in IPP4.0, some functions have same
name in IPP for Pentium and IPP for XScale but do
different jobs ? Is it that, some functions that are
present in IPP for Pentium are not yet there in IPP
for XScale, in ver 4.0 also ?

Then the mention about IPP that they are cross-platform
compatible, is not fully true..

Request the experienced folks to reply..

Thanks & regards,
Narendra

[marc_ba]

Hello

That's exactly the point. Many many functions are present in IPP 4.0 for Pentium and simply do not exist on the XScale version ...

[nlj]

Hello,

What about the other comment, i.e.
Do all the API calls for IPP ver 4.0 for XScale
do the same job as the corresponding API's in
IPP ver 4.0 for Pentium ?

Awaiting for reply,
Thanks & regards,
Narendra

[Vladimir_Dudnik]

Hi,

if there is some difference in function's behaviour, please submit it as issue to technical support, we will fix. It is definitely not thing we want to have.

What about functions whichexist in IPP for ia32/itanium but is not present in IPP for PCA, I has mentioned already, you should take into account the different abilities for those platforms. Whyyou are notsurprised that there no any high-computing servers (say better, clusters) were made based on PCA processors? Right, calculating power too different, but not only. Did you noticed there is no floating point unit on PCA? So, why we should implement a lot of functions which have floating point arguments? And of course, there are other reasons like these, which we accounted.

In general, we implement only those features in IPP for PCA which have application in that very specific area. But you can help us to make IPP better. If you see any functionality missed butyou consider as important to have, you know, submit your request, and we will revise it in future versions.

Regards,
Vladimir