I downloaded an eval copy of IPP 7.1, the one included in Parallels Studio. According to this link (http://software.intel.com/en-us/articles/new-atom-support), I am expecting to have *s8-7.1.dll in my redist folder but the one I have doesn't. Is it a separate download? From the download page in Intel for eval, I only have download links for ia32, intel64 and linux which don't include dlls for Atom. Any help re this one would be appreciated. Thanks.
I have a problem with using V8 (Atom) using static threaded linking.
All symbols I use are undefined. For instance, I link to ipps_t.lib and this contains the function v8_ippsRShiftC_32s but my linker can't find it.
Linking with W7 (SSE2) works fine.
Not sure how do you do the test. Could you please send a small test case?
Regarding the smart dispatch of v8 and s8, there are a function lists in C:\Program Files (x86)\Intel\Composer XE 2013\ipp\tools\ia32\staticlib and you need to include the ipp_s8.h before other IPP header file.
I don't have a small test case right now.
However, I think I now understand the problem. First, I was not aware of the folder ipp\tools\ia32\staticlib.
I now see that it contains remapping function lists of ALL IPP functions... And for Atom (S8), it sometime maps a function to S8 and sometimes to V8. That is the cause of my problem, since I don't use these remapping files. I use a maco that remaps to a single target, S8 or V8 etc., so that is why it gives linking errors in either case.
I "just" have to drop my macro implementation and start using your function remapping files. I guess those files will be kept updates in the future? :)
I just got my code working using the remapping files in ipp\tools\ia32\staticlib.
However, now I got a new problem: the custom DLL I create now exploded in size from 7.5MB to 41MB.
It must be from the fact that the remapping list references ALL functions in IPP, even if I use IPPAPI( type,name,arg ) __declspec(dllexport) type __STDCALL ##name arg, with a REDUCED list of functions.
In fact, the only reference I have are those from my DEF file.
Can you indicate how I can create a custom static DLL using only a subset defined via funclist.h and also using ipp\tools\ia32\staticlib?
I use MS for development and debugging, and Intel Compiler for release.
The problem I describe is both with MS and with Intel Compiler.
With MS, I do have /OPT:REF in my configuration. I say the problem first in MS.
Stil, the only reference is in the DEF file, since the DLL only contains select IPP functions for one CPU only, and a DEF to publish it.
The question is then, how can the size increase so much?
The function remapping H files actually only contains macros who add a specific CPU prefix to any IPP function call.
Thus it should not affect anything.
Have you looked at "advanced-usage/customdll" sample?
Having this sample, what else do you need? To build custom DLL for selected CPU architectures only?
Dumpbin /exports indicates that I have about 1700 functions in the DEF file, which is correct (my IPP subset).
The function remapping files has about 11500 functions, which is the full IPP set.
And yes, I have looked at the customdll sample which is in ipp-samples\sources\advanced-usage\core\customdll\src (IPP 7.1).
I fully understand that for a custom DLL, you basically include ipp.h and then simply specify which IPP functions you want to have in the DLL by adding entries to the DEF file.
This is also what I'm doing in the 5.3, 6.1, 7.0 versions of my custom DLL project. However, when I now wanted to implement Atom-specific CPU, I quickly found out that I must include a file from staticlib, and with that, my DLL exploded in size.
I will continue to search for a solution today.
In you custom DLL you don't need all function clones for CPU archs other than Atom. So, if you want 1700 IPP functions you should have 1700+something entries in DLL.
I am afraid that if you add a single entry to DEF file with basic name (say, ippsAdd_8u), you get all clones (w7_ippsAdd_8u, v8_ippsAdd_8u, s8_ippsAdd_8u ...) in DLL. This is because the general IPP function name is used in DEF file. You should use specific names (e.g. s8_ippsAdd_8u) only in the DEF.
But this adds the limitation, that your target applications should use "#include ipp_s8.h" everywhere instead of "#include ipp.h". Otherwise, the compiler will generate calls to the functions, which are absent in your custom DLL.
I see that one of my DLLs (w7) does indeed have CPU code for v8, s8 etc. instead of only w7 code.
I then need to know why all CPU flavors are linked when I declare ippsAdd_8u in DEF. Why do I also get v8_ippsAdd_8u (and the others too) when I declare ippsAdd_8u and I only read ipp_w7.h? In ipp_w7.h, ippsAdd_8u is translated to w7_ippsAdd_8u.
Is it something in the LIB files that I don't understand? I use ipps_t.lib, ippi_t.lib etc.
If I must use CPU specific prefixes in my DEF, like w7_ippsAdd_8u, then I will get a problem with Atom (only).
For all CPU flavors except Atom optimized, all prefixes are the same.
But for Atom optimized, the prefix is sometimes s8_ and sometimes v8_. The remapping file is ipp_s8.h, but inside this file, many functions map to v8_ (ssse3 or Atom non-optimzied).
This means that I should put a mix of s8_ and v8_ in my DEF file, which breaks my setup.
My old setup does indeed have w7_ etc as prefix in DEF, but now I thought, I can use the (new) remapping files ipp_s8.h and let it remap DEF (no prefix) to lib (mixed prefix).
I now used dumpbin on ipps_t.lib and indeed now see that it contains all CPU references. I now understand that I cannot use function references without prefixes when I use static linking for a single CPU only.
That means going back to putting prefixes in DEF, which is not a problem for non-Atom, but is for Atom because it uses a mix of s8 and v8.
I can manually put in the mix of prefixes in DEF, but I also have __declspec(dllexport) in CPP files, and there I just use a redefined IPPAPI macro, but that only works with a single prefix...