In this particular case t shadows transpose of the base class Matx:
types.hpp:1805:14: warning: declaration of ‘t’ shadows a member of
'this' [-Wshadow]
Changelog gcc 4.8: The option -Wshadow no longer warns if a declaration
shadows a function declaration.
This warning is problematic because it prevents the module
opencv_contrib/modules/ruby to pass the build process
IPP can be switched on and off on runtime;
Optional implementation collector was added (switched off by default in CMake). Gathers data of implementation used in functions and report this info through performance TS;
TS modifications for implementations control;
According to opencl 1.2 spec 5.4.2:
enqueues a command to unmap a previously mapped region of a memory object.
...
CL_INVALID_VALUE if mapped_ptr is not a valid pointer returned by
clEnqueueMapBuffer, or clEnqueueMapImage for memobj.
So if the u->data is not from a clEnqueueMapBuffer call, we should not
call clEnqueueUnmapMemObject() unmap it. With this patch, the cases
./opencv_test_video --gtest_filter=OCL_Video/FarnebackOpticalFlow.Mat/*
could work well with beignet 0.9.1, Otherwise, it will get a
CL_INVALID_VALUE at the clEnqueueUnmapMemObject().
Signed-off-by: Zhigang Gong <zhigang.gong@intel.com>
I propose forEach method for cv::Mat and cv::Mat_.
This is solution for the overhead of MatIterator_<_Tp>.
I runs a test that micro opecode runs all over the pixel of cv::Mat_<cv::Point3_<uint8_t>>.
And this implementation 40% faster than the simple pointer, 80% faster than iterator.
With OpenMP, 70% faster than simple pointer, 95% faster than iterator (Core i7 920).
Above all, code is more readable.
My test code is here.
https://gist.github.com/kazuki-ma/8285876
Thanks.