i.MX 8M Plus EVK では、空間カーネル次元 (H または W) のいずれかが 16 以上である Conv2D 演算で、VX デリゲート (libvx_delegate.so) の下で誤った出力が生成されます。モデルはロードされ、Conv2D は vsi_nn_kernel_selector によって OPENVX カーネルにバインドされ、error_during_init/prepare/invoke はすべて 0 であり、推論レイテンシは正常ですが、int8 出力はさまざまな入力に対してすべての位置で単一の値 (int8 = 127) に飽和します。
空間軸のどちらにおいても、K=15とK=16の境界は明確である。これは、文書化されたストライド > 15 の制限のしきい値と一致します ( https://community.nxp.com/t5/i-MX-Processors/Conv2D-not-working-with-stride-16-for-NPU-Kernel-crashe... )。
2つの質問があります。
このカーネル次元が16以上という制限は既知のものですか?もしそうであれば、i.MX機械学習ユーザーガイド(UG10166)のConv2D制約のセクションに追加していただけますか?
vsi_nn_op_conv2d::op_check(またはVXデリゲートのパーティションロジック)は、グラフコンパイル時にこのケースを拒否し、演算をCPUにフォールバックさせるべきでしょうか?現在の「受け入れ、実行、定数 int8=127 を返す、診断なし」という動作は安全ではありません。カーネルが大きいデプロイ済みモデルは、正常にロードされ実行されるように見えます。
コンポーネント値
| ボード | i.MX 8M Plus EVK |
| BSP | NXP i.MX リリースディストリビューション 6.18-whinlatter (VERSION_ID=6.18-whinlatter) |
| カーネル | Linux 6.18.2-1.0.0-gf49f45233f7bSMPプリエンプト(aarch64) |
| libvx_delegate.so のMD5 | 2f88ec0871d18298bfa357ddaaea4d6d |
| libGAL.so md5 | af4806f617b23363b3be69c4dad2dc05 |
| libOpenVX.so{,.1,.1.3.0}MD5 | 92f85c32746d4d0b38800e21503d13d0(3つとも同一) |
| imx-gpu-viv パッケージ | 1:6.4.11.p4.4-aarch64-r0 |
| tim-vxパッケージ | 1.2.2-r0 |
| OVxlib(ランタイム報告) | OVXLIB_VERSION==1.2.14 |
| TFLiteランタイム | TFLite 2.19.0 (/usr/bin/tensorflow-lite-2.19.0/examples/benchmark_model) |
添付の conv_1x17_broken.tflite (2,136 バイト) は、単一の Conv2D アーティファクトです。カーネル (1, 17)、入力 1×1×1000×5 int8、出力 1×1×1000×8 int8、チャネルごとの int8 重み量子化、パディング=SAME、ストライド=(1,1)、融合活性化なし。
# On the i.MX 8M Plus board: python3 reproduce.py conv_1x17_broken.tflite # exits 1: BROKEN, saturated to int8=127 python3 reproduce.py conv_1x15_torch_control.tflite # exits 0: OK (K<16, same pipeline)
reproduce.py(添付ファイル、tflite_runtimeとnumpyのみに依存)は、6つのシード付きランダムなint8入力をプレーンおよびVX委任インタープリタに通し、平均|Δ|、最大|Δ|、およびVXパスからの一意のint8出力値のカウントを報告します。
単一Conv2Dユニットテストモデル、INT8 PTQ。同じ int8 入力バイトにおける、ボード VX とボード CPU の平均 |Δ|。uniq_VX = 6 つの入力 (256 個中) における一意の int8 出力値。
カーネル(H, W)平均|Δ|uniq_VX結果
| (1、11) | 0.03 | 256 | OK |
| (1、15) | 0.02 | 256 | OK |
| (1、16) | 134.9 | 1 | 破損しています(定数 int8=127) |
| (1、17) | 136.9 | 1 | 破損しています(定数 int8=127) |
| (1、23) | 130.5 | 1 | 破損しています(定数 int8=127) |
| (15、1) | 0.11 | 256 | OK |
| (17、1) | 136.9 | 1 | 破損しています(定数 int8=127) |
| (23、1) | 129.3 | 1 | 破損しています(定数 int8=127) |
| (3, 3)、(5, 5)、(7, 7) | < 0.2 | 256 | OK |
| (15、15)(エリア225) | 0.41 | 256 | OK |
| (3、23) | 123.4 | 1 | 破損しています(定数 int8=127) |
| (5、15) | 0.24 | 256 | OK |
しきい値は H と W にそれぞれ独立して適用されます。すべての不具合ケースにおいて、VX 出力はすべての位置で int8 = 127 に飽和します。正の int8 極値への飽和 (output_zp または 0 ではなく) は、最終クランプ前の乗算器シフトオーバーフロー、または MAC 結果の代わりに固定値が出力タイルに書き込まれていることを示唆しています。この問題はカーネル領域とは関係ないようです(例えば、15x15は正常に動作します)。
このしきい値は必要条件ではあるが十分条件ではない。K ≥ 16 の場合、一部の int8 の重み値のパターンはバグを引き起こすが、他のパターンは引き起こさない。バイトレベルの分離実験(破損したアーティファクトと破損していないアーティファクトの間に個々のTFLiteテンソルフィールドを移植する)を行い、値パターンのトリガーを特定のテンソルフィールドに絞り込みました。もしお役に立てるようでしたら、分離結果と使用したツールを喜んで共有いたします。
INFO: Vx delegate: error_during_init set to 0. INFO: Vx delegate: error_during_prepare set to 0. INFO: Vx delegate: error_during_invoke set to 0. I [vsi_nn_CreateGraph:1327] OVXLIB_VERSION==1.2.14 D [setup_node:535] Setup node id[3] uid[30000] op[DATACONVERT] D [setup_node:535] Setup node id[0] uid[1] op[PERMUTE] D [setup_node:535] Setup node id[1] uid[2] op[CONV2D] D [setup_node:535] Setup node id[2] uid[3] op[PERMUTE] D [setup_node:535] Setup node id[4] uid[30001] op[DATACONVERT] D [vsi_nn_kernel_selector:1286] Instance OPENVX node with kernel "conv2d"
完全なログファイルは vsi_nn_log_level_5_conv_1x17.txt として添付されています。
bug_report_artifacts.tar.gz としてバンドルされています。
ご要望に応じて、追加のアーティファクトを提供できます。バイトレベルの分離ツール、デルタ解析用の構造的に同一の動作アーティファクト(1、17)、完全な十分条件グラフト結果。
こんにちは、 @themis_stewartさん
情報ありがとうございます。いただいた2つの質問について、社内チームに確認中です。
よろしくお願いします、
志明
こんにちは、 @themis_stewartさん
カーネルサイズが16より大きい場合に演算をCPUにフォールバックさせるには、 L6.18.2に基づいた以下のパッチをお試しください。
よろしくお願いします、
志明
迅速な対応をありがとうございます。ガードパッチを適用・テストした結果、こちらの問題は解決したと確認しています。
op_map.ccの変更を含むlf-6.18.2_1.0.0のデリゲートソースからパッチ付きlibvx_delegate.soを作成し、元のレポートの最小限のリプロダクターと比較して i.MX 8M Plus EVKで検証しました。パッチ適用後:
CPUフォールバックパスは実際には良好に機能していますが、フォールバックはNPU上で完全に動作するモデルよりも自然に遅いです。回帰テストのカバレッジ向上に役立つようでしたら、詳細な前後比較ベンチマークを個別にご提供いたします。
改めてありがとうございました。大変感謝しています。