Intel® Integrated Performance Primitives
Deliberate problems developing high-performance vision, signal, security, and storage applications.
6704 Discussions

how to use IPP Generic Libraries Pack add-on

selea
Beginner
586 Views
Hi all, I recently switch to IPP 7.0.2 and it's all fine. All except that I have to use my application in an embedded pc that have an old CPU not SSE3 (has not SSE at all).
So I downloaded the "w_ipp-generic_p_7.0.2.048.zip" file and I decompress it in the installation directory of the IPP libraries. Now I have the lib files ipp*px.lib in the LIB directory.
The problem is that I don't understand how can I link this libraries because I get always link errors.
I'll tell you what I'm doing right now so you can tell me what I'm wrong:
I have defined the_IPP_NO_DEFAULT_LIB define so the standard library are not linked.
I have included the file "ipp_px.h" before the file
in the file "ipp_px.h" (taken from the IPP 6 version) there's definition like this:
Then I link the ipp*px.lib in my project and the file ippcore.lib. Anyway I can't get the project link correctly.
So How can I link in my project to use the px_* functions so I can run the application on old pc? What's wrong?
thank you
0 Kudos
1 Solution
PaulF_IntelCorp
Employee
586 Views
Unfortunately, the static version of the generic add-on libraries do not include the px/mx prefix in version 7.0, like they do (effectively) in the 6.1 library; so you cannot use the technique you are borrowing above from the 6.1 library with the 7.0 library. It won't work because the "prefixed" library names don't exist inside that generic add-on library.

This means that you need to link explicitly against the ipp*px.lib files rather than relying on the compiler to do it for you -- thus you do need to use the _IPP_NO_DEFAULT_LIB option, and then list all the ipp*px.lib files in your link command line; and don't forget to include the ippcore.lib file at the end of that list, since it is not included with in the add-on library.

Essentially, the ipp*px.lib files look like a regular version of the ipp library, except that it contains no optimized code. This means that you can only use it, in this form, to build a generic editition of your application, which it sounds like you want to do.

If you use the DLL files you can simply throw them in with the other DLL files and it will "just work." But the static library is not built that way.

Paul

p.s. A "quick and dirty" approach would be to rename the standard distribution ipp*.lib files to ipp*.opt.lib (or something like that) and then rename the ipp*px.lib files to ipp*.lib (remove the px suffix within the basename). Then the #pragma(lib,filename.lib) thing will work inside the include headers and you should be able to build using the standard technique. Remember to keep ippcore.lib around.

View solution in original post

0 Kudos
11 Replies
PaulF_IntelCorp
Employee
587 Views
Unfortunately, the static version of the generic add-on libraries do not include the px/mx prefix in version 7.0, like they do (effectively) in the 6.1 library; so you cannot use the technique you are borrowing above from the 6.1 library with the 7.0 library. It won't work because the "prefixed" library names don't exist inside that generic add-on library.

This means that you need to link explicitly against the ipp*px.lib files rather than relying on the compiler to do it for you -- thus you do need to use the _IPP_NO_DEFAULT_LIB option, and then list all the ipp*px.lib files in your link command line; and don't forget to include the ippcore.lib file at the end of that list, since it is not included with in the add-on library.

Essentially, the ipp*px.lib files look like a regular version of the ipp library, except that it contains no optimized code. This means that you can only use it, in this form, to build a generic editition of your application, which it sounds like you want to do.

If you use the DLL files you can simply throw them in with the other DLL files and it will "just work." But the static library is not built that way.

Paul

p.s. A "quick and dirty" approach would be to rename the standard distribution ipp*.lib files to ipp*.opt.lib (or something like that) and then rename the ipp*px.lib files to ipp*.lib (remove the px suffix within the basename). Then the #pragma(lib,filename.lib) thing will work inside the include headers and you should be able to build using the standard technique. Remember to keep ippcore.lib around.
0 Kudos
selea
Beginner
586 Views
Thank you for reply, I'll try the "quick and dirty" approach: I think could be easy to get it work that way.
I let you know the result of my try.
0 Kudos
selea
Beginner
586 Views
I put the ipp*px.lib files in a directory and I renamed all files from ipp*px.lib to ipp*_l.lib (I put in the directory the ippcore_l.lib from the original IPP 7.0.2 directory)
The project it's linking correctly, but I got the same problem on old (not SSE) pc:
Illegal instruction (0xc000001d)
is it ippcore_l.lib the problem? or what else?
0 Kudos
selea
Beginner
586 Views
More details about the problem.
I make a test project that do nothing (display only a dummy window). I compile and link with IPP 7.0.2 and the program is running without problem.
I put in the code the function:
ippStaticInit();
and
ippGetCpuType()
and it's running fine without the illegal instruction problem.
if I put the function
ippGetCpuFreqMhz()
I get the "Illegal instruction (0xc000001d)"
I try to use the ipp*px.lib file renamed to ipp*_l.lib but the problem is the same: I think that something in the ippcore_l.lib library is not working for old CPU. Why didn't you put even the ippcorepx.lib in the add-on libraries?
0 Kudos
PaulF_IntelCorp
Employee
586 Views
Good question, makes no sense to me. I'm filing a bug to request this be fixed (inclusion of ippcore) or to insure that the standard ippcore work on a generic machine. In the meantime, if you need the MHz info (I'm assuming you might need it for timing measurements) you might be able to use the brand string from the CPUID intrinsic (seehttp://msdn.microsoft.com/en-us/library/hskdteyh(v=vs.80).aspx) or by retrieving info from the registry.
0 Kudos
selea
Beginner
586 Views
Thank you for advice. Actually I do not need the Mhz of the CPU, I'm just try to find out what function can cause on an old CPU the Illegal instruction error.
I found that this function reproduce the problem, but I'm investigate further because my application crash with illegal instruction at the beginning even without using the function that retrieve the CPU Mhz.
0 Kudos
selea
Beginner
586 Views

Probably I found the problem.

In the compiler options (visual studio) there's an option to specify the minimum CPU architecture (Enable Enhanced Instruction Set ) /arch:.

For some reason with the preview IPP sample using /arch:SSE the software work anyway on old CPU.

With latest version, instead, on old CPU I got the Illegal Instruction.

So if I leave the option to unset I can get the software work.

So just renaming the add-on libraries from ipp*px.lib to ipp*_l.lib I can get the software running on old CPU: anyway you do not have to call the function to obtain the Mhz of the CPU

0 Kudos
PaulF_IntelCorp
Employee
586 Views
Thank you for the update, glad you resolved the issue.

If you went from an older Intel compiler to a more recent version you may have run into issues regarding the default SSE level that the Intel compiler generates. I believe in the most recent edition of the Intel compiler the default is to generate SSE2 code, but I'm not certain. You should check the Intel compiler docs and compiler forum to be sure. In any event, if you want to guarantee what level of instructions are being generated you should definitely specify those flags on the compiler command line.

Also, if you are curious what level of MMX/SSE instructions your old processor supports, you can use ark.intel.com to get information. It's a little sparse for older processors, but it is very useful site. Also, compile and run the CPUINFO sample application or try using the CPUID intrinsic sample from MSDN.
0 Kudos
Thomas_Jensen1
Beginner
586 Views
I have a problem similar to this.
I build a custom dll with manual dispatching, based on ippmerged.c

It works for all except PX. The reason is that Intel decided to remove the prefixes (px_) from all functions, kepping the prefixes for all other library types (w7_, g9_ etc).

The purpose of PX is a catch-all when no other cpu library can be used.
Therefore, PX must be integrated into ippmerged.c, but that seems to be impossible now.

An example:
A function ippiCopy() normally is directed to w7_ippiCopy() (w7 is just for this example).
For PX, ippiCopy() is directed to ippiCopy(), and that won't compile.

Is there a way to somehow add a prefix to all PX functions?

0 Kudos
PaulF_IntelCorp
Employee
586 Views
Hello Thomas,

I've requested that the px_ and mx_ prefixes be added back to the generic static library files, but there is no commitment as to whether or not that will happen. In the meantime, the only solution is to build a seperate version of your application based on the generic files and then have a "preloader" that detects if you can use the >=SSE2 version of code or if you need to run the generic version of code, and then load the appropriate version of your app.

Paul
0 Kudos
Thomas_Jensen1
Beginner
586 Views
I'm glad you supports the idea of putting back the prefixes.

Since I'm not happy about writing a separate code path for px, I was looking for information if it is possible to use linker functions, or some pragma trick, to actually put in prefixes for px compile-time.

Looking at ippmerged.c, a lot of effort has already been created to make it possible to create a single dll with an ipp subset (just what I'm doing).
0 Kudos
Reply