Ability to use IPP as a JUCE FFT backend

[forestbond]

Hey @sudara, I sent a message on the Audio Programmer Discord but thought I'd post here as well so it doesn't get lost in the mix.

I'm using a pretty similar setup to what you have with Pamplejuce for IPP and I've had to add these definitions: _IPP_SEQUENTIAL_STATIC=1 IPP_NO_DEFAULT_LIB=1. I don't see these in your setup (which I've been using as a reference). Wanted to bring to your attention just in case IPP is perhaps failing silently with Pamplejuce on Windows.

I have not confirmed one way or the other with Pamplejuce directly. But what I've seen with my own tree is that without defining _IPP_SEQUENTIAL_STATIC, the JUCE IPP code is not active. Without IPP_NO_DEFAULT_LIB=1 I had build failures that appear to be due to a bug in IPP (I am using same version as you, the bug is in ippcore.h where the library paths appear to be incorrect). In any case it seems this flag should be set when manually specifying static libraries to link.

Let me know if any questions.

[sudara]

Hey @forestbond! Thanks for opening an issue, it's appreciated.

without defining _IPP_SEQUENTIAL_STATIC, the JUCE IPP code is not active

Ah ok, I've never used the JUCE IPP code. That's for using IPP as the JUCE FFT backend, right?

Without IPP_NO_DEFAULT_LIB=1 I had build failures that appear to be due to a bug in IPP

Do you have any backtrace for this? Is it again the JUCE FFT stuff?

I'm using IPP fine out of the box but I did have to update the includes at some point in the last year when upgrading IPP, I believe they simplified to #include "ipps.h" — sounds like the JUCE implementation still references the old way of doing things?

I'll update the issue title to make it a bit more clear. Thanks!!

[forestbond]

Hi @sudara, yes that's right this is using IPP as JUCE FFT backend. I hadn't thought to use IPP directly as I already had the JUCE FFT working. I know nothing of the the old/new way of doing things.

The build failure is a linker error:

LINK : fatal error LNK1104: cannot open file 'C:\Users\runneradmin\.nuget\packages\intelipp.static.win-x64\2022.2.0.575\build\native\include\ipp\ippcore.h/../../../lib/ippcoremt.lib' [D:\a\***AudioTools\***AudioTools\Build\Plugins\FreqBlender\FreqBlender_AAX.vcxproj]
LINK : fatal error LNK1104: cannot open file 'C:\Users\runneradmin\.nuget\packages\intelipp.static.win-x64\2022.2.0.575\build\native\include\ipp\ippcore.h/../../../lib/ippcoremt.lib' [D:\a\***AudioTools\***AudioTools\Build\Plugins\FreqBlender\FreqBlender_VST3.vcxproj]

This seems to be due to incorrect library paths in ippcore.h:

#if !defined(IPP_NO_DEFAULT_LIB)
  #if defined(_IPP_SEQUENTIAL_DYNAMIC)
    #pragma comment(lib, __FILE__ "/../../../lib/ippcore")
  #elif defined(_IPP_SEQUENTIAL_STATIC)
    #pragma comment(lib, __FILE__ "/../../../lib/ippcoremt")
  #elif defined(_IPP_PARALLEL_DYNAMIC)
    #pragma comment(lib, __FILE__ "/../../../lib/threaded/ippcore")
  #elif defined(_IPP_PARALLEL_STATIC)
    #pragma comment(lib, __FILE__ "/../../../lib/threaded/ippcoremt")
  #endif
#endif

On my system the correct paths would say "win-x64" instead of "lib".

-Forest

[forestbond]

BTW @sudara perhaps you have seen this already but the checks in the JUCE code look like:

#if _IPP_SEQUENTIAL_STATIC || _IPP_SEQUENTIAL_DYNAMIC || _IPP_PARALLEL_STATIC || _IPP_PARALLEL_DYNAMIC
...
#endif

[sudara]

Ok thanks for the details! So you didn't find IPP_NO_DEFAULT_LIB via documentation but by poking around in that header?

I don't use the IPP FFT (I use it for vector functions), which is probably the main reason why I never ran into compatibility issues with JUCE!

Keeping track of thoughts here:

• I believe all of the compile-time sequential/parallel macro junk is deprecated IPP dispatching related code which is no longer relevant in the new versions (which do runtime dispatching). JUCE relying on those old macros is also in the way of other things like linux support: https://forum.juce.com/t/improve-ipp-support-and-integration/47662/4
• juce_dsp is including ippcore.h first, which is triggering the issue (vs. only loading ipps.h, which is the "new" way) — I'm not entirely sure but maybe the check for IPP_NO_DEFAULT_LIB has something to do with this load order and legacy dispatching?...
• My knee-jerk is that JUCE should update its IPP code to use the modern includes, but I guess IPP has some backwards compatibility which we are seeing here, so everything works.
• I'm not sure about other consequences/side-effects of setting the legacy macros, in particular IPP_NO_DEFAULT_LIB which I've never seen reference to...

[forestbond]

@sudara OK I certainly appreciate the depth of thought here. I don't really have a horse in the race as I'm not actually using Pamplejuce. My suspicion is that improving performance on Windows for juce::dsp::FFT is a primary reason for many people to integrate IPP (that was my motivation), and the current state of things may be surprising for them.

[sudara]

Appreciate the report! I'll try to get JUCE to update its IPP support, otherwise seems like docs for the workaround would be useful. Thanks!