Inplace functions are declared as deprecated since ipp 7.1 and possibly will be removed.
So, can we use non-inplace functions with pSrc==pDst? Or we must use intermediate buffer (and get excessive copying)?
How can we know whether a function is safe to to use src==dst? I've encountered some functions where doing this led to unpredictable results. Is this documented somewhere? Is it only safe when src and dst have the same data type? For example, if src is complex and dst is real.
For example, I was getting strange errors with ippsMagnitude_32f when using one of the input vectors as the output vector.
I may be wrong on which function it was. There were two I was getting an error with, and it was only for certain input signals. Once I changed them to use a temporary buffer instead of dst=src, the errors went away. I'll see if I can determine which one it was, but it's one of these:
ippsWinHann_32f, ippsFFTFwd_RToPerm_32f, ippsMulPerm_32f, ippsMagnitude_32f.
I wish I could be more specific, but unfortunately I didn't write it down. I'll try to remember, but it's in a large program, and I fixed it several days ago.
The error was simply that the output value was just slightly off of what it should be, but enough that I knew something was wrong.
I just need to know exactly when it's safe to reuse memory and when it's not.
Yes it was very ambiguous. But I'm not really looking for help debugging my code. I fixed these errors several weeks ago, by using temporary buffers instead in-place ops.
What I need is some clear documentation on when in-place ops can be done, and when they can't. This may be in the reference manuals, but I've been unable to find it.
My point was that, I have experienced bugs as a result of using in-place ops with IPP, which were difficult to diagnose. Because these bugs were only evident with certain input parameters, they could have easily gone unnoticed, and ended up in the production code. So it's just not worth the risk of a "trial and error" approach.
I should have taken better notes about the bugs, and how they were resolved, but unfortunately I didn't. Even then, I'm restricted on how much information I can give in a public forum.
So I'm hoping someone can point me to some definitive documentation.Otherwise, I'll play it safe for now, and use temporary buffers.
If I recall correctly, the error was with using the real input to ippsMagnitude_32f as the real output.
There was another function where the input was real, the output was complex, and the same memory space was being used for both. I think that one's pretty obvious, though.
And I believe I was also getting errors with src=dst in ippsWinHann_32f.
I changed to using temporary buffers in ippsFFTFwd_RToPerm_32f, ippsMulPerm_32f, after discovering the other bugs, and there's nothing in the documentation indicating if in-place ops are supported for these functions. Ultimately, I removed all in-place ops with IPP. Fortunately, we use IPP sparingly in our code.
Another function I was concerned about was the Haar transform. It would work if the algorithm was carried out in the most intuitive way, because writes would progress in increments of one, while the reads would have increments of two. However, I didn't want to chance making assumptions about IPP internal workings, which could change in subsequent releases.
So there are so many different scenarios, and it really needs to be clearly documented for each function.
What your showing is for _32fc rather than _32f, but it still doesn't use pSrcDst.
I can't see any reason why it wouldn't work, as long of the nth element of pDst is not written to until after the magnitude is computed, i.e. realp
I hope this hole in the documentation is filled in the near future, as non-in-place operations can get very expensive for large data buffers. I'd like to see every function be documented as to which buffers can be reused for src/dst.