在rk3399pro上使用rknn的接口rknn_init内部概率性崩溃！！！

iamher0 发表于 2020-6-8 17:04
正常情况，我们不会不停的销毁，我们是在线上设备发现的问题，4个进程，4路视频，每个进程跑大概3个模型 ...

异构运算，你的快速能保证和NPU同步么，不能的话拼命销毁重建模型，考虑过NPU那边会不会爆掉么？

jefferyzhang 发表于 2020-6-8 17:07
异构运算，你的快速能保证和NPU同步么，不能的话拼命销毁重建模型，考虑过NPU那边会不会爆掉么？ ...

我觉得这是你们应该考虑的吧，从驱动或SDK里面加上保证稳定性的逻辑

为什么复现代码都提供了，还是一堆的问题，而不去复现呢？
而且我们不频繁操作也同样会出现问题， 我们是多进程使用，NPU的同步不应该让应用层去考虑

iamher0 发表于 2020-6-8 17:14
我觉得这是你们应该考虑的吧，从驱动或SDK里面加上保证稳定性的逻辑

为什么复现代码都提供了，还是一堆的 ...

因为我们不是NPU的人啊，NPU那边就是说了不能频繁建立和销毁模型，你要我怎么弄？
如果你有FAE渠道，建议你通过FAE给NPU部门提问题，社区这里在公司问题处理优先级是最低的。

好的，非常感谢你的耐心答复，也希望你能把我们的疑问反馈给NPU的相关人员

因为在正常的程序重启过程中：3个模型销毁重建就是6次操作，同时另外3个进程的9个模型也在推理
中间可能出现了同步的问题

jefferyzhang 发表于 2020-6-8 17:25
因为我们不是NPU的人啊，NPU那边就是说了不能频繁建立和销毁模型，你要我怎么弄？
如果你有FAE渠道，建议 ...

你好，我这边再给你们提供一个简单完整的测试用例，代码只有几十行，只需要拷贝到系统里，执行make install编译，
然后进入test/bin目录执行./start.sh脚本就可以运行起来，可以拷贝test目录，多进程测试。
现在测试发现的问题是rknn_api和npu服务进程都存在崩溃现象，而且是必现，不管是参数错误、内存不够还是
其它问题，都不应该崩溃，最多是返回错误，崩溃肯定是程序问题，希望尽快解决！！！

panziwen86 发表于 2020-6-8 21:35
你好，我这边再给你们提供一个简单完整的测试用例，代码只有几十行，只需要拷贝到系统里，执行make insta ...

1. 本社区是工程师交流的地方，不是提交bug的地方，NPU部门同事只会偶尔会上来看看问题。
2. 咨询过NPU的同事，你这么用就是有问题的，不允许频繁的init和destroy，NPU来不及释放肯定会出错
3. 如果有疑问，请向FAE咨询

jefferyzhang 发表于 2020-6-8 22:38
1. 本社区是工程师交流的地方，不是提交bug的地方，NPU部门同事只会偶尔会上来看看问题。
2. 咨询过NPU的 ...

1、如果不是提交Bug的地方，我们这些开发者来这里还有什么价值？我们买的是板子，怎么着FAE？
2、前面的帖子已经说明了，这个测试是为了快速复现问题，真正的问题是当实例重启的时候根本没法重启起来，因为我们的实例里有多个模型，当重启的时候就会有多次init和destroy，你们应该在接口层面提供阻塞或者错误代码，否则我们也不知道何时可以正常使用

jefferyzhang 发表于 2020-6-8 22:38
1. 本社区是工程师交流的地方，不是提交bug的地方，NPU部门同事只会偶尔会上来看看问题。
2. 咨询过NPU的 ...

1、这只是我的测试代码，为了更快的复现问题，以便解决，我们在具体项目中并没有这么频繁的init和destroy，但同样也出现此问题；
2、你说不允许频繁的init和destroy，sdk的文档中没这么写吧，那多少频率算频繁呢？NPU来不及释放可以返回错误码，不一定要崩溃吧，感觉这都说不过去呀；
3、我们没有要求你们现在就立马解决问题，只是希望你们向你们的FAE反馈一下问题，而你直接就说这是我们使用上的问题，要我自己联系FAE，但我也没有联系方式呀，更没有讨论的平台啊。

我怎么感觉，他们很抵触问题，不正面回答，而且态度上就是程序员易犯的思维模式“有问题肯定是别人的问题”

iamher0 发表于 2020-6-9 10:03
我怎么感觉，他们很抵触问题，不正面回答，而且态度上就是程序员易犯的思维模式“有问题肯定是别人的问题” ...

没办法，我们也只是普通工程师，偶尔上来交流问题而已，你们问我们的问题，我们报给NPU部门，他们就这么回得。
但是这个你也必须理解，他们手上非常多立项客户，不会去在意我们论坛客户的。。。