• 状态 Resolved
  • 已锁定 已锁定
  • 回复 3 回复
  • 订户 0 订户
  • 视图 255 视图
  • 用户 0 会员在此处
选项
选项
相关

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

[参考译文] AM5728：OpenCV 算法处理延迟

admin
Guru**** 2587365 points
Other Parts Discussed in Thread: AM5728

请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/592526/am5728-opencv-algorithm-processing-delay

器件型号：AM5728

您好！

我正在尝试描述 OpenCV 算法在基于 AM5728的平台上进行背景减除(BackgroundSubtracorMOG2)所花费的时间。
我已启用 DSP 访问、因此、我从 OpenCL 程序中获取以下调试日志-

(笑声)

[内核1] TIDSP 修改的 MOG2 clk=15294248 frame_row=480 frame_col=640 (80a580 80c980 808180) prune =-0.000100
[内核0] TIDSP 修改 MOG2 clk=15297946 frame_row=480 frame_col=640 (80a580 80c980 808180) prune =-0.000100

上述日志似乎表明、在每个600MHz DSP 内核(15294248/600000000)上处理图像所花费的时间约为25.5ms。
我的理解是、OpenCL 程序应在每个 DSP 内核上并行运行、因此、算法处理整个映像(640x480分辨率)所需的时间应为25.5ms。
但是、当我分析算法在 ARM 端处理图像所需的时间时、它几乎是两倍(~51ms)。
每个 DSP 内核上的 OpenCL 程序是否以某种方式串行化？ 或者我在这里缺少什么？

此致、
制造商

  • 0
    TI__Guru**** 2587365 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    软件团队已收到通知。 他们将在这里作出回应。
  • 0
    TI__Guru**** 2587365 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。

    您好、Manu、

    DSP 内核上的执行不会被串行化。 工作分区基于数据输入：因此图像的上半部分由第一个内核处理、下半部分由第二个内核处理。

    您可以在 http://git.ti.com/opencv/tiopencv/blobs/tiopencvrelease_3.1/modules/video/src/opencl/bgfg_mog2.cl 中查看实现详细信息 。

    关于 DSP 和 ARM 上执行时间的差异：报告的时钟直接来自 C66内核、不包括 Linux 用户空间和 DSP 存储器之间的数据传输。

    请注意，此后台估算器具有非常大的状态：大多数状态变量是 SP 浮点(SP32=4字节)。

    实际上、有3个 SP32矩阵(元素数量与像素相同)： 权重、方差、平均值。 模式(uchar)的其他选项。

    因此、除了传输输入图像外、还需要更新大量数据(每帧一次)。

    DSP clk-s 中未考虑这些数据传输、但在进行基于 ARM 的分析时可以看到这些数据传输。

    希望这能有所帮助-此致

    Djordje

  • 0
    TI__Guru**** 2587365 points
    请注意，本文内容源自机器翻译，可能存在语法或其它翻译错误，仅供参考。如需获取准确内容，请参阅链接中的英语原文或自行翻译。
    您好、Djordje、

    感谢您的详细答复。 这很有帮助。
    您所说的内容非常有意义。 但是、很难相信数据传输延迟与处理延迟相同！
    总之、再次感谢您的参与。

    此致、
    制造商