|
Using OpenCV with IPP 6.1 on Atom Processors
Hi,
I have IPP 6.1 which have Atom processor support.
I'm using OpenCV 1.0.
When I run my app on an Atom PC, the app runs, but the IPP DLLs don't load.
Should they load?
Will OpenCV properly identify the Atom platform and load the correct DLLs? Has anyone tried this? Are there any changes that need to be made to OpenCV to allow this? Thanks!! Adi ------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july_______________________________________________
Opencvlibrary-devel mailing list
Opencvlibrary-devel@...
https://lists.sourceforge.net/lists/listinfo/opencvlibrary-devel
|
|
Re: Using OpenCV with IPP 6.1 on Atom Processors
Hi Adi,
First of all, check if cxswitcher.cpp contains something like "-6.1", that is, if it looks for IPP 6.1 at all. OpenCV 1.0 was long time ago, and I do not have it on my machine right now to check that.
Secondly, I think, you will have to modify cxswitcher.cpp anyway, because, afaik, the IPP DLLs for Atom have some different suffix, not w7, v8, but something else, and the reason for it is that Atom does not have out-of-order execution, so a normal code, built for Pentium4 or Core, can be quite slow.
That is, you will likely need to add this suffix somewhere in cxswitcher.cpp
Regards, Vadim On Tue, Sep 1, 2009 at 1:42 AM, Adi Shavit <adishavit@...> wrote:
Hi,
I have IPP 6.1 which have Atom processor support.
I'm using OpenCV 1.0.
When I run my app on an Atom PC, the app runs, but the IPP DLLs don't load.
Should they load?
Will OpenCV properly identify the Atom platform and load the correct DLLs? Has anyone tried this? Are there any changes that need to be made to OpenCV to allow this? Thanks!! Adi
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Opencvlibrary-devel mailing list
Opencvlibrary-devel@...
https://lists.sourceforge.net/lists/listinfo/opencvlibrary-devel
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july_______________________________________________
Opencvlibrary-devel mailing list
Opencvlibrary-devel@...
https://lists.sourceforge.net/lists/listinfo/opencvlibrary-devel
|
|
 Re: Using OpenCV with IPP 6.1 on Atom Processors
Hi Vadim, Actually, I had an error with the file names/paths. When that was fixed, OpenCV 1.0 loaded ver 6.1 without a problem (cxswitcher already has 6.1 in it). The platform postfix is not important and cxswitcher, rightly, does not check it, since it loads IPP's own dispatcher which is suffix-less (e.g. ippi-6.1.dll). That takes care of loading the correct DLL for the current platform.
Indeed, on the Atom it loads the ipp* s8.dll files.
In the upcoming OpenCV 2.0 (which is now in pre-beta state) IPP support has been temporarily removed, but will likely get back in 2.0 gold or in the nearest 2.x.
That's a real shame. I was really looking forward to it.
As for static linking with IPP I am not sure that is the best option.
It is very conveniant having a single executable loading
different optimized implementations on runtime, instead of keeping
multiple exes. I think IPP's redist installer actually installs only
the relevant files for each platform.
This is especially true, when doing Pentium/Atom development. The same exe runs on both machines.
Unless you mean linking all of IPP's implementations for all platforms into your exe.
Then your really get a huge exe.
There we are going to change the mechanism completely - we will link OpenCV against static merged IPP libs, that brings several advatanges:
1) once you built OpenCV with IPP you can be sure that it is used,
This can be checked in runtime already now.
With your approach, linking the wrong IPP implementation might cause the program to crash.
It also requires an IPP dev. installation to be present on each build machine, and not just the redist DLL files.
This means many more licenses.
Given that vision SD is a lot about performance you can't have some developers use slower implementations than others.
2) the corresponding duplicate code in OpenCV will be excluded at compile time for smaller footprint.
This is small price to pay I think.
Especially, if all IPP implementations will go into the exe instead and cannot be shared with other apps.
3) no need to prepare custom IPP libs and care about shipping it. Together with static OpenCV linking (which is also planned for 2.x), users could finally generate their DLLs and executables w/o having to redistribute OpenCV and IPP parts.
I understand you considerations, but I would really like to see the dynamic linking option left-in.
I have not seen any discussions about this on the group. Has there been any?
Any thoughts?
Thanks,
Adi
On Tue, Sep 1, 2009 at 10:22 AM, Adi Shavit <adishavit@...> wrote:
Hi Vadim, Thanks for the quick reply! Which OpenCV version would you suggest? Is there a stable release I can upgrade to?
I'll try what you suggested and let you know. Thanks, Adi
On Tue, Sep 1, 2009 at 1:27 AM, Vadim Pisarevsky <vadim.pisarevsky@...> wrote:
Hi Adi,
First of all, check if cxswitcher.cpp contains something like "-6.1", that is, if it looks for IPP 6.1 at all. OpenCV 1.0 was long time ago, and I do not have it on my machine right now to check that.
Secondly, I think, you will have to modify cxswitcher.cpp anyway, because, afaik, the IPP DLLs for Atom have some different suffix, not w7, v8, but something else, and the reason for it is that Atom does not have out-of-order execution, so a normal code, built for Pentium4 or Core, can be quite slow.
That is, you will likely need to add this suffix somewhere in cxswitcher.cpp
Regards, Vadim On Tue, Sep 1, 2009 at 1:42 AM, Adi Shavit <adishavit@...> wrote:
Hi,
I have IPP 6.1 which have Atom processor support.
I'm using OpenCV 1.0.
When I run my app on an Atom PC, the app runs, but the IPP DLLs don't load.
Should they load?
Will OpenCV properly identify the Atom platform and load the correct DLLs? Has anyone tried this? Are there any changes that need to be made to OpenCV to allow this? Thanks!! Adi
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Opencvlibrary-devel mailing list
Opencvlibrary-devel@...
https://lists.sourceforge.net/lists/listinfo/opencvlibrary-devel
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july_______________________________________________
Opencvlibrary-devel mailing list
Opencvlibrary-devel@...
https://lists.sourceforge.net/lists/listinfo/opencvlibrary-devel
|
|
Re: Using OpenCV with IPP 6.1 on Atom Processors
Hi Vadim, Any comments on this? Thanks, Adi On Tue, Sep 1, 2009 at 9:05 PM, Adi Shavit <adishavit@...> wrote:
Hi Vadim, Actually, I had an error with the file names/paths. When that was fixed, OpenCV 1.0 loaded ver 6.1 without a problem (cxswitcher already has 6.1 in it).
The platform postfix is not important and cxswitcher, rightly, does not check it, since it loads IPP's own dispatcher which is suffix-less (e.g. ippi-6.1.dll). That takes care of loading the correct DLL for the current platform.
Indeed, on the Atom it loads the ipp* s8.dll files.
In the upcoming OpenCV 2.0 (which is now in pre-beta state) IPP support has been temporarily removed, but will likely get back in 2.0 gold or in the nearest 2.x.
That's a real shame. I was really looking forward to it.
As for static linking with IPP I am not sure that is the best option.
It is very conveniant having a single executable loading
different optimized implementations on runtime, instead of keeping
multiple exes. I think IPP's redist installer actually installs only
the relevant files for each platform.
This is especially true, when doing Pentium/Atom development. The same exe runs on both machines.
Unless you mean linking all of IPP's implementations for all platforms into your exe.
Then your really get a huge exe.
There we are going to change the mechanism completely - we will link OpenCV against static merged IPP libs, that brings several advatanges:
1) once you built OpenCV with IPP you can be sure that it is used,
This can be checked in runtime already now.
With your approach, linking the wrong IPP implementation might cause the program to crash.
It also requires an IPP dev. installation to be present on each build machine, and not just the redist DLL files.
This means many more licenses.
Given that vision SD is a lot about performance you can't have some developers use slower implementations than others.
2) the corresponding duplicate code in OpenCV will be excluded at compile time for smaller footprint.
This is small price to pay I think.
Especially, if all IPP implementations will go into the exe instead and cannot be shared with other apps.
3) no need to prepare custom IPP libs and care about shipping it. Together with static OpenCV linking (which is also planned for 2.x), users could finally generate their DLLs and executables w/o having to redistribute OpenCV and IPP parts.
I understand you considerations, but I would really like to see the dynamic linking option left-in.
I have not seen any discussions about this on the group. Has there been any?
Any thoughts?
Thanks,
Adi
On Tue, Sep 1, 2009 at 10:22 AM, Adi Shavit <adishavit@...> wrote:
Hi Vadim, Thanks for the quick reply! Which OpenCV version would you suggest? Is there a stable release I can upgrade to?
I'll try what you suggested and let you know. Thanks, Adi
On Tue, Sep 1, 2009 at 1:27 AM, Vadim Pisarevsky <vadim.pisarevsky@...> wrote:
Hi Adi,
First of all, check if cxswitcher.cpp contains something like "-6.1", that is, if it looks for IPP 6.1 at all. OpenCV 1.0 was long time ago, and I do not have it on my machine right now to check that.
Secondly, I think, you will have to modify cxswitcher.cpp anyway, because, afaik, the IPP DLLs for Atom have some different suffix, not w7, v8, but something else, and the reason for it is that Atom does not have out-of-order execution, so a normal code, built for Pentium4 or Core, can be quite slow.
That is, you will likely need to add this suffix somewhere in cxswitcher.cpp
Regards, Vadim On Tue, Sep 1, 2009 at 1:42 AM, Adi Shavit <adishavit@...> wrote:
Hi,
I have IPP 6.1 which have Atom processor support.
I'm using OpenCV 1.0.
When I run my app on an Atom PC, the app runs, but the IPP DLLs don't load.
Should they load?
Will OpenCV properly identify the Atom platform and load the correct DLLs? Has anyone tried this? Are there any changes that need to be made to OpenCV to allow this? Thanks!! Adi
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Opencvlibrary-devel mailing list
Opencvlibrary-devel@...
https://lists.sourceforge.net/lists/listinfo/opencvlibrary-devel
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf_______________________________________________
Opencvlibrary-devel mailing list
Opencvlibrary-devel@...
https://lists.sourceforge.net/lists/listinfo/opencvlibrary-devel
|
|
Re: Using OpenCV with IPP 6.1 on Atom Processors
Hi Adi,
Sorry for a big delay with reply. Please, see below
Regards, Vadim On Tue, Sep 22, 2009 at 10:44 AM, Adi Shavit <adishavit@...> wrote:
Hi Vadim, Any comments on this? Thanks, Adi
On Tue, Sep 1, 2009 at 9:05 PM, Adi Shavit <adishavit@...> wrote:
Hi Vadim,
Actually, I had an error with the file names/paths.
When that was fixed, OpenCV 1.0 loaded ver 6.1 without a problem (cxswitcher already has 6.1 in it).
The platform postfix is not important and cxswitcher, rightly, does not check it, since it loads IPP's own dispatcher which is suffix-less (e.g. ippi-6.1.dll). That takes care of loading the correct DLL for the current platform.
Indeed, on the Atom it loads the ipp*s8.dll files.
right, I forgot that OpenCV switched to using IPP dispatcher quite a while ago.
In the upcoming OpenCV 2.0 (which is now in pre-beta state) IPP support has been temporarily removed, but will likely get back in 2.0 gold or in the nearest 2.x.
That's a real shame. I was really looking forward to it.
As for static linking with IPP I am not sure that is the best option.
It is very conveniant having a single executable loading
different optimized implementations on runtime, instead of keeping
multiple exes. I think IPP's redist installer actually installs only
the relevant files for each platform.
This is especially true, when doing Pentium/Atom development. The same exe runs on both machines.
OpenCV could be linked (though, that's not implemented yet) against the same IPP dispatcher libs (like ippi-6.1.lib, or how they are called), not necessarily merged/emerged libs, this is just a matter of changing CMake scripts, not the library itself. Then you get the same automatic dispatching mechanism.
Unless you mean linking all of IPP's implementations for all platforms into your exe.
Then your really get a huge exe.
Starting from 2.0, OpenCV already includes a lot of SSE2-optimized code, that you can compile with Atom-aware compiler (such as ICC) and get the optimal instruction scheduling. In theory, of course, manual code optimization and instruction reordering could give you even better performance, but in practice, in the case of IPP, such optimization is only done for a limited number of functions, so called "hot list". The current OpenCV includes SSE2 optimization for image warping (resize, remap, affineTransform etc.), image linear filtering, median filtering, morphology, most of the arithmetical functions etc. There are still some OpenCV functions that can benefit from using IPP, but there are actually not many of them.
Thus, if we link all of the implementation of those functions into opencv DLLs, or into the executable, once we add static opencv libs, that should not be a huge executable. I believe, most of the space will be taken by the DFT and maybe color space transformations. I think, that will be 2mb at most.
There we are going to change the mechanism completely - we will link OpenCV against static merged IPP libs, that brings several advatanges:
1) once you built OpenCV with IPP you can be sure that it is used,
This can be checked in runtime already now.
With your approach, linking the wrong IPP implementation might cause the program to crash.
linking OpenCV against merged/emerged libraries is safe, since the IPP dispatcher is invoked in the beginning that checks the host CPU and reassigns the function pointers as needed. If OpenCV is linked against IPP's dispatcher libs, this is also safe because of the same reason. The only possibility for the program to crash is when you link it against, say, Nehalem-specific library and run it on Core Duo or other earlier CPU.
It also requires an IPP dev. installation to be present on each build machine, and not just the redist DLL files.
This means many more licenses.
Well, now this is a serious reason. I need to check that. Let's see what is needed to compile OpenCV against IPP and run it: DLLs/shared libs, headers, and the import libraries in Windows.
DLLs/shared libs are a part of runtime, so no probs. headers - as OpenCV can now use (with noticeable benefits) only a few dozens of IPP functions, we can duplicate their declarations, as we did it before in _cvipp.h etc.
The only remaining thing is import libraries (for Windows only). I recall that at least Borland had the tool that extracts import libraries from DLLs, I believe, for MS compiler there should be such a tool too. Besides, I've looked here http://software.intel.com/sites/products/collateral/hpc/ipp/ipp_faq.pdf, the question "what are the redistributable files?" and they say, .libs are there. Need to check the redist.txt. Overall, I think, this problem can be solved some how. Another possible option is to link OpenCV against a custom DLL/lib, prepared in the same way as for the previous versions of OpenCV.
Given that vision SD is a lot about performance you can't have some developers use slower implementations than others.
2) the corresponding duplicate code in OpenCV will be excluded at compile time for smaller footprint.
This is small price to pay I think.
Especially, if all IPP implementations will go into the exe instead and cannot be shared with other apps.
3) no need to prepare custom IPP libs and care about shipping it. Together with static OpenCV linking (which is also planned for 2.x), users could finally generate their DLLs and executables w/o having to redistribute OpenCV and IPP parts.
I understand you considerations, but I would really like to see the dynamic linking option left-in.
ok, I think, we can not provide it by the time of 2.0 release, but for 2.x this can be reconsidered again. The fact is that 2.0, as is, i.e. without IPP, is definitely much faster than 1.x without IPP. So maybe the users will be satisfied with the performance.
I have not seen any discussions about this on the group. Has there been any?
well, I could not find it in opencvlibrary-devel mailing list. Maybe, it was posted to yahoogroups, need to check this.
Any thoughts?
Thanks,
Adi
On Tue, Sep 1, 2009 at 10:22 AM, Adi Shavit <adishavit@...> wrote:
Hi Vadim, Thanks for the quick reply! Which OpenCV version would you suggest? Is there a stable release I can upgrade to?
I'll try what you suggested and let you know. Thanks, Adi
On Tue, Sep 1, 2009 at 1:27 AM, Vadim Pisarevsky <vadim.pisarevsky@...> wrote:
Hi Adi,
First of all, check if cxswitcher.cpp contains something like "-6.1", that is, if it looks for IPP 6.1 at all. OpenCV 1.0 was long time ago, and I do not have it on my machine right now to check that.
Secondly, I think, you will have to modify cxswitcher.cpp anyway, because, afaik, the IPP DLLs for Atom have some different suffix, not w7, v8, but something else, and the reason for it is that Atom does not have out-of-order execution, so a normal code, built for Pentium4 or Core, can be quite slow.
That is, you will likely need to add this suffix somewhere in cxswitcher.cpp
Regards, Vadim On Tue, Sep 1, 2009 at 1:42 AM, Adi Shavit <adishavit@...> wrote:
Hi,
I have IPP 6.1 which have Atom processor support.
I'm using OpenCV 1.0.
When I run my app on an Atom PC, the app runs, but the IPP DLLs don't load.
Should they load?
Will OpenCV properly identify the Atom platform and load the correct DLLs? Has anyone tried this? Are there any changes that need to be made to OpenCV to allow this? Thanks!! Adi
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Opencvlibrary-devel mailing list
Opencvlibrary-devel@...
https://lists.sourceforge.net/lists/listinfo/opencvlibrary-devel
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf_______________________________________________
Opencvlibrary-devel mailing list
Opencvlibrary-devel@...
https://lists.sourceforge.net/lists/listinfo/opencvlibrary-devel
|
|
Re: Using OpenCV with IPP 6.1 on Atom Processors
Hi Adi,
ok, now IPP is found and linked with OpenCV (when USE_IPP=TRUE in CMake configuration dialog). It looks like IPP (for all the platforms) only takes a few hundreds kilobytes, comparing to the C-only code, so the size overhead is not an issue.
Regards, Vadim On Tue, Sep 22, 2009 at 4:17 PM, Vadim Pisarevsky <vadim.pisarevsky@...> wrote:
Hi Adi,
Sorry for a big delay with reply. Please, see below
Regards,
Vadim On Tue, Sep 22, 2009 at 10:44 AM, Adi Shavit <adishavit@...> wrote:
Hi Vadim, Any comments on this? Thanks, Adi
On Tue, Sep 1, 2009 at 9:05 PM, Adi Shavit <adishavit@...> wrote:
Hi Vadim,
Actually, I had an error with the file names/paths.
When that was fixed, OpenCV 1.0 loaded ver 6.1 without a problem (cxswitcher already has 6.1 in it).
The platform postfix is not important and cxswitcher, rightly, does not check it, since it loads IPP's own dispatcher which is suffix-less (e.g. ippi-6.1.dll). That takes care of loading the correct DLL for the current platform.
Indeed, on the Atom it loads the ipp*s8.dll files.
right, I forgot that OpenCV switched to using IPP dispatcher quite a while ago.
In the upcoming OpenCV 2.0 (which is now in pre-beta state) IPP support has been temporarily removed, but will likely get back in 2.0 gold or in the nearest 2.x.
That's a real shame. I was really looking forward to it.
As for static linking with IPP I am not sure that is the best option.
It is very conveniant having a single executable loading
different optimized implementations on runtime, instead of keeping
multiple exes. I think IPP's redist installer actually installs only
the relevant files for each platform.
This is especially true, when doing Pentium/Atom development. The same exe runs on both machines.
OpenCV could be linked (though, that's not implemented yet) against the same IPP dispatcher libs (like ippi-6.1.lib, or how they are called), not necessarily merged/emerged libs, this is just a matter of changing CMake scripts, not the library itself. Then you get the same automatic dispatching mechanism.
Unless you mean linking all of IPP's implementations for all platforms into your exe.
Then your really get a huge exe.
Starting from 2.0, OpenCV already includes a lot of SSE2-optimized code, that you can compile with Atom-aware compiler (such as ICC) and get the optimal instruction scheduling. In theory, of course, manual code optimization and instruction reordering could give you even better performance, but in practice, in the case of IPP, such optimization is only done for a limited number of functions, so called "hot list". The current OpenCV includes SSE2 optimization for image warping (resize, remap, affineTransform etc.), image linear filtering, median filtering, morphology, most of the arithmetical functions etc. There are still some OpenCV functions that can benefit from using IPP, but there are actually not many of them.
Thus, if we link all of the implementation of those functions into opencv DLLs, or into the executable, once we add static opencv libs, that should not be a huge executable. I believe, most of the space will be taken by the DFT and maybe color space transformations. I think, that will be 2mb at most.
There we are going to change the mechanism completely - we will link OpenCV against static merged IPP libs, that brings several advatanges:
1) once you built OpenCV with IPP you can be sure that it is used,
This can be checked in runtime already now.
With your approach, linking the wrong IPP implementation might cause the program to crash.
linking OpenCV against merged/emerged libraries is safe, since the IPP dispatcher is invoked in the beginning that checks the host CPU and reassigns the function pointers as needed. If OpenCV is linked against IPP's dispatcher libs, this is also safe because of the same reason. The only possibility for the program to crash is when you link it against, say, Nehalem-specific library and run it on Core Duo or other earlier CPU.
It also requires an IPP dev. installation to be present on each build machine, and not just the redist DLL files.
This means many more licenses.
Well, now this is a serious reason. I need to check that. Let's see what is needed to compile OpenCV against IPP and run it: DLLs/shared libs, headers, and the import libraries in Windows.
DLLs/shared libs are a part of runtime, so no probs. headers - as OpenCV can now use (with noticeable benefits) only a few dozens of IPP functions, we can duplicate their declarations, as we did it before in _cvipp.h etc.
The only remaining thing is import libraries (for Windows only). I recall that at least Borland had the tool that extracts import libraries from DLLs, I believe, for MS compiler there should be such a tool too. Besides, I've looked here http://software.intel.com/sites/products/collateral/hpc/ipp/ipp_faq.pdf, the question "what are the redistributable files?" and they say, .libs are there. Need to check the redist.txt. Overall, I think, this problem can be solved some how. Another possible option is to link OpenCV against a custom DLL/lib, prepared in the same way as for the previous versions of OpenCV.
Given that vision SD is a lot about performance you can't have some developers use slower implementations than others.
2) the corresponding duplicate code in OpenCV will be excluded at compile time for smaller footprint.
This is small price to pay I think.
Especially, if all IPP implementations will go into the exe instead and cannot be shared with other apps.
3) no need to prepare custom IPP libs and care about shipping it. Together with static OpenCV linking (which is also planned for 2.x), users could finally generate their DLLs and executables w/o having to redistribute OpenCV and IPP parts.
I understand you considerations, but I would really like to see the dynamic linking option left-in.
ok, I think, we can not provide it by the time of 2.0 release, but for 2.x this can be reconsidered again. The fact is that 2.0, as is, i.e. without IPP, is definitely much faster than 1.x without IPP. So maybe the users will be satisfied with the performance.
I have not seen any discussions about this on the group. Has there been any?
well, I could not find it in opencvlibrary-devel mailing list. Maybe, it was posted to yahoogroups, need to check this.
Any thoughts?
Thanks,
Adi
On Tue, Sep 1, 2009 at 10:22 AM, Adi Shavit <adishavit@...> wrote:
Hi Vadim, Thanks for the quick reply! Which OpenCV version would you suggest? Is there a stable release I can upgrade to?
I'll try what you suggested and let you know. Thanks, Adi
On Tue, Sep 1, 2009 at 1:27 AM, Vadim Pisarevsky <vadim.pisarevsky@...> wrote:
Hi Adi,
First of all, check if cxswitcher.cpp contains something like "-6.1", that is, if it looks for IPP 6.1 at all. OpenCV 1.0 was long time ago, and I do not have it on my machine right now to check that.
Secondly, I think, you will have to modify cxswitcher.cpp anyway, because, afaik, the IPP DLLs for Atom have some different suffix, not w7, v8, but something else, and the reason for it is that Atom does not have out-of-order execution, so a normal code, built for Pentium4 or Core, can be quite slow.
That is, you will likely need to add this suffix somewhere in cxswitcher.cpp
Regards, Vadim On Tue, Sep 1, 2009 at 1:42 AM, Adi Shavit <adishavit@...> wrote:
Hi,
I have IPP 6.1 which have Atom processor support.
I'm using OpenCV 1.0.
When I run my app on an Atom PC, the app runs, but the IPP DLLs don't load.
Should they load?
Will OpenCV properly identify the Atom platform and load the correct DLLs? Has anyone tried this? Are there any changes that need to be made to OpenCV to allow this? Thanks!! Adi
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Opencvlibrary-devel mailing list
Opencvlibrary-devel@...
https://lists.sourceforge.net/lists/listinfo/opencvlibrary-devel
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf_______________________________________________
Opencvlibrary-devel mailing list
Opencvlibrary-devel@...
https://lists.sourceforge.net/lists/listinfo/opencvlibrary-devel
|
|
Re: Using OpenCV with IPP 6.1 on Atom Processors
Hello, I've download and installed the OpenCV-2.0.0a-win32.exe.
It work great with MinGW but it doesn't have the *.lib and *.dll for MVSC++ 2008 (I had to build them). I think it should be good to propose a OpenCV-2.0.0a-Full-Win32.exe (with lib and dll for MinGW and MSVC++ 2008)
lib/cv200.lib lib/cvaux200.lib ... lib/libcv200.dll.a lib/libcvaux200.dll.a ------------------- bin/cv200.dll
bin/cvaux200.dll
...
bin/libcv200.dll
bin/libcvaux200.dll ... What do you think about this. Regards, Benoit -- Benoit RAT www.neub.co.nr
------------------------------------------------------------------------------
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf_______________________________________________
Opencvlibrary-devel mailing list
Opencvlibrary-devel@...
https://lists.sourceforge.net/lists/listinfo/opencvlibrary-devel
|
