This forum is disabled, please visit https://forum.opencv.org
| 2016-06-27 05:41:37 -0600 | commented answer | OpenCV 3.1 HAL functions in lapack Thank you for clear answer. |
| 2016-06-27 05:40:46 -0600 | received badge | ● Supporter (source) |
| 2016-06-27 05:40:44 -0600 | received badge | ● Scholar (source) |
| 2016-06-17 04:31:57 -0600 | received badge | ● Student (source) |
| 2016-06-17 04:03:54 -0600 | asked a question | OpenCV 3.1 HAL functions in lapack I am trying to get the concept of HAL, but right now in some parts (lapack.cpp) it looks a bit confusing: First, we have HAL intrinsics implementations in separate headers, one of which is chosen depending on cpu commands supported (SSE2, NEON or cpp implementation). If we work with different platform, we can add new header fill it with specific definitions, add the rule for it to intrin.hpp, and add required changes to cmake config files. Second, user redefinitions of cv_hal_foo aliases. It seems to be the most clear part of HAL. Standalone library, which needs only interface.h from core includes. If HAL interfaces are constant we can apply changes only to hal source files, rebuild hal library and test it with stable OpenCV build. Quite convenient and fast. The third part and my questions. F.e. LU32f is implemented in OpenCV source file (matrix_decomp.cpp) as part of cv::hal:: namespaces. Why implement HAL in OpenCV sources? Why call the only implementation of LU32f hal? Why not make it standard and as for arithm.cpp functions, add some hal_ni_foo implementations to hal_replacement.hpp and define cv_hal_foo macros? Thank you. |