ippsTone_Direct replacment (deprecation warnings)

ippsTone_Direct replacment (deprecation warnings)

James v.'s picture

Good day,

Is there a recommended replacement for ippsTone_Direct_32fc?  Ipp 7 has deprecated this and related functions, and I can't see an obvious replacement.

Thanks.

9 posts / 0 new
Last post
For more complete information about compiler optimizations, see our Optimization Notice.
Sergey Kostrov's picture

>>...Is there a recommended replacement for ippsTone_Direct_32fc? Ipp 7 has deprecated...

When the depreciation message is displayed there is link to follow for more details and please take a look. My generic advise is you need to consider usage of older version of IPP library if the function will be removed and no replacement provided.

Let's see what Intel software engineers say about it.

James v.'s picture

Quote:

Sergey Kostrov wrote:

When the depreciation message is displayed there is link to follow for more details and please take a look. My generic advise is you need to consider usage of older version of IPP library if the function will be removed and no replacement provided.

Thanks.  The deprecation message suggests looking at  http://software.intel.com/en-us/articles/intel-ipp-71-deprecated-features/, which helpfully tells me that the ippsTone_* functions are obsolete.  There is unfortunately no explanation of why, or where to look for a suitable replacement.

David J.'s picture

I'd also like to know the answer to this.

I can't imagine that it's deprecated just because too few people need to generate complex sinusoids.

Sergey Kostrov's picture

Please take into account that different versions of IPP library could co-exist ( installed ) on a system and could be used in one application. Win32 API functions LoadLibrary or LoadLibraryEx could be used to load older IPP libraries at run-time if needed.

The decision is made and I personally consider it as right and wise because IPP team is trying to reduce overheads related to maintenance of IPP library.

James v.'s picture

I'd agree that deprecating the old functions is a good idea when there is an alternative, as is the case with most of the other deprecated functions (like the inline versions of many functions), but I can't find a suitable alternative in this case.

Sergey Kostrov's picture

Sorry for repeating this again because during last a couple of days the subject was very hot:

1. Create a static library with all deprecated IPP functions and use it forever in an application
2. Different versions of IPP could co-exist on a computer system and could be used in the application at the same time

Consider 1 and 2 as possible solutions and let me know if you need more information.

Igor Astakhov (Intel)'s picture

Initially "_Direct" suffix was introduced to state the difference between functions that had state structure (no "_Direct" suffix) and functions that didn't have state. IPP deprecated all functions with "_Direct" suffix with different approaches to their further support. For example instead of FIR/IIR_Direct their analogues with state are available. For "Tone" (and other vector initialization functions) the deprecation message (sorry) is not clear regarding possible future substitution - so in the nearest future corresponding functions without "_Direct" suffix will be introduced - only Q15 function will be removed without any substitution.

regards, Igor

James v.'s picture

Thanks Igor.  That answers my question.  I'll stick with the current deprecated function then until the new non-direct version appears.

Sergey - Yes, I am aware that I can use old versions of the library, or link in old versions of the particular functions of interest, but the future replacement function suggested by Igor seems like a better option.  I would, after all, like to take advantage of future optimizations and new architecture support for all my IPP code.

Login to leave a comment.