Intel® IPP 9.0 Beta is now available. The release added the new Intel® AVX-512 optimization for the computer vision and image processing functions, extended optimization for Intel® Atom™ and Intel® Quark™ processors, added the new APIs to support external threading, and provided the custom dynamic library building tool, which enables users to build the dynamic library containing the selected Intel® IPP functions.
We also provide some options on the deprecated IPP functions. Please find more information on Intel IPP 9.0 Beta release note
Intel IPP 9.0 beta release is available as a part of the Intel Parallel Studio XE 2016 Beta, or Intel System Studio 2016 Beta now.
To sign up for the Intel System Studio 2016 Beta, visit this page.
To sign up for the Intel Parallel Studio XE 2016 Beta, visit this page.
Your feedback and question is welcome during your evaluation.
Could you check the Gaussian Blur is faster than the Separable Filter (Given a Gaussian Kernel)?
It seems it is not optimized well enough and using the separable version is faster (Though the Gaussian version can take advantage of the symmetry of the Kernel).
Could you shed more details about the new Multi Threading API?
Gaussian Blur function is based internally on calls to ippiFilterRow/ColumnPipeline. Please, don't use the word "seems", please provide the reproducible code for your statements - in this case we can help you to find mistakes/misprints/incorrectness's in your approach.
Why not take advantage of the symmetry of the Gaussian Kernel when using its 1D form?
It will reduce the number of multiplications by almost half.
Could you shed more details on the Multi Threading API?
Regarding the external threading, here is some details:
In the IPP 9.0 release:
1) The external threading is recommended, which is more effective than the internal threading
2) To use the external threading in the high level, it often need the IPP APIs to support to handle "border" data.
3) The in APIs in the IPPs are updated to support this.
Let me give a ippsFIR_32f functions example, the following is using the external threadings:
The first threading: It has no history delay data(NULL), No need to output delay data(NULL)
The last threading : It use previous data for the border(pSrc-dlyLineLen), Output the delay line data for future use(OutDelayLine)
For Other threadings: It use previous data for the border(pSrc-dlyLineLen), and it does not need to output delay data(NULL)
dlyLineLen = tapLen -1;//the delay line is used to keep old data.
ippsFIRSRGetSize_32f(… &specSize,&bufSize );
len = LEN/NUNTHREADS; //simplified code, not consider for tail data
for(iThread=0;iThread< NUNTHREADS;iThread++)//it means parallel for
Ipp32f* pSrc = input+iThread*len;
Ipp32f* pDst = ouput+iThread*len;
if( iThread == 0)
ippsFIR_32f( pSrc, pDst, len, pSpec, NULL, NULL , buffer);
else if (iThread == NUMTHREADS - 1)
ippsFIR_32f(pSrc, pDst, len, pSpec, pSrc-dlyLineLen,OutDlyLine, buffer);
ippsFIR_32f(pSrc,pDst, len, pSpec, pSrc-dlyLineLen, NULL , buffer);
If you have chance to look at these APIs, let us know you feedback.
Yes, we are currently using AMR, AMR-WB, iLBC, Silk, Opus, G.722.1, G.729 and G.722 codecs implementations based on IPP.
So we use the following functions (and I am probably missing a few):
I am very surprised to see that Intel is dropping the codecs from the IPP library. We are using a lot of the speech codecs and video codecs from the IPP library in our application: G.711, G.729, AMR, AMR-WB, G.722, H.263, MPEG-4, and H.264. Is the Media SDK going to provide support for all of these? As far as I am aware, only H.264 is currently supported?