[参考译文] TDA4VH-Q1：TIDL 编译会根据图像大小冻结

您好 Olof、

对该模型的初步分析表明、TIDL 不支持许多层。  这意味着它们将在 ARM 内核上运行。  这要慢得多。  此外、输入数据也有点奇怪。  正常图像输入数据为 3xHxW。   此型号的输入为 92x24x32、但仍为“图像“。  这是正确的吗？   

----------------------------------------------------------------------------------------
|核心|节点数量|子图数量|
----------------------------------------------------------------------------------------
| C7x | 45 | 5 |
| CPU | 37 | x |
----------------------------------------------------------------------------------------

上述输出报告不支持 37 个图层、它们会生成 5 个子图。  这意味着每次从 C7x 切换到 ARM 时都有一个上下文切换。  我将进一步研究这一点、但如果我们让这个模型正常工作、它将不会运行得非常快。   

此致、

Chris

这很奇怪。 正如您在 log.txt 中所看到的、这是我在运行时看到的内容：

-------------------------------------------------------------------------------
|          Core           |      No. of Nodes       |   Number of Subgraphs   |
-------------------------------------------------------------------------------
| C7x                     |                      67 |                       1 |
| CPU                     |                       0 |                       x |
-------------------------------------------------------------------------------

即 67 个节点、所有这些节点都被 列为受支持节点。

您是正确的、因为此模型的输入不是图像。 而是从图像中提取的特征。 原因是我将问题隔离到了图形的这一部分。 为了给你一个更容易的时间调试,我只提供了一部分,引起冻结。 此器件工作之前和之后的所有内容。

您好 Olof、

我已经用您的脚本进行编译了。  我通常不喜欢使用修改后的脚本并坚持使用标准 TIDL 工具、但在本例中、它是有效的。  我能够在 Docker Ubuntu 22.04 映像中使用以下 TIDL 版本信息编译和运行 model.onnx：

| TIDL 工具版本| 11_00_08_00 |
----------------------------------------------------------------------------------------
| C7x 固件版本| 11_00_08_00 |
----------------------------------------------------------------------------------------
|运行时版本| 1.15.0 |
----------------------------------------------------------------------------------------
|型号选项版本|18|
----------------------------------------------------------------------------------------

我认为 model.onnx 是您遇到问题的一个。  是这样吗？  成功运行的模型的 md5sum 为：

4c45697d0d9949a547cfe918131fc4de ./../../model.onnx

我附加了编译和运行日志。  我认为图像大小没有改变、但看起来正在运行。  附加的运行/编译日志。

此致、

Chris

感谢您试用！

确实是 model.onnx 导致问题。 我得到了同样的 md5sum 在我的身边。

因为它运行为你,我尝试重新安装 dockers ,无论有没有 GPU,它实际上是编译。 但是、这两种情况都需要一个小时、这很奇怪、因为我们只有一次校准迭代。 您需要多长时间？ 在任何情况下、它仍然不能在 TDA4VH 卡上运行。

您好 Olof、

注意了名字  以为这是一个私人论坛为你,但它不是。  我从未让 TIDL 与 GPU 搭配使用、许多人也曾尝试过、如果它实际上要用于 GPU、恭喜您。  我只在 CPU 模式下在 Ubunut 22.04 上运行,您的模型需要大约 2-3 分钟的时间来编译,而不是一个小时。  其他部分结束了。  您能否仅在 CPU 上尝试一下、看看它有什么不同？

我会尽力而为。 示出 AM69A（与 TDA4VH 相同的处理器）上的工件、并向您发送更新。

此致、

Chris

您好 Olof、

您是否尝试使用 GPU？  我之所以会这样问,是因为我认为使用 GPU 不正确,或者所有的恒星都需要对齐。 您可以尝试仅在 CPU 上进行编译吗？  在 Ubuntu 22.04 计算机上编译不到 5 分钟、这不是很令人印象深刻。  一个小时意味着出现了问题。

此致、

Chris  

顺便说一句、我现在不需要 AM69A 了几个小时、因为我今天允许有人使用电路板、所以我还无法进行测试。

Chris

早上好！

我仅使用 CPU。 我没有设置 TIDL_TOOLS_TYPE 标志、这应该会将工具默认为 CPU、并且 nvtop 在编译期间不会报告任何 GPU 使用情况。

当您有机会在板上测试您的工件时、请告诉我！

Olof

再次向 Chris Tsongas 致以问候！

您是否已经取得了任何成功？

Olof

您好 Olof、

由于带宽的原因、Chris 有点忙、因此我将提供帮助。 请给我一些时间来进行测试、并让电路板运行的工件。 我将发送有关最新星期五状态的更新。

谢谢您、

Christina

你好 Christina！

感谢您的关注！

Olof

您好 Olof、

您能分享设备上出现的挂起或错误吗？ 我相信我已经能够重新创造它,但需要比较。  

此外,在编译方面,我的汇编大约耗时 23 分钟。 我的 Ubuntu 22.04 机器 不像 Chris 那么快、因此我期望的数字会更低。 1 小时编译也可能因您的设置而异。  

我将尝试使用替代流程 (TIDLRT) 而不是 OSRT（Github 上显示的内容）重现问题、并查看这是否只是 OSRT 行为。  

此致、

Christina

您好！

我附加了一个文件、其中包含在 64 小时的推理时间后在器件上观察到的输出、但在几秒钟内我们已经观察到了所有输出。 将其称为推理时间可能会产生误导、因为在推理实际开始之前模型似乎已冻结。 该模型使用debug_level=6和运行TIDLRT_DEBUG=1。

似乎我们找到了一个关于长时间编译的部分解释。 当编译失败时、进程不会像预期的那样终止。 相反,我们必须用 Control+C 来杀死它 显然,这也不会杀死这个过程,而是在后台继续,占用资源。 正确停止进程后、编译时间会缩短、但仍然不成比例地很长。

此致  

Olof

e2e.ti.com/.../output_5F00_card.txt

您好 Olof、

今天是美国假日、因此请期待明天我的答复。  

感谢您的耐心。

此致、

Christina

您好 Olof、

Ctrl+C 实际上是一个已知错误 (Jira TIDL_7842)、可能会在下一个版本中修复。 对于您共享的参数、您是否  已在 DEBUG_LEVEL=0 且未设置 TIDLRT_DEBUG 的情况下运行模型？

此致、

Christina

再次大家好！

到目前为止debug_level=6  TIDLRT_DEBUG=1、我们使用了和、但现在我们尝试在 debug_level=0  且 取消设置 TIDLRT_debug 的情况下再次在器件上运行模型。 但是模型仍然冻结。

Olof

您好 Olof、

我回来了。  我再次将其重新运行到级别设置。   我在我的机器上定时编译、花费了 808 秒。   有点长、但不在小时范围内。  推理很快。  当尝试 不挂起模型时、调高调试级别会使情况更糟。   增加调试将写入磁盘、与您的模型无关  的任何 IO 问题也会导致磁盘挂起。  最好在默认情况下将其关闭。   您是否尝试过在 Docker 映像外部或仅在 Docker 映像中运行编译？

我在编译日志中包含了一个带有执行时间的编译和推理日志（最后）。 再次提醒我、由于您的模型运行、问题在哪里？   

此致、

Chris

e2e.ti.com/.../inference.loge2e.ti.com/.../7750.compile.log