NNIE的运行机制

NNIE的运行机制

一：背景

       由于当前主流算法中都使用了深度学习算法，而深度学习算法在移植过程中，基于带有的NNIE推理单元的Hisi芯片将极大的提高算法模型的推理，加速算法计算，从而便于算法落地上车。故而本文将简要说明NNIE的运行机制，主要包括如下部分：

a:NNIE的运行机制

b:单/双核NNIE的调度逻辑

c:多算法并行的可能资源限制条件

二: NNIE的运行机制

       NNIE 是 Neural Network Inference Engine 的简称，是海思媒体 SoC 中专门针对神经网络特别是深度学习卷积神经网络进行加速处理的硬件单元。NNIE作为海思开发框架中所处的位置如下图1，当前支持现有大部分的公开网络，如 Alexnet、VGG16、Googlenet、Resnet18、Resnet50 等分类网络，Faster RCNN、YOLO、SSD、RFCN 等检测网络，以及 SegNet、FCN 等场景分割网络。

目前 NNIE 配套软件及工具链仅支持以 Caffe 框架，使用其他框架的网络模型需要转化 为 Caffe 框架下的模型。

                                                            

                                                                                                         图1：海思SVP开发框架

       NNIE在系统中的位置如下图2：

                                                  

                                                                                    图2：NNIE在系统中的位置

       从上面的NNIE在系统中的位置可以看出，与NNIE模块交互的单元主要有两部分，DDR和CPU。NNIE 硬件只能从 DDR 中获取数据。如果用户在调用 NNIE 任务时，访问空间可cache 而且 CPU 可能会进行访问，为了保证 NNIE 输入输出数据不被 CPU cache 干扰，此时用户需要调用专门的HISI接口刷cache，将数据从cache刷到DDR，NNIE 单元使用DDR中数据作为输入，用于后续的推理。一个常见的流程是，在DDR中会加载模型参数（Para data），当有数据（Source Data）需要做推理时，需要将CPU中数据刷cache到DDR，NNIE获取数据后，并将结果输出（Result Data）。CPU端可获取输出结果，并进行后续的后处理操作。

三: 单/双核NNIE的调度逻辑

       针对一个深度学习模型，一个完整的调用流程如下图3所示：

                         

                                           图3：模型整体调用流程

       如上图3中描述了深度学习算法的流程图，其中主要包括，模型的加载，数据的填充，算法的推理，后处理，模型卸载部分。在Hisi芯片上能够推理的模型一般是由caffe模型转换出的wk模型，通过加载wk模型，可以获取和模型相关的信息，一般需要关注模型的输入信息和输出层结构体信息。输入层信息，确定了模型的推理所需的数据及格式，依赖的格式和数据不正常可能会导致后续的Forward推理异常。

       实际上针对单核NNIE和双核NNIE在策略和调度上一致的，算法模型的推理可以同时跑在两个核上。在实际运行中，和NNIE核相关的只有Forward模块，此处用到了NNIE核的计算资源。在进行推理时，可通过参数可选择推理计划使用的核。推理进行时，两个核中所进行的计算可以并行进行，并不会相互影响。需要注意的是，针对对单一NNIE核，只能串行执行。                                               

四: 多算法并行的可能资源限制条件

在基于Hisi芯片的设备上跑多算法，可能会受限于如下因素的影响。如下是一些影响较大的限制因素：

a：MMZ的限制

b：CPU和flash的限制

c：DDR的限制

 4.1 MMZ的限制

       关于MMZ（Media Memory Zone,多媒体内存区域）需要说明的是，海思平台内存主要划分两部分，一部分是系统使用的OS内存，一部分是MMZ的内存。OS就是操作系统的内存，会随着进程的退出而自动释放，而MMZ只要是给海思的MPP系统，还有NNIE引擎等硬件资源使用的，如果不手动释放的话，即使进程退出，也不会自动释放。会导致多次启动退出进程后MMZ内存被占用。这两部分内存的分配，在系统启动时由uboot参数决定。需要注意的是：malloc不会申请到MMZ里的内存，操作MMZ内存需要HI_MPI提供的接口。MMZ内存的使用情况可以通过cat /proc/umap/media-mem命令查看

在查看信息的最下面会有如下的说明：

此处需要重点关注如上模块的remain。由于模型的加载和运行都需要使用MMZ资源，故而当出现mmz相关的malloc异常时，需要第一时间查看mmz的大小是否正常。通常情况下，如果模型无法加载，大部分也是此处的原因。

4.2 CPU和flash的限制

       CPU部分主要需要关注CPU使用率，使用top即可查看，CPU的使用率会影响业务的正常处理速度。当默认情况下，未跑任何算法时，若是CPU占用较大，则需要卸载一些不需要的算法模块，以保证第三方算法正常运行。CPU的占用可使用top命令来查看：

       此处需要重点关注当前内存剩余和，CPU使用率剩余。当内存不足时，则需要优化业务整体逻辑，同时需要排查是否有内存泄漏的可能性。当CPU不足时，则需考虑关闭一些当前无用的进程（如上图的自研算法中的itgt进程），或是优化第三方算法，减少不必要的计算量。

       涉及flash部分，则是需要保证算法依赖的文件不超过当前可用flash大小。需要注意的是：针对不同的型号，可用flash可能有所不同。同时，针对依赖的so库过大，则可用strip来减少库大小，建议使用release版本的算法库。若是依赖模型过多，则需考虑优化当前模型。

4.3 DDR的限制

总的 DDR = OS+MMZ，其中OS代表操作系统内存，MMZ为海思编解码等功能使用的内存。多算法并行运行的因素会受到DDR的制约。限制点主要有两点：其一是DDR的容量，其二是DDR的带宽。

如上所述，DDR的容量包含两部分，其中MMZ可参见本条目4.1查看MMZ容量，关于系统内存，则可通过linux自带命令free –m 查看：

关于DDR带宽，亦指DDR的使用率，通过观察该使用率所占大小，可在一定程度上知道当前是否达到硬件瓶颈。一个比较明显的现象是，若原有的模型推理耗时为30ms的模型，当DDR占用率较高时，当前模型推理耗时推理耗时变高，且模型推理不稳定。正常情况下，ddr的占用应在40%一下，附件中给出了三个平台的ddr测试工具脚本。可直接在相应设备上执行。

参考链接：

1：行车记录仪 – 海思平台的 NNIE 介绍 - 大大通       

2：HiSVP 开发指南

3：HiSVP API 开发指南

4：hisi DDR内存空间的分配 - 灰信网（软件开发博客聚合）

5：https://blog.csdn.net/JCYAO_/article/details/103969670