2410044_ja-JP

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

2410044_ja-JP

2410044_ja-JP

i.MX8MP - Qt OpenGL / 大規模EGLレンダーターゲットを使用すると、Vivante 6.4.11.p4.xでWestonがクラッシュする

こんにちは、NXPサポートの皆さん、

私たちはi.MX8MPプラットフォーム上の再現可能なグラフィックス問題を調査しています。

動作構成

  • ヨクト・スカースギャップ
  • カーネル: 6.6.52
  • Vivanteスタック: 6.4.11.p2.x
  • Weston 14.0.2.imx
  • Qt 6.8.3

結果:

  • Qt Quickは
  • QOpenGLWindowは動作します
  • クラッシュなし

設定エラー

  • ヨクト・ライノーズ
  • カーネル: 6.18.20
  • Vivanteスタック:6.4.11.p4.4および6.4.11.p4.6
  • Weston 14.0.2.imx
  • Qt 6.8.3 および 6.8.4

結果:

  • QQuickWindowがクラッシュする
  • QOpenGLWindowがクラッシュする
  • ウェストンがSIGSEGVと衝突
  • また、メモリ破損の症状も確認されました。
malloc(): unaligned tcache chunk detected

グラフィック障害発生後には、無関係なプロセスが時折クラッシュする。


Qtはおそらく根本原因ではない

当初、この問題はQt Quickの問題のように見えた。

しかし、テストケースは最小限に絞りました:

QOpenGLWindow
 

QML、シーングラフ、QRhi、テクスチャ、カスタムレンダリングは使用しません。

故障は依然として発生する。


ネイティブEGLテスト

シンプルなネイティブのWayland/EGL/GLES3アプリケーションは安定しています:

wl_egl_window
eglCreateContext
glClear
eglSwapBuffers
 
最大サイズまでリサイズした場合でも:
 
1920x1080
 

何時間も。


追加のネイティブEGLテスト

私たちは以下の方法でネイティブのWayland/EGL/GLES3テストを作成しました。

  • テクスチャ割り当て
  • FBOの作成
  • テクスチャへのレンダリング
  • glFramebufferTexture2D()
  • glBlitFramebuffer()
  • eglSwapBuffers()

以下のサイズは正常に通過します。

500x500
640x480
800x480
900x540
1024x600
 
この問題は、以下のようなより大きなレンダリングターゲットで発生し始めます。
 
1280x720
1280x800
 

ウェストンの行動

OpenGLアプリケーションを起動した後、Westonはクラッシュします:

weston.service: Main process exited
status=11/SEGV
 
Qtアプリケーションは次のように報告します:
 
The Wayland connection broke.
Did the Wayland compositor die?
 

これは、ウェストンが最初に衝突したことを示唆している。


Vivanteのユーザースペースの違い

正常に動作するシステムと故障しているシステムで異なるライブラリは以下のとおりです。

libGAL.so
libEGL.so
libGLESv2.so
 
この問題はどちらの環境でも再現可能です。
 
6.4.11.p4.4
6.4.11.p4.6
 

一方、年配の方は:

6.4.11.p2.x
 

6.6カーネルで動作します。


質問

  1. Vivante 6.4.11.p4.x には、以下の点に関する既知の問題はありますか?

    • Weston
    • ウェイランド-EGL
    • FBO(固定基地運営事業者)
    • glBlitFramebuffer()
    • 大きなレンダリングターゲット
  2. p2.xとp4.xの間には既知の回帰関係はありますか?

  3. 以下の項目について、推奨されるデバッグオプションはありますか?

    • ガルコア
    • libGAL
    • libgbm_viv
    • Westonバッファのインポートパス

何かご助言いただければ大変ありがたいです。

Vivanteスタックを使ったカーネル6.18.20でクラッシュを再現できる簡単なテストアプリ(6.4.11.p4.4と6.4.11.p4.6)を添付しました

Re: i.MX8MP - Weston crash with Vivante 6.4.11.p4.x when using Qt OpenGL / large EGL render targets

私はさらに調査を進めた。

カーネル6.6.52とVivante p6.4.11.p4.4の組み合わせは動作します。

カーネル6.18.20とVivante p6.4.11.p4.4の組み合わせでクラッシュする

調査結果は明らかに悪化している。

500x500から1024x600への直接的なサイズ変更だけでも、クラッシュを引き起こすのに十分だ。
クラッシュはOpenGLの処理パス内で、スワップチェーンのサイズ変更直後に発生します。
同時に、systemd-journalのSEGVが再び発生します。
これは単なるアプリのエラーではなく、GL/Wayland/Vivanteスタックにおけるメモリ破損の強い兆候です。

仮説の現状

重要なのは1280x720という解像度だけではない。
むしろ、決定的な要因は「再構成」に直接ジャンプし、その後に「提示」を実行することである。
連続的に小さなサイズ変更を行う方が、直接的なサイズ変更よりもはるかに堅牢です。
ソフトウェアバックエンドは安定しており、問題はハードウェア-GL経路にあることが確認されています。

Re: i.MX8MP - Weston crash with Vivante 6.4.11.p4.x when using Qt OpenGL / large EGL render targets

こんにちは、

Qtの問題よりもVivante/galcoreやバッファ管理の問題です。特にネイティブEGLテストもトリガーし、Westonが最初にクラッシュするプロセスなので。レンダリングターゲットが大きい場合に発生し、p4.xスタックでのみ発生するという事実は、特に興味深い。p2とp4のGAL/GBMの変更点を比較し、バッファの割り当てとインポートに関するgalcore/Westonのデバッグを有効にします。

Tags (1)
No ratings
Version history
Last update:
yesterday
Updated by: