在小米mix 2s + 高通骁龙 845 + Adreno 630 上测试了opencl版本的cv::dft()。

测试数据

先看表格里面的描述：

名称

函数名

最大时间(ms)

平均时间(ms)

说明

cpu版本dft

cv::dft()

-

0.029448

未统计其他，仅cv::dft()函数的调用时间

opencl版本

cv::dft(UMat)

802.557000

0.202941

不计算mat与umat的拷贝，不计算umat的填充对齐

opencl中使用opencl计算的主函数

cv::ocl_dft()

802.553000

0.210583

cv::dft()包装了cv::ocl_dft()，这一层无太多性能损耗

ocl_dft第一步调用的子函数

ocl_dft_rows()

802.518000

0.1031

-

ocl_dft第二步调用的子函数

ocl_dft_cols()

338.004000

0.078061

-

对象池

OCL_FftPlanCache::getInstance().getFftPlan()

0.190000

0.000028

对象池很快，几乎不占用时间，可以忽略

opencl的核函数编译、绑定参数、计算

OCL_FftPlan::enqueueTransform()

464.393000

0.075685

-

核函数编译

enqueueTransform()

464.237000

0.019422

第一次编译很慢，以后会快很多。但是也不用重复编译才对

参数绑定

enqueueTransform()

0.122000

0.016015

绑定参数也很快

核函数执行

enqueueTransform()

1.167000

0.028805

-

结果分析

有这样一些结论：

• 令人失望：opencl+gpu版本的平均时间 0.202941，而CPU版本的平均时间是 0.029448，GPU版本比CPU版本慢了6.9倍；而且还未加上Mat拷贝到UMat, Mat填充对齐，UMat拷贝回Mat等部分占用的时间；
• 可以发现，第一次执行cv::dft()的opencl版本的时候，编译核函数很耗时（464ms），后续的编译占用时间尚可；
• 纯计算时间上看，opencl核函数执行时间大约是0.028805 * 2，大约是CPU版本的1.96倍。产生这样的原因可能是我的测试数据很小，如果数据量很大，GPU版本在纯计算时间上可能会比CPU版本好一些。

优化计划

• 在调用cv::dft()的opencl版本以前，开一个线程空调用一次cv::ocl_dft()，这样核函数的编译时间就不会占用总调用时间了。

• ocl::Kernel这里可以建立对象池，而不是每次调用都使用临时对象，这样的话，每次调用可以节约0.019422ms，性能可提升9.6%；

  ocl::Kernel k(kernel_name.c_str(), ocl::core::fft_oclsrc, options);

• 如果采用GPU内存池，每次计算的输入和输出地址都不变，那么参数绑定环节的0.016015ms可以省略，性能可能提升7.9%

• 在我的cv::dft()的使用场景中，每次连续计算44个矩阵的数据。假设能够找到方法，把44次计算陆续加入队列，让GPU连续计算。假设GPU并发度支持44次计算同时进行，那么GPU版本的理论延迟是 0.202941/44 = 0.004612， 比CPU版本提升 6.39倍！