deepv3plus模型转换问题

应用开发 算法工具链
, ,
1

1.芯片型号：J3-
2.天工开物开发包OpenExplorer版本：XJ3_OE_1.15.2-
3.问题定位：模型转换-
4.问题具体描述：利用sh 03_build.sh脚本转换模型过程中，共发现了如下4个问题

4.1 模型读取到我的output维度为 [0, 0, 0, 0]，但是我看量化完后的onnx模型维度也是正确的，不知道这对我模型的转换是否有影响。log部分如下所示：-
ONNX IR version: 7-
Opset version: [11]-
Producer: pytorch1.10-
Domain: none-
Input name: input, [1, 3, 512, 512]-
Output name: output, [0, 0, 0, 0]

4.2 在Default calibration in progress处，log打印如下，这对于模型转换是否有影响呢？-
Default calibration in progress: 0%| | 0/13 [00:00<?, ?it/s]2023-05-17 10:58:41.851822862 [E:onnxruntime:, sequential_executor.cc:183 Execute] Non-zero status code returned while running Resize node. Name:‘Resize_140’ Status Message: /home/jenkins/agent/workspace/model_convert/onnxruntime/onnxruntime/core/providers/cpu/tensor/upsample.h:299 void onnxruntime::UpsampleBase::ScalesValidation(const std::vector&, onnxruntime::UpsampleMode) const scales.size() == 2 || (scales.size() == 4 && scales[0] == 1 && scales[1] == 1) was false. ‘Linear’ mode and ‘Cubic’ mode only support 2-D inputs (‘Bilinear’, ‘Bicubic’) or 4-D inputs with the corresponding outermost 2 scale values being 1 in the Resize operator

Default calibration in progress: 0%| | 0/13 [00:10<?, ?it/s]-
2023-05-17 10:58:41,852 INFO Above info is caused by batch mode infer and can be ignored-
2023-05-17 10:58:41,852 INFO Reset batch_size=1 and execute calibration again…-
Default calibration in progress: 100%|████████████████████████████████████| 100/100 [03:34<00:00, 2.14s/it]-
2023-05-17 11:03:09,197 INFO Select max-percentile:percentile=0.99995 method.

4.3 在我的模型中，有3处resize算子，但是前两处是在BPU上处理的，最后一处显示在CPU上，如何让最后一处resize算子也在BPU上运算呢-
Conv_130 BPU id(0) HzSQuantizedConv 0.998633 142.221069-
Resize_140 BPU id(0) HzQuantizedRoiResize 0.998626 180.959702-
Concat_141 BPU id(0) Concat 0.997866 180.959702-
Conv_142 BPU id(0) HzSQuantizedConv 0.997683 180.959702-
Resize_152 BPU id(0) HzQuantizedRoiResize 0.997761 130.957626-
Concat_153 BPU id(0) Concat 0.997822 130.957626-
Conv_154 BPU id(0) HzSQuantizedConv 0.997123 130.957626-
Conv_156 BPU id(0) HzSQuantizedConv 0.999196 122.873146-
Resize_165 CPU – Resize 0.999227

4.4 我的onnx模型能正常推理，但是在量化完成后，利用生成的optimized_float_model.onnx模型推理都不正确，不知道是4.1和4.2的问题还是其他原因呢？-
因为上传限制原因，现将模型放在百度网盘上，链接如下-
链接: https://pan.baidu.com/s/1Ovk0570AVjUuwHycpxPFKg 提取码: errp 复制这段内容后打开百度网盘手机App，操作更方便哦

2

感谢您使用地平线芯片算法工具链，最近我们在收集大家的满意度反馈，欢迎您填写问卷，详细情况可见：https://developer.horizon.ai/forumDetail/146177053698464782

3

也可以参考OE包中的示例哈：

4

你好，

针对问题1，建议使用新版OE1.16.2c对应的docker再次尝试一下，获取链接为：https://developer.horizon.ai/forumDetail/136488103547258769

针对问题2，日志是转换过程中的一些优化尝试，不影响模型转换

针对问题3，在新的docker中进行尝试一下，若依旧在cpu上，可以使用run_on_BPU这个yaml中的参数配置一下看看效果，也可以查看算子支持列表看看是否是因为不满足BPU的约束。

针对问题4，尝试新版工具链后，可以参考这篇文章进行问题定位：https://developer.horizon.ai/forumDetail/71036815603174578

5

你好，

针对问题1，我已经更新到新版OE1.16.2c对应的docker，在执行OE包中的deeplabv3示例时候，发现log如下

ONNX IR version: 7

Opset version: [11]

Producer: pytorch1.10

Domain: none

Input name: input.1, [1, 3, 1024, 2048]

Output name: 705, [0, 1, 0, 0]

其中output输出维度也没有正常显示，虽然也不影响模型的转换（我的模型也能正常转换），算不算一个小bug呢。

针对问题3，我还没有找到run_on_BPU的位置，能否告知其具体位置呢？

针对问题4，我按照提供的链接，把我的原始模型放在docker模型用HB_ONNXRuntime里面推理，发现推理的结果不对，如第二张图所示（在我的环境中推理结果如第一张图），是不是对这个模型的某些节点支持不好呢。

我看了下，aspp结构中dilations参数官方为[6, 12, 18], 由于只支持2的指数，我将其改为[4，8，16]并重新训练的模型。而你们提供的模型dilations参数官方为[2, 4, 8]，并且8是由两个dilations参数为4的卷积组成的。这么更改的原因是否你们也发现了dilations参数过大时效果不好呢？

如果可以的话能否提供你们用于训练deeplabv3puls的仓库呢？

6

1. 关于输出shape未成功解析到，已经复现，我们这边看一下哈~

2. 关于run_on_bpu这个参数可以在手册中yaml中参数详细解读有写，位置可能稍微有点区别：

3. 关于模型训练，我们这边是有进行了一些些改进的，都是源码开发的，可以在下图中位置找到训练脚本

7

对于模型转换以及模型推理

1、按照我的理解，如果我在模型转换中的yaml中norm_type: 配置为’no_preprocess’，且输入为rgb，那么对于onnx模型的推理，在我环境中的代码和docker环境中的代码前后处理代码应该是基本相同的，只有推理接口要换成HB_ONNXRuntime推理，并且设置input_offset=128即可。

2、基于1的理解下，我自己环境中推理onnx模型没问题的，但是在docker环境中转换后用optimized_float_model.onnx模型推理却没有任何结果，应该如何解决呢？

8

使用original_float_model.onnx呢？

9

也没有结果

10

此时就是前处理和使用方式的问题，建议再仔细检查一下哈，因为original_float_model.onnx我们并没有做其它的操作了

11

还有就是后处理，建议先看一下模型输出能否对齐

12

但是初始的onnx模型和original_float_model.onnx模型推理所有代码都是一样的，只不过将onnxruntime推理接口换成HB_ONNXRuntime推理接口。而且在模型转换时，为了避免前处理节点的问题，我还将yaml中norm_type: 配置为’no_preprocess’，这样所有的数据处理都是通过代码实现的。

13

麻烦再确认一下准备的输入数据类型是int8还是float的，用的是sess.run还是sess.run_feature，input_offset是0还是128，在yaml配置中input_type_rt/input_layout_rt和自己准备的数据是一致的。

14

我明白了，在input_type_rt中我配置的是nv12，但是输入数据却是rgb。已解决。谢谢您的解答

15

不客气，记得填一下问卷哈~