zoukankan      html  css  js  c++  java
  • 【感受】android + opencv + umat + opencl使用感受

    近期编译了android下支持opencl的opencv,使用opencl能力的关键是用cv::UMat替换cv::Mat。
    实际使用后发现坑很多,非常不成熟,不推荐使用这种方式来提升实际产品的性能。

    • 每个UMat产生的时候会从gpu分配内存,而GPU分配内存是很慢的;使用Mat的时候,这点开销不值得一提,但是UMat完全不是一回事。因此,UMat一定一定要重用,避免反复分配。
    • mat.getUMat()方法很多坑,引用计数的错误很难查,至今没搞明白原理。因此一直用mat.copyTo(umat)来代替。
    • mat.copyTo(umat) 和 umat.copyTo(mat)也是很慢的,因此,一定要计算时间大于数据拷贝时间,抵消了拷贝的开销,使用umat才能带来性能提升。
    • 例如这样一个函数 cv::cvtColor(umat_in, umat_out),第一次使用是很慢的,因为opencl的核函数编译很耗时。因此要使用很多次,多到第一次使用的编译开销可以忽略。
    • 再说核函数编译的问题:opencv是C风格的,每次调用,核函数都要编译一次,虽然第二次以后很快,但是这种每次调用都编译一次核函数没有意义。
    • T-API看起来很好,一套API既支持Mat又支持UMat,但其中的坑是:计算到底用GPU完成的还是CPU完成的,你不知道。例如我使用cv::dft()一样,传入的UMat必须按照2的倍数对齐,否则就会退化到用CPU计算。这下大坑就来了——我先mat.copyTo(umat),然后传给cv::dft(), 函数内部检测无法用GPU计算后,自动退化成CPU计算,然后内部umat.getMat(), 计算完成后再mat.getUMat,白白多了两次GPU内存拷贝,加上外部调用又拷贝了两次,来回有四次GPU内存拷贝。
    • opencv的函数都没有提供opencl的Queue的支持,也就是所有的拷贝和计算无法让CPU和GPU做到异步。就算GPU分担了CPU的压力,但是CPU在等着GPU计算的结果。
    • 从opencl支持的源码风格上看,很可能T-API最初只在intel GPU & AMD GPU上测试,网上的android+opencv+opencl的文章也很少——由此猜测:android下的opencv中的opencl加速,可能并没有专门针对android平台去测试加速情况。没有前人证明过这条路可行!
  • 相关阅读:
    log4net 简单使用教程(配置)
    C#WinForm 国际化的简单实现,多语言实现
    EF Power Tool 参数错误 HRESULT:0x80070057 (E_INVALIDARG)) 解决办法
    如何用委托与事件实现winfrom窗体之间值传递
    VS2010自带的Dotfuscator 5注册
    WinForm 实现主程序(exe)与其关联类库(*.dll)分开存放
    POJ_3211 Washing Clothes (01背包)
    POJ_3624 Charm Bracelet ( 01背包 )
    集训队内部测试赛(2012.01.02)
    HDU_1011 Starship Troopers && HDU_1561 The more, The Better (树型dp)
  • 原文地址:https://www.cnblogs.com/ahfuzhang/p/11220097.html
Copyright © 2011-2022 走看看