2372640_ja-JP

キャンセル
次の結果を表示 
表示  限定  | 次の代わりに検索 
もしかして: 

2372640_ja-JP

2372640_ja-JP

i.MX 8M Plus VXデリゲート上のConv2Dは、空間カーネル次元が16以上の場合に誤った出力を生成します。

概要

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つの質問があります。

  1. このカーネル次元が16以上という制限は既知のものですか?もしそうであれば、i.MX機械学習ユーザーガイド(UG10166)のConv2D制約のセクションに追加していただけますか?

  2. vsi_nn_op_conv2d::op_check(またはVXデリゲートのパーティションロジック)は、グラフコンパイル時にこのケースを拒否し、演算をCPUにフォールバックさせるべきでしょうか?現在の「受け入れ、実行、定数 int8=127 を返す、診断なし」という動作は安全ではありません。カーネルが大きいデプロイ済みモデルは、正常にロードされ実行されるように見えます。


環境

コンポーネント値

ボードi.MX 8M Plus EVK
BSPNXP i.MX リリースディストリビューション 6.18-whinlatter (VERSION_ID=6.18-whinlatter)
カーネルLinux 6.18.2-1.0.0-gf49f45233f7bSMPプリエンプト(aarch64)
libvx_delegate.so のMD52f88ec0871d18298bfa357ddaaea4d6d
libGAL.so md5af4806f617b23363b3be69c4dad2dc05
libOpenVX.so{,.1,.1.3.0}MD592f85c32746d4d0b38800e21503d13d0(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.03256OK
(1、15)0.02256OK
(1、16)134.91破損しています(定数 int8=127)
(1、17)136.91破損しています(定数 int8=127)
(1、23)130.51破損しています(定数 int8=127)
(15、1)0.11256OK
(17、1)136.91破損しています(定数 int8=127)
(23、1)129.31破損しています(定数 int8=127)
(3, 3)、(5, 5)、(7, 7)< 0.2256OK
(15、15)(エリア225)0.41256OK
(3、23)123.41破損しています(定数 int8=127)
(5、15)0.24256OK

しきい値は H と W にそれぞれ独立して適用されます。すべての不具合ケースにおいて、VX 出力はすべての位置で int8 = 127 に飽和します。正の int8 極値への飽和 (output_zp または 0 ではなく) は、最終クランプ前の乗算器シフトオーバーフロー、または MAC 結果の代わりに固定値が出力タイルに書き込まれていることを示唆しています。この問題はカーネル領域とは関係ないようです(例えば、15x15は正常に動作します)。

このしきい値は必要条件ではあるが十分条件ではない。K ≥ 16 の場合、一部の int8 の重み値のパターンはバグを引き起こすが、他のパターンは引き起こさない。バイトレベルの分離実験(破損したアーティファクトと破損していないアーティファクトの間に個々のTFLiteテンソルフィールドを移植する)を行い、値パターンのトリガーを特定のテンソルフィールドに絞り込みました。もしお役に立てるようでしたら、分離結果と使用したツールを喜んで共有いたします。


詳細ログ抜粋(VSI_NN_LOG_LEVEL=5、大文字小文字を区別しない)

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 としてバンドルされています。

  • conv_1x17_broken.tflite — 2,136バイトの破損したアーティファクト。
  • conv_1x15_torch_control.tflite — 2,056バイトのサブスレッショルド制御、同じパイプライン。
  • reproduce.py — ボード側再現ツール(tflite_runtime + numpyのみ)。
  • vsi_nn_log_level_5_conv_1x17.txt — 完全な詳細ログ。

ご要望に応じて、追加のアーティファクトを提供できます。バイトレベルの分離ツール、デルタ解析用の構造的に同一の動作アーティファクト(1、17)、完全な十分条件グラフト結果。

i.MX 8M | i.MX 8M Mini | i.MX 8M NanoLinuxソフトウェア不具合の疑いRe: Conv2D on i.MX 8M Plus VX delegate produces incorrect output when either spatial kernel dim >

こんにちは、 @themis_stewartさん

情報ありがとうございます。いただいた2つの質問について、社内チームに確認中です。

よろしくお願いします、
志明

Re: Conv2D on i.MX 8M Plus VX delegate produces incorrect output when either spatial kernel dim >

こんにちは、 @themis_stewartさん

カーネルサイズが16より大きい場合に演算をCPUにフォールバックさせるには、 L6.18.2に基づいた以下のパッチをお試しください。

よろしくお願いします、
志明

Re: Conv2D on i.MX 8M Plus VX delegate produces incorrect output when either spatial kernel dim >

迅速な対応をありがとうございます。ガードパッチを適用・テストした結果、こちらの問題は解決したと確認しています。

op_map.ccの変更を含むlf-6.18.2_1.0.0のデリゲートソースからパッチ付きlibvx_delegate.soを作成し、元のレポートの最小限のリプロダクターと比較して i.MX 8M Plus EVKで検証しました。パッチ適用後:

  • 影響を受けるINT8 Conv2D(空間カーネル≥16)は、デリゲートによって適切に拒否され、TFLite CPUにフォールバックするようになりました。ログメッセージにはフォールバックが明示的に表示され、int8 = 127へのサイレント飽和はなくなりました。出力はCPUの参照値と完全に一致する。
  • 本番モデル(カーネル≤15)は影響を受けず、完全にNPUに委譲されているため、ガードが過剰トリガーされないようにしています。

CPUフォールバックパスは実際には良好に機能していますが、フォールバックはNPU上で完全に動作するモデルよりも自然に遅いです。回帰テストのカバレッジ向上に役立つようでしたら、詳細な前後比較ベンチマークを個別にご提供いたします。

改めてありがとうございました。大変感謝しています。

タグ(1)
評価なし
バージョン履歴
最終更新日:
火曜日
更新者: