Recommended deployment methods for IPP 6.0

[hagay_lupeskoinscan-]

Hi,

Version 5.3 used to include an installer that installed all required binaries in the system32 folder, and performed all other required updates (such as env variables if I am not mistaken).

However, IPP 6.0 does not include this installer.
I searched in the IPP documentation but failed to find a recommendation for deployment.

- Could you describe your recommended deployment method(s)?
- I would mention I found the installer (which had a silent feature) most convinient for client-site deployment. Why did Intel gave up on it?

Regards, Hagay

[elhefe38]

Hi

Quoting - hagay.lupeskoinscan-tech.com

However, IPP 6.0 does not include this installer.
I searched in the IPP documentation but failed to find a recommendation for deployment.

- Could you describe your recommended deployment method(s)?
- I would mention I found the installer (which had a silent feature) most convinient for client-site deployment. Why did Intel gave up on it?

I ran into the same issue and it prevented me so far to migrate to IPPv6. Official answer I got was "in response to many customer requests and to avoid potential conflicts when multiple Intel IPP versions are installed to a target system, the Intel IPP RTI was removed in version 6.0". Which translates roughly into "some idiots were definitely not able to use it so let us just remove this".

You have either to resort to static linking with dispatching (which can use threaded version of the functions, although this is not documented), or copy the dlls yourself when you install your program (which roughly resorts to rewriting Intel's installer if you want to keep CPU detection to install only the specific version). If you only support one type of CPU you can use static linking.

Anyway, much likely unpleasant hassle to replace what was running smoothly in versions 5.x... I finally sorted out all the issues (*fingers crossed*) to be able to use static linking, and it requires a lot of fiddling with CRT libraries (under Windows) to make it work.

Enjoy ;)
Nicolas

[Naveen_G_Intel]

Hi,
We have published an article about method of deploying application with IPP 6.0, Please refer to it.

http://software.intel.com/en-us/articles/intel-ipp-rti-tool-is-obsolete/

I hope this will answer your question.

Thanks,
Naveen Gv

[elhefe38]

Quoting - Naveen Gv (Intel)

We have published an article about method of deploying application with IPP 6.0, Please refer to it.

http://software.intel.com/en-us/articles/intel-ipp-rti-tool-is-obsolete/

IMO, Intel has yet to give a convincing reason for removing a working and useful tool...

[pvonkaenel]

Quoting - elhefe38

IMO, Intel has yet to give a convincing reason for removing a working and useful tool...

I'm afraid that I was one of the idiots who ran into problems in the past: however there really were problems going from IPP 4.1.3 to 5.0 which caused me to skip the 5.0 release completely. The 5.0 RTI required that older RTI installations be uninstalled before continuing. This in combination that the 5.0 entry points were different than the 4.1.3 entry points could cause 4.1.3 application to stop working if a 5.0 application installed the RTI. You could have one or the other, but not both unless you included the IPP DLLs in your application's bin directory (also a possibility).

By the time 5.1 was released, the RTI was fixed and you could have multiple side-by-side installations, but as soon as I saw that one of the 5.3 updates allowed for static linking including the threading layer I moved to that and have been happy ever since. Distributing the entire IPP RTI (which includes entry points for multiple processors) is very large and can bloat the installer several times.

Considering all the available linking options, I think Intel has done a pretty good job documenting them - takea look at the "IPP User's Guide" for details.

Peter

[elhefe38]

Hello

Quoting - pvonkaenel

I'm afraid that I was one of the idiots who ran into problems in the past: however there really were problems going from IPP 4.1.3 to 5.0 which caused me to skip the 5.0 release completely. The 5.0 RTI required that older RTI installations be uninstalled before continuing. This in combination that the 5.0 entry points were different than the 4.1.3 entry points could cause 4.1.3 application to stop working if a 5.0 application installed the RTI. You could have one or the other, but not both unless you included the IPP DLLs in your application's bin directory (also a possibility).

By the time 5.1 was released, the RTI was fixed and you could have multiple side-by-side installations, but as soon as I saw that one of the 5.3 updates allowed for static linking including the threading layer I moved to that and have been happy ever since. Distributing the entire IPP RTI (which includes entry points for multiple processors) is very large and can bloat the installer several times.

I understand what you ran into, and IMHO it had to be this way, trying to make two versions coexist on the same system using a RTI which will put them in system32 is a twisted way of asking for troubles :)
I must say I am far less enthusiastic about the forced and undocumented migration to another linking model imposed by IPP 6.0
And performing static linking when you have a mix of native and managed dlls using IPP functions is far from obvious IMO...

a+