工具/软件:
您好:
我们发现、与 使用 tools 10.05构建的相同模型相比、使用 tools 10.1构建的模型性能是不可接受的。
它首先在编译阶段收到了一些警告、考虑到某些 SLIC 和转置层不受支持。 在器件上运行时、该模型的精度不可接受。
在编译期间设置 RT.GraphOptimizationLevel.ORT_DISABLE_ALL 后、警告会消失、但它不会提高模型的精度。
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.
工具/软件:
您好:
我们发现、与 使用 tools 10.05构建的相同模型相比、使用 tools 10.1构建的模型性能是不可接受的。
它首先在编译阶段收到了一些警告、考虑到某些 SLIC 和转置层不受支持。 在器件上运行时、该模型的精度不可接受。
在编译期间设置 RT.GraphOptimizationLevel.ORT_DISABLE_ALL 后、警告会消失、但它不会提高模型的精度。
您好 Alex、
您正在将哪个版本的 edgeai-tidl-tools 与 SDK 版本10.1和10.05配合使用? 您能否 确认用于每个编译的 edgeai-tidl-tools 标签和 SDK 版本是兼容的、并且 版本兼容性表的"注释"列中所述的任何步骤都没有遗漏?
发行说明 : https://github.com/TexasInstruments/edgeai-tidl-tools/releases
谢谢您、
法比亚纳
您好 Alex、
我已运行您的模型、目前正在尝试重现此问题。 我在电子邮件中看到您有自己的脚本来测试准确性(full_test.py)。 这是您可以分享的内容吗?
如果不是、电子邮件中的哪些号码是准确的? 是1.65--01范围内的较大器件吗?
我正在使用 edgeai-tidl-tools 版本10_01_04_00和 10_00_05_00。 如果您使用的是不同的、请告诉我。
此致、
Christina
尊敬的 Christina:
我将对两个版本使用相同的测试- 10_00_05_00 (向后兼容 SDK9.2)和10_01_00_01。 我运行一个输入、同时对32位和16位量化模型进行推理。 我将比较所有输出16位与32位、只是计算一个绝对差分误差。 我在10_01_00_01中收到非常高的差异,而10_00_05_00中的错误很小~[1e-3 : 1e-2]。
我附加了脚本、以便可以运行并重现它。 如果您需要设置工件路径和 onnx files.e2e.ti.com/.../full_5F00_test.tar.gz、则它使用 YAML 文件运行
您好 Alex、
我比较了输出值和 Key 的10_00_05_00和10_01_00_04之间的结果以及两者的绝对差值误差。 两个版本之间的一切都是相同的,有相同的差异。 我运行了示例下的 onnxrt_ep 脚本并通读。
我试图让你的脚本 full_test 为我工作,但我一直得到一个分割核心转储每当我运行. 我认为你的脚本中所做的数学运算可能存在问题,因为根据你的屏幕截图,一些数字与其他版本相匹配,而其他的则不匹配。 可能是由于某些输出为负。
您能否尝试运行 TIDL 中包含的 onnxrt_ep 脚本、看看您是否仍能看到不同的输出、或者看看脚本的数学运算是否确实存在错误?
此致、
Christina
尊敬的 Christina:
只是为了确保我们在如何重现问题方面保持一致。 您应该有两个版本的输入图像和伪影。 我与您共享的脚本可以执行多项操作-模型编译、CPU 仿真推理以及器件上的推理。 您不需要创建伪影、重点是测试给定输入的两个版本的量化推理和32位推理之间的平均均值误差。 还请注释第74行(so.graph_optimization_level = RT.GraphOptimizationLevel.ORT_DISABLE_ALL)运行10_00_05_00推理时-编译是在没有此参数的情况下运行的、稍后当我遇到10_01_00_04编译的一些奇怪警告时、TIDL 团队建议这样做。
谢谢您、
Alex。
您好 Alex、
我遵循了过去的吉拉斯的所有指示,包括第74行的取消注释,因此没有看到错误。 行223和226上的设置已经设置,但它仍然不允许我用你的脚本重现。
我只是在脚本之外对 CPU 仿真进行了模型编译和推理、因为这是我们确保可重现性的常规做法。 我也为此重新编译了工件。 我比较了在执行16位和32位推理时的平均平均误差。
我再次使用您提供的图像中的另一张图像运行所有内容、并在两个版本的输出中获得相同的结果。 只是为了更彻底地解释我在 OSRT 上所做的步骤
1.将 common_utils.py 张量位值设置为32
2.运行 onnx_rt.py 编译和推理
3.请参阅 Value 和 Key 的输出、转换为.txt 以实现32float
4.重复16个 int
5.通过减去.txt 文件来查找绝对错误
5.重复10.00.05.00
6.检查10.00.00.04与10.00.05.00之间的差异(没有任何差异)
我附上了我在10.01.00.04上生成的工件、以防这些工件对您有用。 现在、我确实认为需要通过 OSRT 进行检查、因为我在我这边看不到问题 您是在仿真器件还是仅在器件上看到此问题? 我假定这是仿真和器件。
此致、
Christina
您好 Christitna、
当您使用单个图像编译伪影时、您会过度适应它、并且在使用相同的输入进行测试时、一定会获得不错的结果。 执行 PTQ 时、我使用包含128个图像的校准集构建伪影、从而对该校准集进行64次迭代。 我在这里附加了工件、这样您就可以对它们进行测试。 这些来自10_01版本、请运行我提供的推理脚本、并接收所有输出、而不仅仅是 Key 和 Value。 请更新您收到的16/32 Mae。
谢谢您、
Alex。
您好 Alex、
对延迟回复表示歉意。 我试图验证我的结果以仔细检查、但下面是 我能够为10.1e2e.ti.com/.../Leddar_5F00_10.1_5F00_outputs.zip 收集的输出
我在使用您的工件获得10.00.05的结果时遇到了一些困难、这似乎与您的问题相反、因为10.00.05在您的最后工作、所以我一直在尝试调试。 是否有另一组用于10.00.05的伪影? 我假设这是你用于两个相同的工件,但我尝试了两个工件你已经与我分享,以防这是一个问题与他们。
我也一直在尝试让你的脚本在一边工作,但它仍然给出了一个核心转储每当我使用它. 正因为如此,我试图创建一个脚本,做同样的事情,你来解决这个问题。
当我查看这些结果时、虽然我只检查了一些输出(Key、TEgor 和 Value)、但我确实注意到 Value 现在对于10.1有许多零输出。 我正在尝试复制结果、以查看这是否与其他图像一致、或者在切换伪影和图片时是否是我的终端用户错误。
此外、我想再次检查您是否能够设置 兼容性表的注释部分所述的额外 C7x 固件补丁? 我假设您是从我的同事提到它(第一个答案)、但只是为了确保它被漏掉。
但是、由于我仍在确保我可以复制您的问题的过程中、您可以执行一个层分析来进一步确定模型中可能发生这种不匹配的位置。 通常的方法是将调试级别设置为4、并查看.y 和.bin 输出进行比较。 以下说明进一步说明了如何执行此操作
还有另一个名为 layer_trace_inspector.py 的工具、其设置稍微更复杂、但一旦完成、就会对调试有所帮助。 此处提供了相关链接
由于主要问题与伪影有关、我只是使用这些来确认伪影是否都正确通过了两个版本的模型、这是一个很好的测试。
对回复的延迟再次表示歉意。 我试图确保我包括了我调查过的所有内容、即使它们仍在进行中。
此致、
Christina
您好 Christitna、
我有2个不同的工件、在10.00.05上、这与 SDK 9.2向后兼容、并且运行正常。 我没有把它寄给你,因为我想让你专注于10.01.00.04的非工作文物。
当使用我的脚本运行时、您何时收到内核转储? 处理这些数据呢?
" 值现在10.1有多个零输出"是什么意思?
我知道兼容性表、这仅与正常工作的10.00.05相关。 在构建 SDK 时安装了所有需要的补丁、因此它在我们这边可以正常工作。
谢谢您、
Alex。
感谢 Alex 的澄清。 如果我还可以收到10.00.05内的伪影、那么在比较和查看预期输出时、如果此问题实际上是一致的、则 Jira 将很有用。
是的,每当我运行你的脚本在推理期间,我会得到一个分割转储*(我之前误键入)
当转换为32位和16位文本时、Value.bin 输出在我最初传递它时显示多个零输出。 我检查的其他输出没有此问题、我不确定输出是否正确(这就是创建正确输出以进行比较的10.00.05伪影的原因)。 我正在尝试再次检查这是否与您现在包括的其他图像一致。
我很高兴您检查了10.01.04.00的兼容性表。 我只是想确保情况,因为这是其他客户错过的。
我很快会再发送一个更新。
此致、
Christina
尊敬的 Christina:
感谢您的快速更新。
请根据您的请求找到随附的工件10.00.05。
您好 Alex、
以下是确保一切正常后第二次运行10.1.4.0的输出。 e2e.ti.com/.../Leddar_5F00_trial2.zip
不幸的是,我无法让你分享的10.0.5.0新的工件在我的最后仍然工作,因为它会在编译中途停止。 "我要去看看你。
请注意、TI 明天将于星期五上午好假期度假、直到星期一我才会回复。 但请注意、目前我仅在您的 E2E 上工作。 我将在星期一向您提供有关我进度的最新信息。
此致、
Christina
尊敬的 Christina:
是的、在这里、我不知道输出的顺序、因为我打印了所有输出:
顺便说一下、我想我知道为什么在运行10_00_05工件时得到核心转储-您需要注释掉 so1.graph_optimization_level = RT.GraphOptimizationLevel.ORT_disable_all、因为工件是在没有此参数的情况下编译的。 我开始使用此作为 Chris 的建议来消除一些新出现的警告、考虑使用 tidl_tools 10.01执行 Slice 操作。
谢谢您、
Alex。
您好 Alex、
有几个更新和一些步骤需要改进。
更新:
1.通过禁用 RT.GraphOptimizationLevel.ORT_DISABLE_ALL 并生成输出,我修复了昨天的10_00_05_00工件的挂起问题(您的扣除是正确的)
2.我曾要求您的输出进行比较,但由于我不确定是哪个输出,我无法真正使用它。 我附上了我昨天生成的输出
e2e.ti.com/.../Leddar_5F00_trial2_5F00_100.zip
3.比较值区间时,我可以看到,对于16位和32位输出, 10.1和10.0有不同的数字,其中10.1有许多零。 所以我能够看到它们之间的不匹配。
前进的步骤:
根据我的理解、 在比较时、您需要将两个版本(10.1和10.0)都设置为禁用或启用 RT.GraphOptimizationLevel.ORT_DISABLE_ALL。 这会导致模型的行为不同、这会导致在比较时出现不匹配。 您是否可以在启用此功能的情况下创建10.0的工件、然后在它们之间运行比较? 这将更准确地评估启用后它们是否确实不同。
在您选中此项或发送10.0的新工件并 启用 RT.GraphOptimizationLevel.ORT_DISABLE_ALL 后、我可以提交 Jira。
Jira 问题将取决于此比较的结果
1.如果 在启用 RT.GraphOptimizationLevel.ORT_DISABLE_ALL 后10.0和10.1的结果可比较、则我们将知道问题是两个版本都不能接受启用此功能时的精度。
2.如果 在启用 RT.GraphOptimizationLevel.ORT_DISABLE_ALL 后10.0和10.1的结果不可比较、10.1仍具有较差的值、则问题仅在10.1中出现
期待再次聆听。 如果您有任何问题、敬请告知
此致、
Christina
尊敬的 Christina:
我编译了10.0的工件、并 按照您的请求启用了 RT.GraphOptimizationLevel.ORT_DISABLE_ALL。 我收到的精度结果与之前相同。
只是为了向你解释为什么我开始使用这个标志10.1 -这一切都是在编译相同的 ONNX 10.1时,我开始收到一些突然的警告。 警告是由于 Slice 不支持的操作,这是奇怪的,因为10.00.05没有这样的问题。 人工制品也不起作用。 向 TI 打开此错误后、他们建议添加此标志、这可以解决警告问题、但不能解决主要的精度问题。
我附加了使用标志编译的10.00.05工件、因此我们在此项中将与10.01匹配。
e2e.ti.com/.../Artifacts_5F00_10.00.05_5F00_with_5F00_ORT_5F00_DISABLE_5F00_ALL-.tar.gz
谢谢您、
Alex。
尊敬的 Christina:
我也尝试使用你在上面的线程中建议的 layer_trace_checker 工具。 但是、我不明白什么是 ONNX 跟踪文件夹内容、因此我陷入了困境。 我使用 debug_level=4选项导出16位量化模型和32位原始模型的每层二进制文件、但它看起来对 ONNX 跟踪有其他期望。
您能否帮助我了解提取 ONNX 跟踪需要什么?
谢谢您、
Alex。
您好 Alex、
由于你收到相同的错误与这些新的伪影,我只需要在我的最后重新创建它,并提交 Jira。 使用 Jira 编号完成此操作后、我会让您知道。
LAYER_TRACE_CHECKER 工具必须在 tidl_tools 下通过使用导入和推理配置文件来完成。 我认为这可能需要很长时间才能正确设置,所以我建议使用 OSR debug : https://github.com/TexasInstruments/edgeai-tidl-tools/blob/master/docs/tidl_osr_debug.md
此致、
Christina
尊敬的 Christina:
请查找附件。
e2e.ti.com/.../calibration_5F00_dataset.tar.gz
谢谢您、
Alex。
您好 Alex、
TIDL 11.0刚刚发布。 下面是 GitHub: https://github.com/TexasInstruments/edgeai-tidl-tools/releases
这应能解决您遇到的精度问题。 如果您继续让 holdup 测试此新版本、请重新打开此主题。
此致、
Christina