OpenCV-OpenCL只是一个美丽传说？

之前不是没有测试过OpenCV-OpenCL，为此当时还去看过OpenCV3.x的源码，看到了那些写好的kernel；看到OpenCV的API都会有一个选择，只要dstimg是UMat型就会启动OpenCL版本的API，如果是Mat，则启动普通的CPU版本的OpenCV-API。但之前的测试效果就不理想，OpenCL版本的API比纯OpenCV的慢很多，我一直以为是有的函数不适合改成并行，现在想来不是的，如果是不适合，OpenCV团队还怎么会将这个OCL版本的API写进去，他们又不傻。

今天再次测试，测试的是 http://blog.csdn.net/tiemaxiaosu/article/details/52850820 这个例子，当只有一幅图像时：

纯CPU的OpenCV-api只要19ms左右；但是OpenCV-OpenCL的版本却要几百ms！真是醉了。

后来循环处理1000次：纯CPU是2100ms左右；OpenCV-OpenCL就是1100ms左右

我想是OpenCL的check以及准备工作耗时太长，所以少数图片不划算！只能这样理解了。

我将公司一个项目（纯OpenCV-API）中间凡是能改写成对应OpenCV-OpenCL版本的API都改过来。本来有二三十个函数可以改成对应的OCL版本，但我发现速度反而比原来版本慢了N多！我打开CodeXL查看：（绝大部分还是仍旧使用原OpenCV-API，只有这二三十个改成了GPU的API）

可以看到OpenCV-OCL的确启动了的，不然CodeXL中不会出现这些，因为它是无法检测CPU相关的东西只能检测GPU相关的。因为我是处理多幅图像，所以这些函数第一次调用时都隐式的在buildprogam花费了很多时间，但第二次即第二幅图去调用它时就不需要build了，第三幅图去调用也不需要build了。。。

但是速度比我不改的版本还是慢了太多太多！我看到：

这里竟然存在几千条数据传输，我将涉及到这个的UMat改回来，改成纯OpenCV-API形式；但仍旧比原版慢。。。

哎烦躁。有点感觉OpenCV-OCL只是一个美丽的传说了？因为现实生活工作中，不可能全像我举的第1个小例子那样项目代码中的所有函数都可以用OpenCV-OCL的函数来写（而不混入纯OpenCV-API（即有的OpenCV函数没有对应的OCL版本）），这种情况下我实验出来每次都比纯OpenCV慢（那要OpenCV-OCL有何用？！）；还有比如有的项目中我用了OpenCV-OCL，但我有自己写的kernel，想实现GPU端的交互，咋办？性能又如何？（我要自己写个实例运行就知道了  不过我已经失望了  对这个也不报希望）

看谷歌上的：

说实话 我觉得很鸡肋。。。