カーネル更新後も内蔵GPUが利用可能か確認する方法
内蔵GPUが利用可能な状態であり続けるには、新しいカーネルがGPUを検出し、正しいドライバーをバインドし、レンダーノードを作成して、ワークロードから利用できるようにする必要があります。
ホームサーバーのカーネルを更新した後、ハードウェアアクセラレーションのスイッチが有効なままでも、メディアアプリがソフトウェア処理にフォールバックすることがあります。問題は、PCI検出、カーネルモジュールのバインド、ファームウェアの読み込み、DRMデバイスの作成、VA-APIの初期化、デバイス権限、Dockerのマッピング、またはメディアサーバーのFFmpegパスのいずれかで発生する可能性があります。アプリケーション設定を変更する前に、これらの層を順番に確認し、以前の起動時の状態と比較してください。
新しいカーネルを記録し、PCIバス上の内蔵GPUを確認する
実行中のカーネルバージョン、インストール済みの以前のカーネル、起動パラメーター、更新時刻を記録します。次に、数値ID付きのディスプレイクラスPCIデバイスと、内蔵GPUに現在バインドされているカーネルドライバーを一覧表示します。
内蔵GPUがPCI列挙に表示されない場合は、VA-APIを調査する前にファームウェアまたはBIOS設定を確認してください。内蔵GPUまたはマルチモニターのオプションが無効になっていると、サーバーにはディスクリートGPUしか表示されない場合があります。内蔵GPUがLinuxから隠れていた事例もその一例です。
デバイスIDとバインドされたドライバーを、最後に正常だった起動時の状態と比較します。Intelシステムでは、一般的にi915、または対応する新しい構成ではxeが使用されます。別のプラットフォームのモジュール名を無理に指定するのではなく、ハードウェアとディストリビューションに実際に適したドライバーを使用してください。
ドライバーとファームウェアの初期化についてカーネルログを確認する
現在の起動ログで、GPUドライバー、DRM、GuCまたはHuCファームウェア、ディスプレイの初期化、プローブ失敗、タイムアウト、モジュールのブラックリストを検索します。永続ログを利用できる場合は、以前のカーネルで同じメッセージが出ていたか比較してください。
ハードウェアが一覧に表示されていても、メディアドライバーが失敗することがあります。Intelの問題報告では、周辺のソフトウェアスタックが変更された後、内蔵Xe-LPG GPUでVA-APIの初期化に失敗しています。これは、ハードウェアが検出されるだけでは不十分であることを示しています。
必要なファームウェアパッケージが引き続き存在し、新しいカーネルパラメーター、ブラックリスト、またはセキュアブートポリシーによってモジュールがブロックされていないことを確認します。ホストドライバーが正常に初期化されるまで、メディアサーバーを再インストールしないでください。
DRMレンダーノードがまだ存在することを確認する
/dev/driを調べ、各カードとレンダーノードのメジャー番号、マイナー番号、所有者、グループ、シンボリックリンクの参照先を記録します。別のGPUが存在する場合、内蔵GPUが常にrenderD128になるとは限りません。
FFmpegが存在するものの有効なVAディスプレイを提供しなくなったノードを対象にすると、ハードウェアアクセラレーションは失敗します。Jellyfinの報告には、決定的なエラーとしてレンダーデバイスにVAディスプレイがないと記録されています。
sysfsを通じてレンダーノードをPCIデバイスに関連付け、ノードの識別子が実際に変わった場合にのみ、コンテナまたはアプリケーションの設定を更新します。777のような広範な権限は避け、レンダーグループの仕組みを維持して、サービスアカウントがそのグループに所属していることを確認してください。
Dockerの前にホスト上でVA-APIまたはQuick Syncをテストする
確認済みのレンダーノードに対して、ディストリビューションのVA-API診断ツールを実行し、ドライバー名、VA-APIバージョン、対応するデコードプロファイル、エンコードエントリーポイント、ビデオ処理機能を記録します。
ユーザー空間のメディアドライバーは、ハードウェア世代とカーネルインターフェースに適合している必要があります。解決済みのLinux事例では、カーネルのDRMモジュールとユーザー空間のDRIまたはVAドライバーは別々の層であることが強調されています。これらを混同すると、誤ったユーザー空間ドライバーが残る可能性があります。
ホストのVA-APIが失敗する場合は、現在のメディアドライバーとファームウェアパッケージを更新前のバージョンと比較します。ホストのVA-APIが成功する場合は、コンテナ境界の確認に進む間、カーネルとドライバーを変更しないでください。
コンテナ内でも同じデバイスとグループが使われていることを確認する
実行中のコンテナに割り当てられたデバイス、グループID、選択したレンダーノードへのアクセスを確認します。ホストでの成功はコンテナ内での成功を保証しないため、コンテナ内でメディアサーバーに同梱されたVA-API診断ツールまたはFFmpegビルドを実行してください。
コンテナに/dev/dri/renderD128が渡されていても、プロセスに対応するレンダーグループの権限がなければ失敗します。Jellyfinコンテナの報告では、デバイスのマッピングとグループアクセスの両方を検証する必要があることが示されています。
ホストとコンテナ内の数値グループIDを比較し、必要に応じて、デバイスとグループを明示的に設定してサービスを再作成します。ZimaSpaceのハードウェアトランスコードの確認ガイドでは、アプリケーションレベルで次に確認すべき事項が説明されています。
小規模なコーデックテストを強制し、実際のGPUエンジンを監視する
正常に動作することが分かっているH.264またはHEVCのサンプルを1つ使用し、字幕やHDRトーンマッピングを無効にしてビデオトランスコードを強制します。ダッシュボードの状態、FFmpegコマンド、トランスコード速度、CPU使用率、GPUのデコードまたはエンコードエンジンの動作を記録します。
メディアサーバーがハードウェアサポートを報告していても、VA-APIデバイスを自動的に誤選択することがあります。Jellyfinの問題報告では、デバイスを明示的に選択することで、FFmpegがアクセラレーション経路を検出できるかどうかが変わった事例が記録されています。
可能であれば、デコードとエンコードを個別にテストします。基本的なコーデックが動作する一方で、特定のコーデックだけが失敗する場合、内蔵GPUは利用可能ですが、そのプロファイル、ファームウェア機能、ドライバーパス、またはフィルターがサポートされていません。高度なトーンマッピングの失敗だけを根拠に、GPU全体が見つからないと判断しないでください。
以前のカーネルを使って制御された比較を行う
PCI検出、レンダーノード、またはホストのVA-APIが新しいカーネルでのみ失敗する場合は、コンテナイメージ、メディアサーバーのバージョン、ユーザー空間の設定を変更せずに、インストール済みの以前のカーネルで起動します。
Jellyfinのトラブルシューティング事例では、カーネル変更後に問題が発生したと考えられる場合、最も簡単な切り分け方法としてカーネルを戻すことが推奨されています。重要なのは、ロールバックを恒久的な修正とみなすことではなく、制御されたカーネル比較を行うことです。
現在のカーネルで内蔵GPUがPCI上に表示され、意図したドライバーがバインドされ、正しいレンダーノードが作成され、VA-APIが初期化され、コンテナ内からデバイスが利用でき、実際のコーデックテストがアクセラレーションで処理されれば、検証は完了です。以前のカーネルでのみ成功する場合は、カーネル、ファームウェア、またはメディアドライバーの回帰を特定するまで、以前のカーネルを一時的な起動オプションとして保持してください。
おすすめ商品
サポートとヒント
もっと読む
Plexは別のDockerコンテナとGPUを共有できますか？
Plexと別のコンテナは同じGPUにアクセスできることが多いですが、ドライバーのサポート、デバイスマッピング、ビデオエンジンの負荷、メモリ、復旧動作をテストする必要があります。
Plexのエラーがクライアント側とサーバー側のどちらに起因するかを見分ける方法
別のクライアントで同じ項目を再現し、セッションパスを比較してから、スコープによって障害の実際の所在が特定された後にのみサーバーの証拠を収集してください。
Plexのキャッシュとトランスコード用一時ストレージを設定する方法
永続的な Plex の状態を保護しつつ、トランスコードの一時ファイルを適切なローカルストレージに配置し、クリーンアップ、空き容量、再起動時の動作を確認します。
