[参考译文] SK-AM62A-LP：无法在 DL 加速器上使用自定义样式模型执行推理

您好！

我看了一下你的模型和模型工件。 模型不应占用足够的内存/DDR 来运行内存不足、如一些打印输出所示。 更有可能是编译过程中出现故障。  

由于我们不支持 Square 节点,您的模型有许多子图(请参阅此处的文档以了解支持的操作)。 我建议修改您的模型,将 Square 替换为 MUL 节点,并将张量本身相乘 .

有时许多子图会引入更高的错误可能性--在这种情况下有更多的临界情况。 对于可以使用1-2个子图(您的有8个、最多为16个)进行编译的模型、这些工具更稳定。

此外、请将批处理大小设置为1、而不是动态值(如-1)

• https://onnxruntime.ai/docs/tutorials/mobile/helpers/make-dynamic-shape-fixed.html 

在此阶段、我建议在没有完整成像流水线的情况下运行此模型、以便您可以在更简单的应用程序中检查该模型。

我建议使用 edgeai-tidl-tools/examples/osrt_python/ort/onnxrt_ep.py 进行该测试。 您可以使用它来编译模型、然后将部分存储库传输到 SDK (大多数情况下、您可以传输除 tidl_tools 目录之外的所有内容、该目录仅用于在 x86上进行编译/仿真)。 然后、对于主机仿真模式、以与 PC 上相同的方式运行(python3 onnxrt_ep.py -m model_name)

• model_name 是 model_configs.py 中条目的名称

在此模式下运行模型时(仅使用单映像)、请运行 debug_level=2。 您可以在模型配置中将其设置为"optional_options" 的一部分、也可以在 common_utils.py 中全局设置。 另外、请在后台运行/opt/vx_app_arm_remote_log.out、然后运行 onnxrt_ep.py 并共享日志。  

总结：

-在您的模型中,将 Square 替换为 MUL 或等效节点
-使用 edgeai-tidl-tools 在目标上重新编译和运行模型。 如果仍然失败、请使用 debug_level=2和运行 后台的/opt/vx_app_arm_remote_log.out 共享编译和运行时日志(仅适用于 EVM)

BR、
Reese

Reese、您好！

感谢您的建议。 我们将所有平方节点替换为多路复用节点、在编译模型时、我们能够在一个子图中获得所有节点。

新的编译模型

e2e.ti.com/.../zero_5F00_dce_5F00_model_5F00_no_5F00_sq.zip

关于在 edgeai-tidl-tools 上运行模型的问题、由于我们的模型不属于三个可用类别(分类、检测或分段)中的任何一个类别、因此程序中没有可以处理写入由我们的模型生成的输出图像的逻辑。 而是尝试在 EVM 上的自定义 python 脚本上运行它。

from tflite_runtime.interpreter import Interpreter as tfl
from tflite_runtime.interpreter import load_delegate
import numpy as np
import cv2
import time

tidl_delegate_path = '/usr/lib/libtidl_tfl_delegate.so'
tidl_options = {"artifacts_folder": "zero_dce_model_no_sq/artifacts","debug_level": 2,}
tidl_delegate = load_delegate(tidl_delegate_path, options=tidl_options)

modelpath = 'zero_dce_model_no_sq/model/zero_dce_model_no_sq.tflite'

input_image = cv2.imread("image.png")

interpret = tfl(model_path=modelpath,experimental_delegates=[tidl_delegate])
interpret.allocate_tensors()
input_details = interpret.get_input_details()
output_details = interpret.get_output_details()

input_image = cv2.resize(input_image, (600, 400))
input_data = np.array(input_image).astype(np.float32) / 255.0
input_data = np.expand_dims(input_data, axis=0) 
interpret.set_tensor(input_details[0]['index'], input_data)
interpret.invoke()

output_data = interpret.get_tensor(output_details[0]['index'])
output_image_data = (output_data[0] * 255).clip(0, 255).astype(np.uint8)
cv2.imwrite("image_processed_no_sq.png", output_image_data)
print ('Done') 
print ('Closing')

此脚本确实运行过、但我们得到的输出是纯黑色图像。

自定义脚本生成的日志：

e2e.ti.com/.../prog_5F00_log.txt

由 在后台运行的 vx_app_arm_remote_log.out 生成的日志

e2e.ti.com/.../remote_5F00_log.txt

我注意到的一件事是自定义 Python 脚本的最终打印语句执行得更早(如 prog_log.txt 的第101行所示)。 我认为这里发生的情况是、甚至在 C7x 加速器完成图像处理之前、CPU 也会对输出文件进行写入。 如果是这种情况、是否有办法使两个进程同步？

您好、Joel：

这种信息/日志是伟大的,感谢您提供。  

你的日志对我来说很普通--我看不到任何关于它们的东西  

Unknown 说：

我注意到的一件事是自定义 Python 脚本的最终打印语句执行得更早(如 prog_log.txt 的第101行所示)。

这是正常的。  在后台运行 TIDL 推理调用时、会创建多个进程/线程。 这些(加上 python 解释器)可能会并行将数据推送到标准输出(stdout)中、以使某些线交错。 这并不表示存在任何问题、它只是并行处理的(不幸的)副作用-毕竟、AM62A EVM 上有4个 A53内核共同运行 Linux 操作系统。

您看到的关于层周期的打印内容以及这些打印内容均来自 TIDL 软件栈内部、在 AI 加速器(C7x DSP 内核)上完成推理之后才会开始打印。 否则、打印会减慢模型推理本身并影响性能和任何内部测量

有关您的精度  

我的第一个估计是您的网络对量化反应不是很好。 默认情况下、TIDL 使用8位量化来计算最初训练并由浮点值组成的神经网络。 有些网络对此的响应更差、弱光增强模型可能就是其中之一。  

这些文档有一些调试建议和指导：

• https://github.com/TexasInstruments/edgeai-tidl-tools/blob/master/docs/tidl_osr_debug.md 
• https://github.com/TexasInstruments/edgeai-tidl-tools/blob/master/docs/tidl_fsg_quantization.md

我通常建议将 tensor_bits 设置为16 (默认值为8)、对您的模型进行量化。 以这种方式编译模型、并检查精度是否可接受。 这会降低性能、但是一项有用的检查

校准也是量化的一个重要部分。 基本上、我们通过您的网络以浮点方式运行映像、并收集有关中间密度的统计数据。 这些帮助我们确定量化参数、以将 fp32范围的一部分映射到整数范围(8位或16位)。 此处使用的图像很重要、因为它们会影响生成的统计数据。 您的模型是针对弱光而构建的、因此使用光照良好的图像可能不会达到正确的激活范围。  

• 您应该怎么做 ：
  • 更改用于校准的图像(不确定您使用的是哪个程序)--使用 edgai-tidl-tools 进行 TFL 编译时、这些图像在此处设置：  
    • https://github.com/TexasInstruments/edgeai-tidl-tools/blob/efae61031b31aa2ba5491c03bb808216d3baef14/examples/osrt_python/tfl/tflrt_delegate.py#L52 
  • 为了进行编译、请将 tensor_bits 更改为16并重试。 结果是否改善？ 运行时延迟是否可接受？
    • 请注意、最好的运行时延迟是 DEBUG_LEVEL = 0。 更高的详细程度将增加延迟

BR、
Reese

Reese、您好！

感谢您的建议。 我们在编译模型时更改了用于校准的图像。  

我们最终能够使用相同的自定义脚本从模型中获取输出。 我们注意到两件事：

1. 模型的输出实际上是一个双精度归一化值数组(pixel_value/255、然后再除以255)、因此这一行
    

   output_image_data = (output_data[0] * 255).clip(0, 255).astype(np.uint8)

   
   实际上是在将数据转换为 uint8类型时仅向输出写入零。 我们 必须进行以下更改才能获取输出图像。 我们不知道为什么会这样。
   

   output_image_data = (output_data[0] * 255 * 255).clip(0, 255).astype(np.uint8)

2. 这是原始图像：
   
   这是经过处理的图像：
   
   输出中有一个奇怪的亮条。 有什么想法为什么会发生这种情况？

您好！

这是进步！

我同意这是奇怪,你需要乘以255再次... 这似乎是错误的、这可能是图像的某些部分饱和的原因。 听起来、网络的输出已包含标准化、这就是您必须执行此操作的原因。 我可以看到这可能会对准确性产生不利影响、尤其是因为数据必须已经经历去量化。 在这种情况下、任何浮点错误都可能会变得更糟。

一些问题可以帮助您朝着正确的方向发展：

如果您在 CPU 上运行(不针对 TIDL 委派)、输出结果会是什么样的？

• 类似地、是否需要进行此附加标准化？
• 该输出看起来是否正常、还是与卸载到 TIDL 时看到的类似？

您现在是以16位模式运行此网络、还是仍以8位模式运行？

类似地、其他输入图像是否具有这种逐行效果？

BR、
Reese

您好！

该模型运行在8位网络上。 我曾尝试使它成为16位、但程序只是挂起。  由  vx_app_arm_remote_log.out 在后台运行生成的日志：
e2e.ti.com/.../4477.remote_5F00_log.txt

在 CPU 上运行模型时、输出数据很清晰、仅标准化一次。

此致、
Joel Jojo.

您好、Joel：

感谢这里的信息和日志。 CPU 版本看起来不错、所以可能与量化有关。

如果原始版本不需要额外的*255 ,那么它实际上是一个带子对真正的问题做这在最终输出。

你能给我提供你目前的一组文物吗? 我很好奇这些第49/50层是什么--它看起来在其中一层挂起。 我看到很多来自卷积层的警告、但这些警告不会发生挂起的情况。 看起来这是在模型初始化期间发生的、但尚未到达推理阶段。  

您是否在实际的 AM62A 目标上运行此端口？ 我们通常建议在调试精度时以 PC 仿真模式运行、但这不是必需的。 许多人认为在 PC 上进行此调试更为方便。

BR、
Reese

Reese、您好！

张量位设置为16时生成的模型伪影：

e2e.ti.com/.../zero_5F00_dce_5F00_model_5F00_no_5F00_sq_5F00_16.zip

该模型正在实际的 AM62A 目标上使用。 有没有方法可以在 PC 上仿真 C7x 加速器、因为据我所见、在 PC 上运行代码仿真仅在 ARM 内核上运行代码。

您好、Joel：

您是否还可以为您的模型提供 model_config 条目、或者至少介绍您是如何编译模型的？ 我无法重现您遇到的问题。 在校准期间、我在编译期间确实看到了 SEG 故障、这可能是由于没有正确的预处理参数(标称均值和缩放值)而导致的。

我尝试了使用以下工具、但没有得到合理的输出

    'zero_dce_model_no_sq':
    {
       'model_path' : os.path.join(models_base_path, 'zero_dce_model_no_sq.tflite'),
       'source' : {'model_url': 'dummy', 'opt': True,  'infer_shape' : True},
       'mean': [0,0,0],
       'scale' : [1,1,1],
       'num_images' : numImages,
       'num_classes': 1000,
       'session_name' : 'tflitert' ,
       'model_type': 'low-light',
       'optional_options': { 
         'debug_level': 1,
         'tensor_bits': 8
       }
    },

我在 tflrt_delegate.py 中添加了一些代码、以将"model_type"设置为"弱光、但会添加您的图像和后处理代码(mul by 255、并剪切到 uint8)。 使用此配置在 CPU 上运行不会产生输出、而使用 TIDL 运行会产生较差的结果。 在我这边(TIDL_TOOLS 10_00_06_00)、tensor_bit 8和 bit 16的编译失败、在定点执行校准期间似乎会发生

Unknown 说：

是否有方法可以在 PC 上模拟 C7x 加速器、因为据我所见、在 PC 上运行代码只模拟在 ARM 内核上运行代码。

是的、PC 上的相同代码(适当设置 TIDL_TOOLS_PATH 环境变量(也是编译所必需的)应该在 PC 的 C7x 仿真器上运行。 如果您的模型仅在 PC 的 CPU 上运行、则可能未正确生成模型工件。  

Reese、您好！

我们在 TIDL 工具中修改了 model_configs.py 文件中的一个模型配置、然后使用 tflrt_delegate.py 脚本来编译它。

"zero_dce_model_no_sq": create_model_config(
    source=AttrDict(
        model_url="",
    ),
    preprocess=AttrDict(
        resize=(600,400),
        crop=(600,400),
        data_layout="NHWC",
        resize_with_pad=False,
        reverse_channels=False,
    ),
    session=AttrDict(
        session_name="tflitert",
        model_path=os.path.join(models_base_path, "zero_dce_model_no_sq.tflite"),
        input_mean=[0, 0, 0],
        input_scale=[1 / 255, 1 / 255, 1 / 255],
        input_optimization=True,
    ),
    task_type="custom",
    extra_info=AttrDict(num_images=3, num_classes=0),
),

我们通过直接修改 common_utils.py 中的变量更改了张量位

此致、
Joel

您好、Joel：

感谢您通过此配置、现在我可以更有信心地重现您的问题。  

我还没有找到一个可行的解决方案。 我看到 PC 上使用您的配置基于 CPU 的执行具有很高的精度。 我加入 TIDL 后、我看到8、16和32位伪影的黑色图像(所有输出像素=0)在 PC 上模拟它们以检查准确性-这不是典型的、我怀疑有一个错误。 您已经看到、模型本身的输出是低值浮点。

我怀疑 Tanh 激活或条纹切片可能会引起一些奇怪的事情。 这不是真的 、但精度下降似乎发生在 StridedSlice 和输出之间的层中。

• 当我 强制 Tanh 层和此后的一切 CPU (与前面的层模拟加速器),输出看起来合理(视觉特征都存在,但不像你的原始图像那样明亮)。 如果让网络访问 Convs 和 Tanh、则情况也是如此、但强制 StridedSlice 之后的层在 CPU 上运行。

这告诉我、可能导致此处精确度问题的是多个 Elementwise (add、mul、sub 等)层。 如果使用 debug_level=3运行模型、它将在/tmp 目录下生成跟踪。 可以通过 tool like NumPy 加载二进制文件来检查这些文件

data_last_og = np.fromfile('/tmp/tidl_trace_75_0049_0001_0001_00001_00003_00600x00400.y', dtype=np.int8)  

文件名的位置取决于图形的编译方式。 对于 TIDL 运行的每一层、用户都会得到一个.y 输出文件。 当我观察这些时、我看到这些值不是零值、它们仍然包含信息、并且粗略地阅读->重塑->转置->写入到文件显示了有意义的视觉特征(尽管有些暗)。 量化的程度(8或16位)不会对其产生重大影响。

浮点输出看起来太小了,但我目前看不到比简单地重复*255缩放更好的方法。 在最近的一篇评论中、我非常抱歉向您推了一个不同的方向。 我认为这会在我们堆栈中的某个位置构成一个错误、可能是32位流程中的一些缩放、用于在编译期间收集张量值的范围。  

因此、我的建议是：

• 按255*255的比例缩放输出、继续操作
• 我将在这里收集一些信息、并以一个错误的形式记录--我认为它与 Elementwise 层和一些正在使用的缩放有关

此外、请注意元件层并非特别高效(在计算利用率和内存方面)、尤其是考虑到这些元件层在3x600x400输入上运行的大小和数量。 这些层对您的模型至关重要、因此我不会直接提供替代方案的建议。 卷积和矩阵乘法将显著提高效率。

Reese、您好！

我们将源代码中带条纹的切片运算替换为卷积、然后重新塑造运算。 我们能够从这一变化中获得更好的结果。

模型的源代码如下： https://colab.research.google.com/drive/17GckQm8LXURnkJDEqVYcAtLJqlShDYYb?usp=sharing

对您的终端源代码有任何建议？

此致、
Joel Jojo.