status of ippr functions

[siddy]

Hi Intel IPP,

     I had been thinking of extending some of my funtions of 3D, and was intending to use ippr functions (then we were using IPP 6.0). Now that I really have to get a 3D version, I read somewhere that the entire ippr suite is being deprecated? Is this true? Will 7.1 have no way of performing 3D warp affine and remap? There are the basic 2 that would have formed the bulk of my implementation.

Thanks,

Sid.

[Chuck_De_Sylva]

Sid,

The 3D warp affine and remap functions were deprecated in version 7.1. You can still use them, but they will be going away in a future release. And yes, looking at the ippr header it looks as though the suite is being deprecated.

- Chuck

[siddy]

Well, thats sad... what is the alternative, then, for applications that have relied on the ippr suite with 6.0??Would like it if this is

also replied by someone from Intel.

Sid.

[SergeyKostrov]

>>...Will 7.1 have no way of performing 3D warp affine and remap? There are the basic 2 that would have formed the bulk of >>my implementation... As far as I understood the decision to remove these functions from IPP was made and it won't be changed. A simple solution of the problem is your own static library with all deprecated IPP functions. If you use only two deprecated functions than this is a really small project for a couple of hours or a couple of days ( if you create some set of test cases ).

[siddy]

HI, thanks for the reply. In case I go ahead and use static library as you suggested, can the rest of the code continue to use the latest IPP version, with just one component relying on 7.0 ?

Also, are IPP developers thinking of a new 3D libraries in the meantime, or 3D is completely deprecated? Or this there a way to perform 3D with available functionality, and ippr was appearing redundant? The reason mentioned for deprecating ippr was "low frequency of usage". How does intel know this or measure this? Also, in the applications that I have seen/used/coded, the most critical component of the code is definitely not the most frequent, and if speed is the design objective, it is the critical component that is IPP-ized.Hence I do not think that deprecation based on frequency is the right idea.

[SergeyKostrov]

>>...In case I go ahead and use static library as you suggested, can the rest of the code continue to use the latest >>IPP version, with just one component relying on 7.0 ? This is exactly what I would do if some deprecation will affect existing codes. By the way, IPL functions coexist with IPP functions on 32-bit Windows platforms without any issues. This is a piece of codes I could release that demonstrate how libraries of different generations / versions and for different platforms are included: ... #if defined ( _IPL_SUPPORT_ ) // IPL Support #if ( defined ( _M_IX86 ) ) #ifdef _ENABLE_DIAGNOSTICS #pragma message ( "# Diagnostics: IPL 32-bit Libraries Linked" ) #endif #include "ipl.h" #include "iplerror.h" #pragma comment ( lib, "ipl.lib" ) #endif #endif #if defined ( _IPP_SUPPORT_ ) // IPP Support #include "ipp.h" #include "ippcore.h" #include "ippi.h" #include "ipps.h" #include "ippvm.h" #if IPP_VERSION_MAJOR < 7 // For IPP v3.0 & v5.x #if ( defined ( _M_IX86 ) ) ... #endif #if ( defined ( _M_X64 ) || defined ( _M_AMD64 ) || defined ( _M_IA64 ) ) ... #endif #if IPP_VERSION_MAJOR >= 7 // For IPP v7.x & Next Versions #if ( defined ( _M_IX86 ) ) #ifdef _ENABLE_DIAGNOSTICS #pragma message ( "# Diagnostics: IPP v7.x 32-bit Libraries Linked" ) #endif #pragma comment ( lib, "ippcore.lib" ) #pragma comment ( lib, "ippi.lib" ) #pragma comment ( lib, "ipps.lib" ) #pragma comment ( lib, "ippvm.lib" ) #endif #if ( defined ( _M_X64 ) || defined ( _M_AMD64 ) || defined ( _M_IA64 ) ) #ifdef _ENABLE_DIAGNOSTICS #pragma message ( "# Diagnostics: IPP v7.x 64-bit Libraries Linked" ) #endif #pragma comment ( lib, "ippcore.lib" ) #pragma comment ( lib, "ippi.lib" ) #pragma comment ( lib, "ipps.lib" ) #pragma comment ( lib, "ippvm.lib" ) #endif #endif #endif ...

[siddy]

Thanks, Sergey

[Igor_A_Intel]

ippR will be still available (with deprecated message) in the next major release - 8.0. In the future, if it is removed, it still will be compatible with the future IPP releases - I mean that for example IPP version N+1 will not contain ippRR domain, but this domain from IPP version N will be compatible with N+1 (with N+1 version of core library and dispatching mechanism)

regards, Igor