Toybrick

标题: RKNN-API文档与示例代码矛盾 [打印本页]

作者: bob286 时间: 2021-11-8 14:48
标题: RKNN-API文档与示例代码矛盾
版本：RKNN_API_for_RK356X_v1.1.0_20210820
文档第10页，流程图中示意通过 input tensor fd / physical address 来更新每帧，进行逐帧推理；
但位于同一压缩包内的rknn_create_mem_demo.cpp代码，却是通过input_mems[0]->virt_addr来传入帧数据的。

两种说法互相矛盾，请帮忙确认哪一种是正确的？

作者: jefferyzhang 时间: 2021-11-8 17:31
都可以用，fd 、物理地址、虚拟地址 356x的 rknn都能吃。

作者: bob286 时间: 2021-11-9 10:20

jefferyzhang 发表于 2021-11-8 17:31
都可以用，fd 、物理地址、虚拟地址 356x的 rknn都能吃。

那 input_mems[0]->virt_addr 和 output_mems[0]->virt_addr 这两个地址记录下来，每次通过这两个指针更新输入、获取输出，是否可行？（具体的文档和demo都没有提供如何更新帧的范例）

作者: jefferyzhang 时间: 2021-11-9 11:27

bob286 发表于 2021-11-9 10:20
那 input_mems[0]->virt_addr 和 output_mems[0]->virt_addr 这两个地址记录下来，每次通过这两个指针更 ...

怎么用是看你代码怎么写的。
虚拟地址和fd需要访问mmu，物理地址直接硬件可用，虚拟地址有cache，cpu读写较快，fd一般直接可以取DMA buffer使用。具体怎么用不是取决于我们，而是取决你自己的代码。

作者: bob286 时间: 2021-11-9 15:02

jefferyzhang 发表于 2021-11-9 11:27
怎么用是看你代码怎么写的。
虚拟地址和fd需要访问mmu，物理地址直接硬件可用，虚拟地址有cache，cpu读写 ...

现在是遇到了一个数值错误的问题，平时都是对的，但偶尔出现一次，就会数值错误。具体的使用方法就是每次通过 memcpy来写入 input_mems[0]->virt_addr ，然后执行rknn_run，之后通过memcpy 取出output_mems[0]->virt_addr 中的特征。
99.9%的情况下，得到的数值没有问题，但偶有一次，就得到错误的数值，且数值有一定规律（以8个为一组，一组内的数值近似）。

正确的特征（前64维）如下：

0.703769,  0.695992,  0.303281,  0.295505,  0.00388822,  0.244958,  0.532687,  0.684327,  0.37327,  0.295505,  0.00388822,  0.186635,  0.454922,  0.664886,  0.478252,  0.295505,  0.00388822,  0.17497,  0.412152,  0.664886,  0.552128,  0.295505,  0.00388822,  0.151641,  0.509357,  0.695992,  0.637669,  0.303281,  0.00388822,  0.151641,  0.606563,  0.703769,  0.703769,  0.303281,  0.00388822,  0.139976,  0.532687,  0.703769,  0.684327,  0.303281,  0.00388822,  0.124423,  0.544351,  0.695992,  0.664886,  0.303281,  0.00388822,  0.116647,  0.552128,  0.684327,  0.664886,  0.303281,  0.00388822,  0.101094,  0.563793,  0.676551,  0.664886,  0.295505,  0.00388822,  0.0933174,  0.563793,  0.676551,  0.645445,  0.295505
复制代码

错误的特征（前64维）如下：

0.800974,  0.793198,  0.828192,  0.839856,  0.83208,  0.820415,  0.83208,  0.820415,  0.812639,  0.808751,  0.793198,  0.808751,  0.800974,  0.820415,  0.828192,  0.828192,  0.843745,  0.820415,  0.812639,  0.800974,  0.793198,  0.793198,  0.800974,  0.800974,  0.820415,  0.820415,  0.808751,  0.769868,  0.754315,  0.769868,  0.808751,  0.812639,  0.777645,  0.808751,  0.820415,  0.808751,  0.785421,  0.785421,  0.808751,  0.87485,  0.762092,  0.703769,  0.730986,  0.762092,  0.72321,  0.676551,  0.703769,  0.703769,  0.322723,  0.322723,  0.322723,  0.322723,  0.322723,  0.322723,  0.322723,  0.322723,  0.828192,  0.812639,  0.785421,  0.730986,  0.703769,  0.695992,  0.703769,  0.703769
复制代码

请帮忙确认一下我们的使用方法是否确实有误，如果有错误，请指出来。或提出一些可能导致此问题的原因。（因redmine提了之后超过一周没人回复，只好在此提问了，谢谢！）

作者: jefferyzhang 时间: 2021-11-9 15:08

bob286 发表于 2021-11-9 15:02
现在是遇到了一个数值错误的问题，平时都是对的，但偶尔出现一次，就会数值错误。具体的使用方法就是每次 ...

这个你可以自己先定位下，取出前memset 0下，排除是上一次的结果。
如果确定是本次算错的，DUMP下每一层数据，看下哪里开始算错的，硬件计算理论上不会出现计算结果不一致，除非你喂进去的参数就已经有偏差。

作者: bob286 时间: 2021-11-9 15:15

jefferyzhang 发表于 2021-11-9 15:08
这个你可以自己先定位下，取出前memset 0下，排除是上一次的结果。
如果确定是本次算错的，DUMP下每一层 ...

在rknn_run前后分别存下来两个地址的内容，确实发生了，在不同的时空，输入一致，但输出不一致的状况。只是这种情况复现非常困难，我们也只复现了十几次，琢磨不透规律。而且rknn2的c-api没有提供dump出每一层的接口，所以排查比较困难。

作者: bob286 时间: 2021-11-9 15:18

jefferyzhang 发表于 2021-11-9 15:08
这个你可以自己先定位下，取出前memset 0下，排除是上一次的结果。
如果确定是本次算错的，DUMP下每一层 ...

您这所说的”取出前memset 0下“，指的是对谁memset？

欢迎光临 Toybrick (https://t.rock-chips.com/)