码部落

在上一个日记中记录的问题，最近进行了验证和解决。其中的问题1、aclInit(“acl.json”)  一个进程只能调用一次。这个进一步验证了。所以，只能从代码本身入手进行解决。需要在主线程一开始就调用这个初始化。并且，验证了，这个初始化是可以与子线程无关的。即，这个初始化就是这么调一下哪个函数，不用向下传递什么参数、数据或者指针什么的。另外，在结束时调用 aclFinalize() ，虽然，调用了这个并不能再重新调用  aclInit()  这个重新初始化。但本着有头有尾，以防出现什么内存泄漏问题，还是要按套路来。在程序结束时调一下这个。

第2个问题是，“调用aclInit(…) 函数的线程必须与后面调用 aclrtMalloc( …) 和 aclrtMemcpy(…) 的是同一个线程，否则会报提示不能取得硬件资源的错” 这里需要注意的是子线程中在开始时，必须调用  aclrtSetDevice()、aclrtCreateContext()、aclrtCreateStream() 这三个函数，当然也可以在每次处理时循环调用这个和 Destory() 但这样性能不好。这三个的作用是调置调用的NPU设备号，创建上下文 ，创建一个处理流。相当于告诉设备哪个线程对应的是哪块数据。如果三个函数在主线程上执行，哪子线程在处理时就会抛没有上下文 ，或者没有stream的异常错误。并且需要在每次调用NPU处理时都调用一下aclrtSetCurrentContext() 函数，让NPU处理指定上下文的数据，否则会抛异常。

最后，还是有个比较奇怪，不知是硬件设计就是这样，还是代码还是有哪里不对的问题。虽然，最后使用一些感觉好像是折衷的方法，还是就是这样的方法实现了同一个NNN核，同时多线程运行多个模型 （目前测试了同时运行4个），但就是感觉怪怪的。

1、代码中不能使用SDK提供的异步处理函数  aclrtMemcpyAsync()、aclmdlExecuteAsync() 。 调用 aclrtMemcpyAsync() 时会抛内存不足的异常提示，但我板上内存明明是足够的，数据也不是很大。只能调用 aclrtMemcpy()。使aclrtMemcpy()，然后调aclmdlExecuteAsync()，会卡死。只能调aclmdlExecute()。
2、这样分别调aclrtMemcpy()，aclmdlExecute()是不会卡死了，但在多线程时，还是会因为冲突跑着跑着就卡住不动。所以，最后，我只能人为加入线程锁，实现多线程单核处理多个模型。但这样感觉NPU不是并行处理多个模型，而是互斥的一个个交替处理。

本来以为关于SS928 的NNN 的这个NPU的应用开发差不多可以告一段落了，但最近在做外围的功能的时候，还是发现一些问题。这些问题还是值得记录一下，以免日后忘记。

1、官方库的aclInit(“acl.json”) 这个初始化函数在整个程序进程只能调用一次，即使后面调用了 aclFinalize() 这个函数，也不能再次调用aclInit() 进行初始化。这将使程序报错。

2、调用aclInit(…) 函数的线程必须与后面调用 aclrtMalloc( …) 和 aclrtMemcpy(…) 的是同一个线程，否则会报提示不能取得硬件资源的错。

当需要在块SS928开发板上同时运行多个模型处理一路视频，或者多路视频用一个模型处理，甚至是多路视频使用多个模型处理，并且还得在一个程序进程里进行多线程处理的时候，这些就是需要注意和解决的问题。

关于海思3403-SS928 的4.8T 的NPU 的开发，我基本已经搞明白了，包括ATC的模型转换的使用和代码ACL库的调用部份，可以实现由YOLOV5、YOLOV11 的模型转换和模型推理的整个流程。相关的部份代码，我已开源并放在：

https://github.com/marblech/hisi_3403_SS928_yolo

之后还有一些性能提升的处理有待进一步研究和试验。例如，在前处理上使用官方文档上的AAPP 技术，模型使用量化的方式，把原生的FP32 量化成 INT8 ，还有通过什么方法把 后处理NMS 整合到OM模型（这个不确定是不是可以，从某些网上的文档上看好像是可以的）。因为项目的原因，这些可能短期内不做研究了。

因为实际项目需要，昨天又做了一遍yolov5的模型转换和后处理的代码开发的工作，过程中居然还是发现了一个坑的点。这里说的并不是新的 5.6 T算力的哪个 svp_npu的模型转换，而是还是哪个4.8 T 的哪个，官方文档上说的 “NNN” 的哪个 npu 的模型转换。需然这条路我在前天终于走通了，但今天还是在模型转换时遇到了个坑，然后发现了个官方文 档的问题。这个问题是这样的，以下是官方文 档的原文 ：
9.1.3 ONNX 算子规格
该算子规格仅适用于ONNX原生IR定义的网络模型。算子详情请参见《Caffe&ONNX算
子规格清单》>支持ONNX算子清单.。
如果要查看基于Ascend IR定义的单算子信息，请参见《CANN 算子规格说明》手册。
当前支持的ONNX版本为1.8.0、Opset版本为v9~v13、ONNX Runtime版本为1.6.0。

这里说Opset 版本为v9-v13 但实际中，我使用了opset v10  版本把 yolov5s.pt 转为onnx 后，再把这个 yolov5s.onnx 转为 .om 时就会报  Resize 138 节点 input size error 的错误。这个问题折腾了很久，最后发现，就是 .pt 转onnx 时，选用了 v10版本的Opset , 而使用 v12 版本的 Opset 就不会产生这个 Resize138 input size error 的错误。