Be serious 代码问题！！！

[2050airobert]

Hi，
您仔细看，
1 nnadapter出现在kernel目录和 backend目录下 这两个怎么区分的，分别做啥的？ 比如我模型里面的op slice如何传到backend里面的具体硬件的实现的？

  2 这里面确定是一一对应上的吗？ 会不会有缺少的backend op？    

  3 同样的文件 batchXXX.cc 两个地方都有 那个是公共的目录吗？ 难道不会冲突？ 具体是选哪个呢？

  4 比如说在amlogic NPU上跑一个模型，具体模型从开始到op到结束是如何map到backend具体device实现的呢？ 中间是否可以简化？

BR

[paddle-bot-old]

您好，我们已经收到了您的问题，会安排技术人员尽快解答您的问题，请耐心等待。请您再次检查是否提供了清晰的问题描述、复现代码、环境&版本、报错信息等。同时，您也可以通过查看官网文档、常见问题、历史Issue来寻求解答。祝您生活愉快～

Hi! We've received your issue and please be patient to get responded. We will arrange technicians to answer your questions as soon as possible. Please make sure that you have posted enough message to demo your request. You may also check out the API，FAQ and Github Issue to get the answer.Have a nice day!

[hong19860320]

1. 目前存在Paddle op -> NNAdapter operation 和 NNAdapter operation -> NPU op 两层转换的过程，分别在 lite/kernels/nnadapter/converter和 lite/backends/nnadapter/nnadapter/src/driver/xxx/converter/目录下，目前只需要关心 NNAdapter op -> NPU op的转换过程，也就是在lite/backends/nnadapter/nnadapter/src/driver/xxx/converter/目录添加slice.cc 实现 NNAdapter slice operation 到目标硬件的 slice op的转换，然后在lite/backends/nnadapter/nnadapter/src/driver/xxx/converter/all.h 和 lite/kernels/nnadapter/converter/all.h 注册下，具体可查看这个PR [NNAdapter][TIM-VX] Add channel shuffle op #8246 、[NNAdapter][TIM-VX]add batch_norm, scale, conv2d_transpose, nearest_interp, bilinear_interp, matmul, flatten_contiguous_range #7878
2. 部分硬件的 NNAdapter operation -> NPU op转换比较少，决定了它只能支持简单模型，但可以通过在 ite/backends/nnadapter/nnadapter/src/driver/xxx/converter/ 扩充更多的converter来支持更多的模型，每个硬件支持的paddle算子可以在 lite/kernels/nnadapter/converter/all.h 查看
3. 不会冲突，你可以理解左边是 NNAdapter operation的 infer shape & type过程，而右边是具体每个硬件的 NNAdapter operation -> NPU op的实际转换过程
4. 一般是这样的过程： paddle model -> NNAdapter graph -> Amlogic graph -> Amlogic binary model， NNAdapter 作为一个中间适配层，将Paddle 独有或者比较特殊的算子，转换为硬件相对友好的 NNAdapter operation，这样就不需要对 lite 框架有深入的理解，就可以快速完成硬件适配。

顺便提一下，建议使用 TIM-VX 方式支持 Amlogic Soc NPU

[2050airobert]

感谢您详细的回答。
针对问题2
(1) NNAdapter operation -> NPU op 比较少，这是模型不被支持的一种原因。但是是不是还有可能这个模型的op比较少见，甚至连NPU op都不足够实现或者完成这个op需要做的工作。
(2) 更极端的，甚至NPU上想了许多方法就是没办法实现这个op，这种情况也是有可能的吗？

[hong19860320]

感谢您详细的回答。 针对问题2 (1) NNAdapter operation -> NPU op 比较少，这是模型不被支持的一种原因。但是是不是还有可能这个模型的op比较少见，甚至连NPU op都不足够实现或者完成这个op需要做的工作。 (2) 更极端的，甚至NPU上想了许多方法就是没办法实现这个op，这种情况也是有可能的吗？

1）这类converter比较少的原因有多个：一个是这个硬件支持的算子确实较少（受限于硬件厂商的 SDK），另一种情况是目前暂时没有人力增加这些converter，后者占主要的原因，一般是以业务或者外部生态的需要而驱动的；一般来说 SoC NPU 主打 CV 场景，都是一些基础的算子，但确实有诸如deformable_conv这类只有少数硬件厂商支持的算子，如果厂商不支持，就只能走类似TRT plugin方式，但 SoC NPU 一般很少会提供自定义算子的接口；
2）有的，例如yolo_box、box_coder、nms，一般都建议异构到ARM CPU，但如果硬件厂商提供了自定义算子的接口，那还好办。