Switch to the OpenCL execution branch happens if input and output image arguments are passed as opaque cv::UMat objects. This integration uses same functions at the user level as regular CPU implementations. Multiple OpenCL-accelerated algorithms are available via so-called "Transparent API (T-API)". TODO: other options: WITH_CUFFT, WITH_CUBLAS, WITH_NVCUVID? OpenCL support Some tutorials can be found in the corresponding section: GPU-Accelerated Computer Vision (cuda module) See also CUDA-accelerated Computer Vision To build opencv and opencv_contrib together check Build with extra modules. Note Since OpenCV version 4.0 all CUDA-accelerated algorithm implementations have been moved to the opencv_contrib repository. These parameters are not documented yet, please consult with the cmake/OpenCVDetectCUDA.cmake script for details. Additional options can be used to control build process, e.g. For cmake versions older than 3.9 OpenCV uses own cmake/FindCUDA.cmake script, for newer versions - the one packaged with CMake. CUDA toolkit must be installed from the official NVIDIA site as a prerequisite. Many algorithms have been implemented using CUDA acceleration, these functions are located in separate modules. If BUILD_ option is disabled, 3rdparty library will be detected and enabled if found => HAVE_ set to ON if dependency is found.If BUILD_ option is enabled, 3rdparty library will be built and enabled => HAVE_ set to ON.Options starting with HAVE_ indicate that dependency have been enabled, can be used to manually enable a dependency if automatic detection can not be used.Options starting with BUILD_ enable or disable building and using 3rdparty library bundled with OpenCV.Options starting with WITH_ enable or disable a dependency.There are three kinds of options used to control dependencies of the library, they have different prefixes: cmake has special option allowing to print all available configuration parameters:Ĭmake -LH. There are many optional dependencies and features that can be turned on or off. See also GCC instrumentation Build hardening Interprocedural optimization Link time optimization ThinLTO
#Cmake options code
OptionĮnable profiling compiler and linker options.Įnable several quirks in code to assist memory sanitizer.Įnable compiler options which reduce possibility of code exploitation.Įnable thin LTO which incorporates intermediate bitcode to binaries allowing consumers optimize their applications later. Profiling, coverage, sanitize, hardening, size optimizationįollowing options can be used to produce special builds with instrumentation or improved security. opencv Note More details on CPU optimization options can be found in wiki: See ot-efr32 and ot-nrf528xx.Cmake -DCV_DISABLE_OPTIMIZATION=ON. Support for multiple platforms in a single repository is possible and several platform repositories can be used as reference. A good example of this file for a repository which supports only a single platform is from ot-cc2538. This is where you define the source files, include paths, and compiler flags for your platform library. A good starting point would be to copy the ot-efr32 version of this file and modify it to fit your platform. This is a toolchain file which defines some variables that CMake uses in the build process. It also contains a few other required files. This is the heart of the repository and is where the platform abstraction layer is implemented. If you would like to include sample applications in the repo, create an examples folder and add it to the build tree as well. The third_party folder contains any third-party code. The src folder is where the platform-abstration layer source code is located. Now that the top-level configuration is defined, it's time to add other subdirectories to the build tree. set_property(CACHE EFR32_PLATFORM PROPERTY STRINGS $/crypto The CMakeLists.txt file includes a check that aborts builds launched for unsupported platforms. For the sake of this example, we've defined multiple platforms, but having a single platform for the _PLATFORM_VALUES variable is fine as well. We also define a variable EFR32_PLATFORM_VALUES which is a list of efr32 platforms supported by ot-efr32. In this example, we set the project name to ot-efr32 with a version of 0.0.1. The very first values to define are the project name and the supported platforms. The CMakeLists.txt at the root of your repository is the top of the build tree and is a good place to start defining the various targets, options, and macros used in the build process.
The CMake build system relies on CMakeLists.txt files which define build targets.
0 kommentar(er)
