2416755_ja-JP

Yes

OpenGL es ctsを実行しているときに、いくつかのGPUがクラッシュしたり無効な出力が出たりします

こんにちは、

3年以上にわたり、私たちはi.MX6QuadPlusでデバイスを出荷してきました。これはYocto hardknott上で構築され、WestonのQt 6.3.2で構築されています。製品が成長するにつれて、ユーザーからクラッシュ報告が増え、自分たちのコードやQtの中に原因が見つかりませんでした。一部は修正できました。DDRのタイミングを調整したり、特定のビューでシャドウを無効にしたり、内部バッファのサイズを増やしたり、アプリをGPU_VIV_EXT_RESOLVE=0で動かしたりしましたが、それでもレポートは届き、その多くはGPU関連でログに次のように表示されます。

カーネル: *** GPU DRV 設定 ***
カーネル:Galcore バージョン 6.4.3.336687
カーネル:Galcoreオプション:
...
カーネル:[galcore]: シーンを保つためにドライバを止めてください。

これはドライバ自身のハングレポートで、モニタータイマーは進行状況を認識せず、GPUの状態をダンプgckKERNEL_Recovery、recovery=0なのでドライバはコアをリセットせずサービスを停止します(recovery=1は私たちには選択肢にありません。なぜなら、すべてのGUIアプリケーションを再起動する必要があるからです)。画面は完全にフリーズし、ウェストンはSIGKILLを使っても倒せないことが多く、唯一の脱出方法は停電で、これはお客様にとって非常に悪いことです。

Qtやアプリケーションレベルで多くのことを試しましたが、回避策しか得られなかったため、高レベルの機能テストをやめ、OpenGL ESのエントリポイントを直接テストすることにしました。正常に動作すれば問題は私たちの責任、そうでなければドライバやハードウェアの故障(少なくとも部分的)です。

私はVK-GL-CTS（ https://github.com/KhronosGroup/VK-GL-CTS ）を使ってそれをやりました。クロスコンパイルを簡単にするために最初はRustに移植されました(まだ進行中で、関連するケースの約半分しか確認できませんでした)。ケース名は上流のdeqp-gles2/gles3/gles31と同じで、Mesa llvmpipeやUbuntu 24.04のカジュアルノートPC(Mesaドライバー付き)でもすべてパスされます。つまり、ボードの故障はボード自体の問題です。週末にハードウェア上で実行したところ、AIの助けを借りて14個の異なる欠陥を発見し、最小限に抑えることができました。それぞれが独立した再現可能なコードになっています。具体的には、依存関係のないシンプルなRustプロジェクト、cargoビルドのみ、そしてGLSLを独自のファイルに記述したものです。

(JUst Run - ローカルで実行、 Armパーツだけ を抽出して、ビルドステップのみでバイナリを集められます(最初の カーゴインストールが必要で、ロックされたカーゴ・ジグビルド)

この部分のために構築可能な最新ドライバー、6.4.11.p4で依然として問題が残っています:

0001 GPUロックアップ - synchronization.inter_invocation.ssbo_atomic_read_write,一人きり、新しく履き替えたばかりのボードの上で。再起動しないとクリアできませんし、プロセス自体は壊せないので8〜10分かかります。
0002 GPUロックアップ - synchronization.inter_invocation.ssbo_atomic_overwrite、単体で。
0003 GPUのロックアップ - 20 synchronization.inter_invocation中10件。*ケースは単独で起こるが、他の10個はそうではないため、これは境界であり「計算が壊れている」とは言えない。すべての原子SSBO/イメージのバリアント。20人全員がそれぞれ10回のレースを制覇し、すべてのレースはリブート版から始まった。
0010リンク障害 - 同じstd140ブロックの47個のメンバーが両段階で読み取れた7件のUBOケース。どちらのステージだけでもリンクしますが、一緒にはリンクしません。glGetProgramInfoLogは空で、ドライバー自体が報告する制限(ステージあたり3ブロック対16ブロック、704バイト対65536バイト)はほとんどありません。最低でも47回の閲覧と46のリンクが必要です。
0011 結果が間違っています - shaders.invariance.highp.loop_*:同じ式から不変なgl_Positionを計算する2つのシェーダーが、深度に関して数ピクセルの差を生じます。
0013 ステータス列挙型が間違っています - fbo.completeness.size.distinct: ES 2.0 として要求されたコンテキストが ES 3.1 を報告し、その後 ES 2.0 ルールで完全性に応答し、ES 3.x で定義されていない列挙型を返します。

6.4.3.p2で修正済み-> 6.4.11.p4 ジャンプ:

0004 GPUロックアップ - image_load_store.cube.qualifiers.*_r32f（隣にあったr32ui/r32iは問題なかった）
0006 GPUのロックアップ - image_load_store.* 画像がレイヤー化されるたびに、21枚中8枚、2Dでは7枚中0枚、断続的です
0005 クライアントフリーズ - compute.indirect_dispatch.gen_in_compute.empty_command:glMapBufferRange は決して戻りません
0014 クライアントフリーズ - upload_buffer.empty_command 経由、同じ一度、配車がすでにマッピングされている場合
0007 誤った結果 - 18 &&の連鎖で、原子カウンタも宣言される場合、すべての項が真である場合にfalseになります(2007年のssbo.layoutケース中44件)
0008 コンパイラ - 保留ワードテーブルは間違った言語バージョン用、両方向に適用されます
0009 誤った結果 - 入力パラメータを介して返される構造体メンバーに対して、2 つの等しいベクトルに対して vec3 == vec3 が false になります
0012 コンパイラ - mediump vec2(1.0,1.0) コンパイルは成功するが、ESSL 1.00 文法には精度修飾子を入れる場所がない。

両方のテストは同じボードで行いました：i.MX6QPシリコンリビジョン1.0、2 GiB DDR、LVDS 1280x1024@60、fbdev上のWeston、use-g2d=1、GL_RENDERER "Vivante GC2000+"。

古い: hardknott、BSP imx-5.10.52-2.1.0、カーネル 5.10.52、Galcore 6.4.3.p2.336687、IMX-GPU-VIV 1:6.4.3.p2.2-aarch32,Weston 9.0.0.imx、Qt 6.3.2
new: wrynose、BSP imx-6.18.20-2.0.0、kernel 6.18.20、galcore 6.4.11.p4.1190909、imx-gpu-viv 1:6.4.11.p4.6-aarch32,Weston 10.0.5.imx、Qt 6.11.0

CONFIG_MXC_GPU_VIV=y、recovery=0、stuckDump=0 の両方でタイムアウトが発生し、20000 -> 30000 ms となり、6.4.11.p4 で softReset=1 が追加されました。

バージョンアップは助けになりますが、いくつかの問題は残っています。i.MX6の入手可能性のため、近いうちにi.MX8に移行する予定ですが、既存の基盤はいずれにせよi.MX6のハードウェアを保持しているので、将来的にこうした問題が解決されるのを見たいです

たとえYocto版をやめざるを得なくても、新しいドライバーでこれらの問題が修正される可能性はありますか?

この問題はi.MX8にもある程度存在しているのではないかと懸念していますが、Vulkan/OpenGL CTSでテストは行われていますか?現在行われているのか、それとも計画されているのでしょうか?それを通さなければ(さらにcts関数のランダム実行などのファズ処理も)、ドライバーの上層でランダムクラッシュは修正できないと思います

Re: Several gpu crashes/invalid output, when running opengl es cts

こんにちは、

i.MX 6/7の最新公開ドライバーは imx-gpu-viv 6.4.11.p4.6で、wrynose BSP(imx-6.18.20-2.0.0)が付属しています。リリースノートでは、そのジャンプが i.MX 6/7/8ラインの「バグ修正、パフォーマンス最適化」をもたらしたと説明されており、これはあなたの観察と一致しています。 .p2 と .p4の間に14の欠陥のうち8つが解決されたという点です。そして確かに、それは行われていますが、プラットフォームごとに重要な条件があります。Vivante(VSI)GPU搭載のi.MX8では、CTSが動作しています。Linux Factory内部のテストパイプラインでは、各リリース候補サイクルの一環として、i.MX8ボードに対して opengl-es-cts および vulkan-cts パッケージの両方を実行させます。発見された欠陥は、Linux Factory JiraプロジェクトCTSのi.MX8M Nano、i.MX95上で追跡されています。これは、i.MX8M Plus、i.MX8QuadMaxなどに搭載されているVivante GC7000シリーズGPUは、各GAリリース前に体系的な適合性テストを受けていることを意味します。

i.MX9（Mali / OSS Mesa搭載）向け

リリースノートには、Mesa OSS GPUスタック搭載 i.MX 95/952について明記されています:「OpenGL ES11、Vulkan 1.4.5、OpenCL 3.0の基本機能は動作していますが、適合性テストは合格していません。」そのi.MX9上のMali DDKのデフォルトパスはCTSに合格していますが、オープンソースのPanfrost/PanVKパスはまだ適合化の作業中です。

i.MX6 (GC2000+) に関しては、CTS のカバー範囲は最小限です。

現在のLinux Factoryパイプラインにおいて、GC2000+に対して体系的なdeqp/CTS実行が行われているという内部証拠は見つかりませんでした。GC2000+はOpenGL ES 3.0のみをサポートしており(3.1/3.2はサポートしていません)、テストインフラストラクチャは新しいi.MX8/9ボードをターゲットにしているようです。VK-GL-CTSでの作業は、この特定のIPに対する内部チャネルで見られる最も徹底した適合レベルのテストです。

結論として、FUTURE i.MX6ドライバーパッチが保証されているわけではありませんが、オープンサポートThreadを通じてスタンドアロンのリプロダクションを提供するのが正しい方法です。i.MX8移行に関しては、Vivante GC7000シリーズの適合状況がGC2000+よりも大幅に優れており、体系的なCTSテストもリリースプロセスの一部となっていますが、それでもなお galcore 6.4.11.p4 のドライバーバグは依然として発見・報告されています。

よろしくお願いします。

Re: Several gpu crashes/invalid output, when running opengl es cts

添付ファイルが見当たらず、追加を忘れたようだったので、もう一度追加しました