Page 1 of 1
关于官方给的luckfox_pico_rtsp_yolov5 bug
Posted: 2024-04-12 8:45
by W凯先森~
关于release_yolov5_model(rknn_app_context_t *app_ctx)中不能提前使用 rknn_destroy(app_ctx->rknn_ctx);不然后后面的 rknn_destroy_mem(app_ctx->rknn_ctx, app_ctx->input_mems)这个就矛盾了，而且不能使用 free(app_ctx->input_mems);，我在测试中重复初始化模型和释放模型发现的问题
Re: 关于官方给的luckfox_pico_rtsp_yolov5 bug
Posted: 2024-04-12 8:48
by Crocodile
W凯先森~ wrote: ↑2024-04-12 8:45
关于release_yolov5_model(rknn_app_context_t *app_ctx)中不能提前使用 rknn_destroy(app_ctx->rknn_ctx);不然后后面的 rknn_destroy_mem(app_ctx->rknn_ctx, app_ctx->input_mems
)这个就矛盾了，而且不能使用 free(app_ctx->input_mems);，我在测试中重复初始化模型和释放模型发现的问题
您好，非常感谢您的反馈，我们会在问题确认后更新相关源码资料
Re: 关于官方给的luckfox_pico_rtsp_yolov5 bug
Posted: 2024-04-12 10:50
by Crocodile
Crocodile wrote: ↑2024-04-12 8:48
W凯先森~ wrote: ↑2024-04-12 8:45
关于release_yolov5_model(rknn_app_context_t *app_ctx)中不能提前使用 rknn_destroy(app_ctx->rknn_ctx);不然后后面的 rknn_destroy_mem(app_ctx->rknn_ctx, app_ctx->input_mems
)这个就矛盾了，而且不能使用 free(app_ctx->input_mems);，我在测试中重复初始化模型和释放模型发现的问题
您好，非常感谢您的反馈，我们会在问题确认后更新相关源码资料
您好，经过测试目前无法确定重复初始化模型和释放模型的错误是由于rknn_destory 和 rknn_destroy_release 执行顺序引起的，根据RKNN相关的文档 04_Rockchip_RKNPU_API_Reference_RKNNRT_V1.6.0_CN.pdf 提到相关的描述
rknn_destory 销毁的是 rknn_init 申请的 rknn_context 对象， rknn_destory_mem 销毁的是 rknn_create_mem 申请的输入输出tensor对象，两者在结构上是串行的关系（input_tensor -> rknn_context ->output_tensor） 资源的释放理论上来将并不会冲突。
关于luckfox_pico_rtsp_yolov5 一开始的设计思路是类似rkipc模型在 luckfox-pico 启动阶段就运行，使用另外的指令可以结束进程并释放对应资源，目前的代码是没有留出资源释放的出口的（程序的资源释放内容放在while（1）循环之后，使用ctrl-c从while中结束了进程但是没有进入资源释放的部分），请您确定在测试时是否执行了相关的资源释放函数。 我对例程的不完善深感抱歉，目前是打算使用信号量来实现while循环跳出，我会在后续上传新的代码到github上。
此外由于无法确认您的测试环境，所以无法确认问题出现的具体原因。欢迎您提出您的测试结果，这对我们完善例程很有帮助。
Re: 关于官方给的luckfox_pico_rtsp_yolov5 bug
Posted: 2024-04-14 12:15
by W凯先森~
Crocodile wrote: ↑2024-04-12 10:50
Crocodile wrote: ↑2024-04-12 8:48
W凯先森~ wrote: ↑2024-04-12 8:45
关于release_yolov5_model(rknn_app_context_t *app_ctx)中不能提前使用 rknn_destroy(app_ctx->rknn_ctx);不然后后面的 rknn_destroy_mem(app_ctx->rknn_ctx, app_ctx->input_mems
)这个就矛盾了，而且不能使用 free(app_ctx->input_mems);，我在测试中重复初始化模型和释放模型发现的问题
您好，非常感谢您的反馈，我们会在问题确认后更新相关源码资料
您好，经过测试目前无法确定重复初始化模型和释放模型的错误是由于rknn_destory 和 rknn_destroy_release 执行顺序引起的，根据RKNN相关的文档 04_Rockchip_RKNPU_API_Reference_RKNNRT_V1.6.0_CN.pdf 提到相关的描述
rknn_destory 销毁的是 rknn_init 申请的 rknn_context 对象， rknn_destory_mem 销毁的是 rknn_create_mem 申请的输入输出tensor对象，两者在结构上是串行的关系（input_tensor -> rknn_context ->output_tensor） 资源的释放理论上来将并不会冲突。 rknn_destory_mem.jpg
rknn_destory.jpg
关于luckfox_pico_rtsp_yolov5 一开始的设计思路是类似rkipc模型在 luckfox-pico 启动阶段就运行，使用另外的指令可以结束进程并释放对应资源，目前的代码是没有留出资源释放的出口的（程序的资源释放内容放在while（1）循环之后，使用ctrl-c从while中结束了进程但是没有进入资源释放的部分），请您确定在测试时是否执行了相关的资源释放函数。 我对例程的不完善深感抱歉，目前是打算使用信号量来实现while循环跳出，我会在后续上传新的代码到github上。
此外由于无法确认您的测试环境，所以无法确认问题出现的具体原因。欢迎您提出您的测试结果，这对我们完善例程很有帮助。
首先是感谢您的回复，您可以看上面的参数如果开始就用rknn_destory来销毁rknn_context 对象，这样这个rknn_context 对象不存在了，这个上下文就不存在了，但是你后面使用rknn_create_mem 是要根据rknn_context 对象来进行销毁tensor对象，我这边是重复进行将模型按照您的提供的初始方法进行初始化以后在进行释放，后面就会发现实际tensor对象没有进行释放，导致后面因为内存不够进而初始化失败。举个例子，这个rknn_context 就相当于id，通过这个我们知道是当前这个模型输入，还有推理等等，相对应的释放也是，那通过这个id，进行释放与其对应的绑定的模型进行释放，包括tensor对象，如果这个开始id进行释放了，就找不到对应绑定的模型进行释放了，这个是我的理解。你可以试试把初始化模型和释放放在while里，如果正常资源是释放成功的，那就不会存在程序报错没空间了，官方的例子也是最后进行使用rknn_destory来销毁rknn_context 对象
Re: 关于官方给的luckfox_pico_rtsp_yolov5 bug
Posted: 2024-04-15 3:48
by Crocodile
W凯先森~ wrote: ↑2024-04-14 12:15
Crocodile wrote: ↑2024-04-12 10:50
Crocodile wrote: ↑2024-04-12 8:48
您好，非常感谢您的反馈，我们会在问题确认后更新相关源码资料
您好，经过测试目前无法确定重复初始化模型和释放模型的错误是由于rknn_destory 和 rknn_destroy_release 执行顺序引起的，根据RKNN相关的文档 04_Rockchip_RKNPU_API_Reference_RKNNRT_V1.6.0_CN.pdf 提到相关的描述
rknn_destory 销毁的是 rknn_init 申请的 rknn_context 对象， rknn_destory_mem 销毁的是 rknn_create_mem 申请的输入输出tensor对象，两者在结构上是串行的关系（input_tensor -> rknn_context ->output_tensor） 资源的释放理论上来将并不会冲突。 rknn_destory_mem.jpg
rknn_destory.jpg
关于luckfox_pico_rtsp_yolov5 一开始的设计思路是类似rkipc模型在 luckfox-pico 启动阶段就运行，使用另外的指令可以结束进程并释放对应资源，目前的代码是没有留出资源释放的出口的（程序的资源释放内容放在while（1）循环之后，使用ctrl-c从while中结束了进程但是没有进入资源释放的部分），请您确定在测试时是否执行了相关的资源释放函数。 我对例程的不完善深感抱歉，目前是打算使用信号量来实现while循环跳出，我会在后续上传新的代码到github上。
此外由于无法确认您的测试环境，所以无法确认问题出现的具体原因。欢迎您提出您的测试结果，这对我们完善例程很有帮助。
首先是感谢您的回复，您可以看上面的参数如果开始就用rknn_destory来销毁rknn_context 对象，这样这个rknn_context 对象不存在了，这个上下文就不存在了，但是你后面使用rknn_create_mem 是要根据rknn_context 对象来进行销毁tensor对象，我这边是重复进行将模型按照您的提供的初始方法进行初始化以后在进行释放，后面就会发现实际tensor对象没有进行释放，导致后面因为内存不够进而初始化失败。举个例子，这个rknn_context 就相当于id，通过这个我们知道是当前这个模型输入，还有推理等等，相对应的释放也是，那通过这个id，进行释放与其对应的绑定的模型进行释放，包括tensor对象，如果这个开始id进行释放了，就找不到对应绑定的模型进行释放了，这个是我的理解。你可以试试把初始化模型和释放放在while里，如果正常资源是释放成功的，那就不会存在程序报错没空间了，官方的例子也是最后进行使用rknn_destory来销毁rknn_context 对象
您好，
我们测试过注释掉 while 循环并在后台监视内存使用情况，多次运行 demo 内存在程序运行后都能被成功释放。但是如果将初始化和释放放到while循环中不断运行，在运行到一定次数后就会出现内存无法正确分配的情况，在程序停止后被占用的内存才会被重新释放。由于RKNN的源码并没有公开，我们也无从考证在内存在释放期间和程序结束后发生了什么，实验现象可以肯定您的猜测是一种可靠的说法，但是在rknn的使用上input_tensor_memory
和 output_tensor_memory 主要使用的是内存分配的虚拟地址都有暴露出来，存在根据 context 释放或根据地址释放，所以在释放 tensor_memory 后还是引入了 free 对相应内存进行处理。
关于官方例子的使用方式，在开发阶段时rknn_model_zoo的最新版本是1.6.0，我们在相关资料上也是声明以1.6.0为标准，官方案例使用的释放方式是先释放rknn_context使用 free 去释放虚拟内存。最新的版本2.0.0中已经对此做出了修改，但是最新的用法在使用上可能会出现Aborted (core dumped)的问题，可能与链接库的更新有关，问题目前还没有排除出来。在没有rknn源码的情况下我们还是以 rknn_model_zoo 的为主，我们会在后续更新github上的释放源码。
感谢您对我们例程优化问题上的关注和建议。