8550snpe/qnn环境验证失败，6490qnn推理报错

[bhnuihbui]

• snpe/qnnSDK2.26.2
• Host：windows

Qnn模型转换：

Fp16：

python qnn-onnx-converter -i "C:\Users\user\Desktop\XXX-onnxmodel\ocr_recognise_model\qnn_repsvtr\repsvtr_rtc_48_320_250225.onnx" -o "C:\Users\user\Desktop\XXX-onnxmodel\ocr_recognise_model\qnn_repsvtr\repsvtr_rtc_48_320_fp16.cpp" --float_bitwidth 16 --float_bias_bitwidth 16

Int8量化：

python qnn-onnx-converter -i "C:\Users\user\Desktop\XXX-onnxmodel\ocr_recognise_model\qnn_repsvtr\repsvtr_rtc_48_320_250225.onnx" -o "C:\Users\user\Desktop\XXX-onnxmodel\ocr_recognise_model\qnn_repsvtr\repsvtr_rtc_48_320_ptq.cpp" --input_list "C:\Users\user\Desktop\XXX-onnxmodel\recog-raws\raw_list.txt" --param_quantizer_calibration sqnr --act_quantizer_calibration sqnr

静态模型库编译：

添加host的qnn库环境变量：

set QNN_SDK_ROOT=C:\Qualcomm\AIStack\QAIRT\2.25.0.240728、

进行编译

python qnn-model-lib-generator -c C:\Users\user\Desktop\XXX-onnxmodel\ocr_recognise_model\qnn_repsvtr\repsvtr_rtc_48_320_ptq.cpp -b C:\Users\user\Desktop\XXX-onnxmodel\ocr_recognise_model\qnn_repsvtr\repsvtr_rtc_48_320_ptq.bin -t windows-x86_64 -o C:\Users\user\Desktop\XXX-onnxmodel\ocr_recognise_model\qnn_repsvtr

进行htp二进制文件生成：

设置为主机windows的htp backend运行正常：

qnn-context-binary-generator.exe --model "C:\Users\user\Desktop\XXX-onnxmodel\ocr_recognise_model\qnn_repsvtr\x64\repsvtr_rtc_48_320_ptq.dll" --backend C:\Qualcomm\AIStack\QAIRT\2.25.0.240728\lib\x86_64-windows-msvc\QnnHtp.dll --binary_file repsvtr_rtc_48_320_ptq -o C:\Users\user\Desktop\XXX-onnxmodel\ocr_recognise_model\qnn_repsvtr\x64

• 设备：QCS8550

将对应平台的lib库及hexagon-v73的相关库放入到设备中同路径下

设备中的qnn库为下图：

设备中的snpe库为下图：

设备端进行平台验证：

已设置环境变量export LD_LIBRARY_PATH=/usr/lib   export PATH=$LD_LIBRARY_PATH:$PATH    export ADSP_LIBRARY_PATH=/usr/lib

qnn-platform-validator --backend dsp --coreVersion --libVersion –testBackend –debug 报错平台验证失败

由于QNN和SNPE的sdk库为同一版，顺带也尝试了snpe的平台验证：

snpe-platform-validator --runtime dsp --coreVersion --libVersion --testRuntime --debug

随后尝试进行qnn-net-run：

qnn-net-run --retrieve_context /data/repsvtr_rtc_48_320_ptq.bin --backend /usr/lib/libQnnHtp.so --output_dir /data/qnn_XXX_result_htp --input_list /data/TEST_RESIZE/raw_list.txt

也顺带尝试了snpe-net-run：

snpe-net-run --container /data/ocr_recognise_model_quant.dlc --input_list /data/TEST_RESIZE/raw_list.txt --runtime_order dsp,cpu --output_dir /data/snpe_XXX_dsp_result --debug

 

 

• 设备：QCS6490

由于此设备已经验证过环境因此直接尝试运行

Qnn-net-run：

qnn-net-run --retrieve_context /data/repsvtr_rtc_48_320_ptq.bin --backend /usr/lib/libQnnHtp.so --output_dir /data/qnn_XXX_result_htp --input_list /data/TEST_RESIZE/raw_list.txt

经错误提示，感觉可能是vtcm需要限制，因此编写了json文件

但是经再次测试，依然提示该错误。目前不清楚是哪的问题。

[bhnuihbui]

@weixin_38498942 感谢答复！ 但不管是根据错误提示尝试export ADSP_LIBRARY_PATH=/usr/lib/lib*skel.so，还是export ADSP_LIBRARY_PATH=/usr/lib/lib*，其仍然是报一模一样的错。

[weixin_38498942]

可以试试：export ADSP_LIBRARY_PATH=/usr/lib/linSnpe
让ADSP_LIBRARY_PATH直接指向libSnpeHtp*Skel.so

[bhnuihbui]

@Ricky技术随想 感谢答复！ 尝试使用上述命令后仍然报同样的错。 8550设备的系统信息如下： Linux kalama 5.15.148-qki-consolidate-android13-8-g6f59eac17921-dirty #1 SMP PREEMPT Wed Oct 30 01:55:15 UTC 2024 aarch64 GNU/Linux 我使用的是aarch64-oe-linux-gcc11.2的库。 关于问题2，对生成bin和qnn-net-run时的config文件修改vtcm为2后，其报错依旧。但发现了个奇怪现象，我用6490设备的工具链进行该模型编译成so后，其放到6490设备编译成bin并qnn-net-run却可以正常运行，并且全程没设置相关config。

[Ricky技术随想]

你好！关于这里的问题

1. 8550的错误是在于 高通的HTP 有未签名和已签名的保护域（Protection Domains，简称 PD），它们控制对 NPU 上不同服务的访问。从日志的错误上看。8550上跑的是什么系统？
   试试运行下面的命令再跑qnn-net-run试试？
   adb root
   adb remount
2. QCS6490的问题，日志看起来确实是VTCM的限制引起的错误，但是6490的VCTM只有2M ，您的配置是4M，所有修改json文件
   成2m的vtcm

[bhnuihbui]

@Ricky技术随想 抱歉，第二个问题已解决了，是配置文件中graph_names命名前后不一致导致的，所以配置文件之前并没有生效。

[bhnuihbui]

@Ricky技术随想 嗯，好的。我尝试去反馈下。另外，关于vtcm的问题，由于公司需求，需要在windows 主机上进行模型的so编译和bin生成，在设备端上进行推理，因此请问还有其他操作可能造成此问题的相关可疑点吗？

[Ricky技术随想]

@bhnuihbui 你好8550的错误看起来是设备没有签名，需要使用Qualcomm(R) Hexagon™ SDK 工具中的elfsinger 命令工具对设备签名，能否把问题反馈给到8550的模组厂商，让他们帮忙签名？ 因为Qualcomm(R) Hexagon™ SDK 在https://qpm.qualcomm.com/#/main/tools/ 可以找到，但目前是有下载限制