2412035_ja-JP

はい

i.MX8M Plus：VIP8000同時使用時に断続的なフレームシフトの低下と緑色のトップバンドのちらつきが発生する

1. システムと環境

パラメータ設定

SoC	NXP i.MX 8M Plus Quad
シリコン・レビジョン	A1 / B0
カーネル	6.12.20-lts-next-g604d4ef7a1e4
BSP	NXP linux-imx / LTS-Next
ビバンテ/ガルコア・ドライバー	6.4.11.p3.1049711
ガルコアの場所	ドライバ/mxc/gpu-viv/galcore (内蔵)
2Dエンジン	Vivante GC520L(imxvideoconvert_g2d / libg2d.so)
NPU	VeriSilicon/Vivante VIP8000
NPUパフォーマンス	2.3トップ
ビデオエンコーダー	Hantro VC8000E (v4l2h264enc)
RAM	~5.7 GB LPDDR4
CMAトータル	約960MB

2. 問題の説明

VIP8000 NPUの推論とGC520L G2Dエンジンを使用したハードウェアスケーリング/カラー変換が同時に実行されると、断続的にビデオが破損する問題が発生することが確認されています。

影響を受けるH.264ストリームは、完全に緑色にはなりません。その代わりに、個々のフレームが時折次のような挙動を示すことがあります。

アクティブイメージが、わずかなピクセル数／走査線だけ下方向にずれているように見える。
画面上部に水平方向の緑色の帯が表示されます。
次のフレームはすぐに正しい位置に戻ります。
その結果、断続的にフレームが下方向にジャンプしたり、画面上端が緑色にちらついたりする現象が発生します。

この問題は同時アクセラレータのワークロード中は再現可能ですが、NPUやG2Dワークロードを独立してテストした場合は信頼性が高く再現できません。

3．主な観察事項

3.1 G2Dのみのワークロードは安定している

最大3つの同時運行可能なG2Dビデオブランチを実行できます:

メイン：1080p
字幕: 360p
MJPEG: 480p

NPUを無効にした状態で。

映像は長時間にわたり安定しており、緑色のフレームやフレームシフトは観察されません。

3.2 NPUのみのワークロードは安定している

約 15〜30 FPS での重度VIP8000 NPU推論は、G2Dプロセッシングが非稼働中でも推論エラーや映像破損なしに連続的に動作します。

3.3 G2DをCPUプロセッシングに置き換えることで問題は解消されます

ハードウェアG2Dプロセッシングが以下に置き換えられる場合:

videoscale ! videoconvert

NPUがフルワークロードで稼働し続けている間も、システムは安定した状態を維持する。

緑色の帯状の表示やフレームシフトの問題は、もはや発生しなくなりました。

3.4 NPUとG2Dの同時実行が問題を引き起こす

NPUがアクティブで、G2Dが同時に映像やAIプロセッシングに使われていると、破損が発生します。

G2Dワークロードが追加されると、その頻度は増加する。

これは、 問題が個々のNPUやG2Dのワークロードだけでなく、同時進行中のアクセラレーター活動に関連していることを示唆しています。

4. テストマトリックス

故障原因を特定するために、以下の試験を実施しました。

Test NPU AIプロセッシングビデオG2D結果

1	オフ	なし	メイン + サブ + MJPEG (3つのG2Dブランチ)	合格— ちらつきなし
2	オフ	SHMが添付されています	メイン + サブ + MJPEG	合格— ちらつきなし
3	オン	G2D対応	メインG2D	失敗— 断続的なグリーンバンド/フレームシフトが観測されました
4	オン	CPU (ビデオスケール!ビデオ変換）	メインG2D	合格— 主流のクリーン
5	オン	CPU	メイン + サブ G2D	失敗— 追加の G2D ワークロードが導入されると問題が発生します
6	オン	CPU	すべてのビデオブランチがCPUスケーリングに変換されました	合格— すべての河川はきれいな状態です

注：現在、この問題を引き起こすために必要な同時接続G2Dクライアントの最小数を正確に特定するための、より小規模なスタンドアロン再現ツールを準備中です。

5．現在の調査

上記の結果に基づき、この行動が以下の領域のいずれかに関連している可能性があるかどうかを理解したいと考えています。

A. Galcore / アクセラレータ同時実行

デバイスツリーでは、GPU/NPUコンポーネントは同じGPU/MLサブシステムの一部です:

mix_gpu_ml@40000000 {
    compatible = "fsl,imx8mp-gpu", "fsl,imx8-gpu-ss";
    cores = <&gpu_3d &ml_vipsi &gpu_2d>;
    reg-names = "phys_baseaddr", "contiguous_mem";
    memory-region = <&gpu_reserved>;
};

割り込みもgalcoreによって処理されます。

34:        520          0          0          0     GICv3  35 Level     galcore:0
35:      13583          0          0          0     GICv3  45 Level     galcore:3d-1
36:    1737916          0          0          0     GICv3  57 Level     galcore:2d

私たちは以下の点を理解したいと考えています。

galcoreは、GC520L、GC7000、VIP8000間で同期プリミティブまたはロックを共有していますか？
G2DとNPUのコマンドキューは完全に独立しているのでしょうか？
VIP8000推論がアクティブな状態で、複数のG2Dクライアント/プロセスが作業を送信する場合、既知の制限事項はありますか？
コマンドの提出、コンテキストマネジメント、割り込み処理、リソースロックは、同時ワークロード下で遅延を引き起こす可能性があるのでしょうか?

B. NoC / DDR帯域幅またはQoS

GC520L G2DとVIP8000 NPUはどちらも外部LPDDR4メモリにアクセスするアクティブバス・マスタです。

重いNPU推論が以下を可能にするかどうかを判明したい。

NoC/DDRトラフィックを大幅に増加させる。
G2Dのメモリアクセス**レイテンシ**を増やしてください。
G2Dトランザクションの遅延を引き起こす。
G2Dと下流の消費者間のタイミング／同期の問題を明らかにする。
NoC/DDRのQoS優先順位の影響を受ける。

NXPは、この種のワークロードを調査するためにi.MX8MP上で推奨される NoC/AXI/DDRのパフォーマンス監視およびQoS機能 について指針を提供できるでしょうか?

C. G2Dバッファ同期/フェンス/ストライドの問題

この視覚的なアーティファクトは、フレーム全体が破損しているわけではないという点で特に興味深い。

影響を受けるフレームは、おおよそ以下のようになります。

+----------------------------------+
|        GREEN HORIZONTAL BAND     |
+----------------------------------+
|                                  |
|                                  |
|       IMAGE SHIFTED DOWN         |
|                                  |
|                                  |
+----------------------------------+

これにより、この問題には以下のようなものが含まれる可能性があるのではないかと疑問が生じます。

G2D宛先バッファの同期。
DMA-BUFの所有権／再利用。
フェンスの信号発信／完成。
一時的なG2D目的地オフセット/ストライド状態。
G2Dメモリ書き込みの遅延。
G2D操作が完全に完了する前に下流VPUアクセスが行われています。

特に、遅延したG2Dの完了や同期イベントが、v4l2h264enc / VC8000EがすべてのG2D書き込みが完了する前に目的地DMA-BUFを消費する可能性はありますか?

NXPのG2D/V4L2パイプラインには、宛先DMA-BUFがVPUによって消費される前にG2D処理が完了することを保証する、文書化された同期メカニズムはありますか？

D. メモリ / CMA

問題の再現中にメモリ使用量を監視しました。

Total RAM : ~5.7 GB
CmaTotal  : ~960 MB
CmaFree   : ~677 MB

したがって、CMAは故障発生時にも枯渇状態には至っていない。

しかし、同時進行のNPU/G2D/VPUワークロードに影響を与える可能性のある他のメモリ関連の考慮事項があるかどうかを知りたいです。例えば:

DMA-BUF同期。
キャッシュの一貫性。
メモリ領域のマッピング。
物理バッファのアライメント。
バッファの再利用。
IOMMU/MMUマッピング。
予約メモリとのやり取り。

6.追加の診断実験

現在、アプリケーションレベルの複雑さを取り除くための最小限のスタンドアロンリプロダクションを準備中です。

計画されている複製装置には以下が含まれる：

Thread 1 → VIP8000 NPU inference
Thread 2 → GC520L G2D processing
Thread 3 → Additional GC520L G2D processing

また、以下の構成についてもテストを行う予定です。

NPU OFF + G2D
NPU ON  + G2D
NPU ON  + 2 × G2D
NPU ON  + G2D → buffer inspection
NPU ON  + G2D → VPU encoder

これにより、破損がG2D出力バッファ自体で発生しているのか、それともバッファがVPUによって消費された後にのみ発生しているのかを判断するのに役立つはずです。

7. NXPへの質問

NXP社には以下の点についてご助言いただければ幸いです。

1. 既知のハードウェア/ソフトウェアの制限

以下の同時実行は可能ですか？

VIP8000 NPU
+
GC520L G2D
+
VC8000E VPU

i.MX8M Plusでは、複数の同時G2Dクライアントを含むすべての機能が完全にサポートされていますか？

この組み合わせに関連する既知のハードウェア制限、訂正表、ソフトウェア上の制限はありますか?

2. ガルコア

VIP8000とGC520Lの同時動作に関して、既知のガルコアの問題はありますか？

特に、以下のような既知の問題はありますか？

共有ロック、
コマンドキュー、
コンテキスト切り替え、
割り込み処理、
同期、
それともリソースマネジメントですか?

3. DMA-BUF / 同期

宛先DMA-BUFが下流のV4L2/VPUコンポーネントによって消費される前に、G2Dの完了を保証するためにどのようなメカニズムが使用されますか？

imxvideoconvert_g2d/libg2dの同時アクセラレータワークロード下で、フェンスやバッファの所有権問題が既知のものはありますか?

4. NoC / QoS

NXPは、測定にどのようなデバッグレジスタ、debugfsノード、パフォーマンスカウンタ、またはツールを推奨していますか？

GC520L AXIトラフィック、
VIP8000 AXIトラフィック、
VPUトラフィック、
DDR帯域幅、
NoC競合、
QoS/仲裁動作はどうでしょうか？

5. ドライバーバージョン

現在使用しているもの：

Kernel:
6.12.20-lts-next-g604d4ef7a1e4

Galcore:
6.4.11.p3.1049711

この組み合わせは、i.MX8MPの検証済み/推奨構成ですか？

NPU/G2Dの同時ワークロードに対応する新しいgalcore / G2Dのドライバーやパッチセットはありますか?

6. シリコン関連の訂正

当サイトA1/B0リビジョンに適用されるi.MX8M Plusシリコンエラッタに、以下に関連する問題が含まれているかどうか確認していただけますか。

G2D、
VIP8000、
VPU、
AXI/NoC 仲裁、
DDR、
キャッシュコヒーレンシ、
それとも同時アクセラレータの動作ですか?

7. 推奨構成

アプリケーションを必要とする場合:

VIP8000 NPU inference
+
multiple G2D scaling/color-conversion pipelines
+
VC8000E H.264 encoding

NXPはどのような構成を推奨していますか？

具体的なものはありますか？

ドライバーパラメータ、
QoS設定、
メモリ/バッファプール構成、
同期メカニズム、
またはGStreamerパイプラインの実践

それは従うべきことでしょうか？

8. 提供できる情報

必要に応じて以下の情報を提供できます:

GStreamerパイプラインを完全に構築します。
デバイスツリーの設定。
カーネル設定。
再現時のdmesg出力。
/proc/interrupts。
G2D/NPUワークロードの詳細。
v4l2-ctl の情報。
最小限のNPU + G2D再現プログラム。
破損したフレームを含むビデオサンプル。
ドライバのバージョンとビルド情報。

推奨されるデバッグ手順、または根本原因がG2D/NPU同期、DMA-BUF/フェンス処理、NoC/DDR競合、galcore、またはシリコン制限に関連しているかどうかを判断するのに役立つ追加のトレース/レジスタに関するガイダンスがあれば幸いです。

よろしくお願いします。

ヴィシュヌS

i.MX 8M | i.MX 8M Mini | i.MX 8M Nano