[参考译文] 运行 TIDL 后、共享存储器被意外覆盖。

鉴于7天过去了、而且 TI 也没有任何回复、我不得不强调、这个问题是多么严重！

此问题会立即导致 TIDL 输出张量旁边的另一个分配数据被销毁、后果悲观。 访问销毁的分配数据时、算法执行的最终结果不正确。 更糟糕的是、当访问已销毁的分配数据时、程序可能会崩溃。

尊敬的 Mark Kang：

很抱歉响应出现延迟。 我将研究这一问题、并在下周向您提供最新情况。

此致、

尼基尔

尊敬的 Mark Kang：

我已将您的更改改为 TIDL 过程函数。 我看到在分段演示情况下覆盖存储器。 但我没有看到物体检测演示的覆盖。

您能否确认您是否也在观察？ 或者、您是否要在所有 DL 演示中观察此情况？

此致、
尼基尔

尊敬的 Nikhil Dasan：  

我们的问题是为什么 TIDL 的 argmax 层会导致意外的存储器被覆盖、以及 TI 计划如何解决该问题。  

(1)为了找出意外的内存被覆盖、我们已经缩小到 argmax 层。  我们使用分割演示来展示这一问题是如何发生的、该演示将 argmax 作为深度学习模型的最后一层。 我们希望 TI 可以根据分段演示找出 TIDL 中存在的问题。

(2)物体检测演示不包含 argmax 层、当然也不存在此类问题、尝试其他不包含 argmax 层的 DL 演示毫无意义。  

Mark Kang。

尊敬的 Anshu Jain：

我尝试使用 SDK8.6、发现同样的问题仍然存在。  Argmax 问题尚未解决、您的召回是完全错误的。

尽管  vision_apps/apps/dl_demos/app_tidl_seg/vx_tidl_target.c 与 SDK8.4略有不同、进行了类似的修改(见下文)

e2e.ti.com/.../5811.vx_5F00_tidl_5F00_target.c

运行从   vision_apps/apps/dl_demos/app_tidl_seg / 开始的演示程序后,控制台仍然显示"修改长度: 10"。 共享存储器仍被意外覆盖。

TI 请注意该问题的严重性并进行修复。

Mark Kang。

此线程被意外标记为错误解决、无论如何请撤消此操作。

尊敬的 Mark：

  很抱歉响应延迟，我们将在9.0 SDK 版本中修复此问题，我们已提交 https://jira.itg.ti.com/browse/TIDL-3362 bug (这是内部链接)来跟踪此问题。 目前、您是否可以增加  输出缓冲区的分配并取得进展？

此致、
安舒

尊敬的 Mark：

我们将在 下一个计划的版本9.0中修复此问题。

与此同时、您可以为 用于 TIDL 输出张量的共享缓冲区分配额外的存储器吗？

大家好、Anshu 和 Kumar、

(1)我们很高兴听到此问题将在 SDK 9.0 版本中修复。  

   修复此问题后、TI 是否可以为 SDK 8.4提供独立的 TIDL 补丁？ 由于我们的客户在开发固件时以 SDK 8.4为基础、没有计划继续开发后续的 TDA4 SDK 版本。

(2)目前、我们可能会尝试分配额外的存储器来防止出现此问题、以此作为您的建议。

Mark Kang。

尊敬的 Mark：

  我们的修复程序将是9.0的一部分、我们必须将 TIDL 从9.0移植到 SDK 8.4。 如果您有任何未解决的问题、请告诉我们？

此致、
安舒

Anshu、您好！

(1)我们不能等到 SDK 9.0发布才解决此问题、因为我们的客户计划在2023年10月之前发布其基于 TDA4的产品。 我们的客户使用的 SDK 版本 为8.4、目前、我们和我们的客户都在基于 SDK 8.4进行固件开发和验证方面付出了巨大努力。 我们的客户已经告诉我们、根据产品计划、没有机会继续使用 TDA4 SDK 版本。 因此、我们需要在 SDK 8.4上安装 TIDL 补丁来修复该问题。

(2)虽然在 SDK 8.4上、我们通过向输出张量分配额外的存储器填充来解决此问题、但  我们只是使用 try and error 方法来猜测此额外存储器应该有多少大小足够。 此外、除非 TI 告诉我们 TIDL 将意外覆盖的确切大小、否则该权变措施方法无法100%保证。

为了在 SDK8.4上100%安全地运行 TIDL，我们需要 TI 提供指南或公式来 计算输出张量的内存填充的确切大小。 我们相信、当 TI 找出此问题的根本原因时、TI 可以向我们提供此信息。

Mark Kang。