Does Intel IPP 8.0 support in-place operations?

Does Intel IPP 8.0 support in-place operations?

I have originalyy posted this question to stackoverflow

IPP <= 7.1 has special in-place functions.

In IPP 8 they are deprecated: deprecation-summary

It is not clear if the new out-of-place functions also support in-place operation.

My guess is that for some of the functions it is OK to pass the same pointers for src/dst, but for others it is not, but this is not documented.

Here is the documentation

16 帖子 / 0 全新
最新文章
如需更全面地了解编译器优化,请参阅优化注意事项

>>I have originalyy posted this question to stackoverflow...

I did not see any technical details there. Since your question is Intel IPP specific ( for 100% ) I don't think stackoverflow is the right place to ask questions related to Intel IPP.

>>...IPP <= 7.1 has special in-place functions.

In-place functionality is specific to some set of functions and it is Not library specific. Please provide a list of functions. Thanks.

Stackoverflow is a good place to ask questions, even if they are 100% related to any technology.

Anyway, the problem is that the documentation is simply not clear.

There is a set of functions that support in-place, but this set is not documented.

Do I really have to give you a list of 200 functions and have a yes/no answer to each one? In the forum?

It was actually library API specific that functions that can work in-place were marked appropriately in previous versions, and now they are not.

What I need is the full list of functions which support in-place operation. I was expecting to find this in the docs, and not have to ask "on demand" in the forums for every current and future function used.

>>Do I really have to give you a list of 200 functions and have a yes/no answer to each one?

Take a look at IPP header files for more information and descriptions are always given for cases when in and out parameters point to the same memory.

There are no such descriptions.

For example:

ippiAbs_16s_C1R - in-place operation is mentioned only for the deprecated flavors, but can pSrc and pDst point to the same place? It is not known.

ippiAddC_8u_C1RSfs - this function most likely supports in-place, but this is not mentioned in the description, and we have to guess.

These are just two examples showing the pattern.

From ippi.h header file:

...
// pSrcDst pointer to the source/destination image (for in-place function)
// srcDstStep step through the source/destination image (for in-place function)
...

if you don't see 'for in-place function' it means that functionality is no longer supported.

If this is true, then for ippiAbs , ippiAddC the in-place functionality is no longer supported? I don't think so.

Also, it seems that  'for in-place function' is only found on deprecated functions...

So, maybe the answer to the question is NO, Intel IPP 8.0 does not support in-place operations?

Can you give an example of a deperecated in-place flavor, that still supports in-place with the new API? Is this example documented in the docs or headers?

Hi Hristo,

all out-of-place flavors of the corresponding in-place operations DO support in-place operation in IPP 8.0. "deprecated" doesn't mean "removed" - we still don't have the final decision and it will be based on your (customers) feedbacks. Anyway, in case of "remove" decision, all documentation and headers will be updated correspondingly ("this function supports pSrc==pDst operation"), additional check for "pSrc==pDst" will be added to all other functions - so you'll get "not supported mode" status + we'll provide in-place wrappers (probably macro) for all out-of-place functions that support such mode. Is it OK or you have something more to add for more smooth transition?

regards, Igor

Hi Igor,

here is my simple point of view:

1. I will not use deprecated functions. For me, deprecated means that the function will be removed in the near future.

2. If the alternatives support in-place operations, I will use it.

3. There is currently no information which non-deprecated functions support in-place.

4. It is not an option to check if there is corresponding deprecated in-place flavor, this is too fuzzy.

5. If there is such update ("this function supports pSrc==pDst operation") in the docs/headers, that would be awesome, but currently there is not.

6. So, in this moment I can't migrate to 8.0 because of the reasons above. This makes the transition less smooth.

Ok, got your point, will take into account during the next update preparation - just one Q for you - what do you think - is macro wrapper for in-place operation over out-of-place suitable for you? Like IPPAPI( ippStatus, ippsAdd_xx_I,( pSrc, pSrcDst, len) where ippsAdd_xx_I is a macro that uses ippsAdd_xx( pSrc, pSrcDst, pSrcDst, len) or you use something other than C/C++ and you need real entry points for each function?

regards, Igor

Such macro wrappers will not be needed for me, as I am already automatically generating C++ Qt wrappers. These wrappers handle things such as type conversions (QRect, QImage, QSize etc.), error/warning handling, edge cases, in-place operations, etc.

All I need is a clearly documented notes in the docs and headers about the in-place support for each function.

Thank you for your support!

Hi,

old thread, but I was just watching the list of deprecated functions in 7.1 (couldn't find the same for v8)
https://software.intel.com/en-us/articles/functions-deprecated-in-ipp-71/

..and indeed, I too noticed that a lot of basic in-place versions were marked as deprecated, with the hint saying to use the not in-place version instead.
That's indeed confusing, it doesn't tell exactly if it's a direct replacement.

While there is a part of IPP that I use because I can't do it myself or I don't have the time to (the complex stuff), there is the basic stuff, like.. block additions/multiplications.. that I use because it's there, and because it may be using AVX which I don't have access to (Delphi). It's a time saver, but when I see that some really basic ones are so easily marked as deprecated, and when I consider that when I write my own versions, it's usually faster than what's in IPP, it doesn't make me wanna keep using them.

For ex, this function:
IppiAddC_8u_C4IRSfs
it says to replace with the non in-place version. That doesn't make any sense, it's a basic addition. Allocating memory a copying back & forth would be several times costier than the addition itself.
So what would anyone sane do? Obviously not switch to the non in-place version, but do his own, either asm or using the signal version on each line.
Now if IppiAddC_8u_C4RSfs was described as supporting the same source & dest, then yes, that would make sense.

 

Hi Dambrin,

according to a lot of customer requests deprecation messages have been already removed for almost all in-place functionality. As regarding deprecation in v7.1 - yes, your last supposition is correct - all out-of-place analogues of in-place functions support pSrc=pDst operation, but yes, you are right - with "I" suffix and pSrcDst notation IPP API is more evident and self-describing.

regards, Igor

Ah, thanks

As I was reading the definition of ippiFilterBoxBorder, I did notice that that one was claiming to support in-place operation.

So this is 100% safe, all out-of-place also support in-place now? Because the 8.1 manual is still very obscure for IppiAddC. But ok, I'll use the out-of-place versions, and I'm actually 100% for that, that's how my own libraries work as well. Only problem here, it's not something we can test ourselves reliably (with the various CPU branches), thus we need to rely on the manual (which is quite good btw, but sometimes unclear. Like with the new FilterBoxBorder which I haven't fully understood yet.. but that'll be for another post)

Dambrin,

as I've written above - almost all in-place functionality has been restored in IPP, deprecation message removed - therefore use please special in-place APIs for in-place operations. There is no any guarantee that some new optimization for some out-of-place functionality will continue support of pSrc==pDst as there is special API with "I" suffix. Let's consider our attempt to decrease the number of supported APIs in 7.1 as unsuccessful and unreasoned and switch to the historically correct and well thought approach.

regards, Igor.

perfect, thanks

发表评论

登录添加评论。还不是成员?立即加入