UMat很慢(OpenCV,Python)

3

我一直在使用OpenCV来调整大批量(100k+)的图像大小(16-24MP)。但是不知何故,使用CPU总是比使用GPU快30-50%。 由于我正在运行ryzen 1700x和1080ti,所以我本来期望情况会相反。 如果有人能给我一个提示,告诉我我做错了什么就太好了。 我正在运行OpenCV 4.0.0.pre和OpenCL 1.2

#!/usr/bin/python
import numpy as np
import cv2 as cv
import glob
from multiprocessing import Pool
import time
path =''
dic=[]
def resizer(file):
    img = cv.imread(file)
    height, width = img.shape[:2]

    dim = float(width)/float(height)
    if dim > 1:
        width=4000
        height= 4000/dim
        start_time = time.time()
        res = cv.resize(cv.UMat(img), (int(width), int(height)), interpolation=cv.INTER_CUBIC)
        print("--- %s seconds ---" % (time.time() - start_time))
    else:
        width=4000*dim
        height= 4000
        start_time = time.time()
        res = cv.resize(cv.UMat(img), (int(width), int(height)), interpolation=cv.INTER_CUBIC)
        print("--- %s seconds ---" % (time.time() - start_time))
    name=file.split('/')[-1]
    cv.imwrite('/small/{}'.format(name), res)

for file in glob.glob(path+'*.JPG'):
    dic.append(file)

if __name__ == "__main__":
    pool=Pool(16)
    pool.map(resizer, dic)
    pool.terminate()

我怀疑你在使用错误的工具。依我之见,OpenCV更适合于"计算机视觉"任务。我建议你考虑使用vips或其Python绑定进行后处理或调整大小。 - undefined
1
我正在运行OpenCV 4.0.0.pre,这似乎是来自主分支的不稳定开发版本 - 目前可能存在一些混乱,因为新的主要版本正在进行中。除非您正在开发OpenCV代码本身,否则最好使用稳定版本(例如从标签构建的3.4.1版本)。 - undefined
我们还在3.4.0版本上进行了测试,结果相同。 - undefined
@evilblubb 是的,我有点预料到这一点,但觉得提及它很重要。最近我在尝试实现一个新的转换选项时,也注意到了cvtColor中类似的行为。我试着比较了我从中获得灵感的现有实现和OpenCL变体,并没有发现OpenCL变体比并行化的基于CPU的实现更快。我需要进一步深入研究才能弄清楚发生了什么...目前还相当令人困惑,我对此也有同样的期望(而且我已经排除了与GPU内存之间的传输开销,据我所知)。 - undefined
@evilblubb 你可能想尝试启用跟踪(请参考该页面的后半部分),以了解正在调用哪些函数,从而对发生的情况有一些了解。或者尝试进行一些性能分析,看看程序在哪里花费了最多的时间。 - undefined
我会看一下,周末很忙,可能需要一两天时间。 - undefined
2个回答

4

对于像调整大小这样的计算简单的任务,将数据发送到GPU内存并再次返回所需的时间比通过更快的计算节省的时间更长。

特别是因为openCV将使用并行CPU核心和长指令字SIMD优化汇编程序来完成调整大小。


0

GPU具有很高的处理能力,这意味着它比CPU执行计算速度更快,但是当您在代码中执行大量赋值操作时,它并不是最佳选择,因为GPU的内存能力低于CPU。这就是为什么在通过CPU运行代码片段时效率更高的原因,其中操作以赋值为主。


网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接