概要
- VRAM管理の改善 に関するカーネルパッチが Linux 7.3にマージ
- VRAM不足時の パフォーマンスと安定性問題 の詳細な分析
- PCIe帯域制限 による実際のパフォーマンス低下の仕組み解説
- カーネルロックとデッドロック問題 の発生原因と修正作業
- 今後の課題と さらなるパッチ適用の必要性
VRAM不足時のゲーム挙動とLinuxカーネルの改善
- 2024年初頭に VRAM管理改善作業 についてブログ執筆
- 長期間のメーリングリストでの議論を経て、 カーネルパッチがLinux 7.3にマージ
- ゲームの VRAM使用量が物理VRAMを超えた場合の挙動 に注目
- 一般的には「ゲームがクラッシュ」「パフォーマンス激減」と予想される
- しかし理論上は パフォーマンス問題のみ で済むはず
VRAMオーバーコミットの理論と現実
- GPUドライバは VRAMオーバーコミット をサポート
- 要求されたVRAMはカーネルが物理メモリに収まる範囲で割り当て
- VRAM不足時は 一部メモリがCPU RAMへ退避
- GPUからCPU RAMへのアクセスは 大幅に遅い
- PCIe経由でのアクセスが 帯域・レイテンシ両面でボトルネック
- PCIe 4.0 x16接続時の理論帯域：約 32GiB/s
- 30FPS維持には1フレームで 最大約1GiBのデータ転送が限界
- この制限を超えると 30FPS維持は物理的に不可能
メモリアクセスパターンとキャッシュの影響
- 全てのメモリアクセスが等しく遅いわけではない
- コマンドバッファ等はCPU RAMでも問題なく動作
- キャッシュヒット時はVRAM/CPU RAM問わず同等のレイテンシ
- L2キャッシュ（例：RDNA3では6MB）内なら差異なし
- Infinity CacheはVRAMアクセスのみ利用、CPU RAMはPCIe直通
- PCIe経由はInfinity Cacheヒットの 約7.3倍のレイテンシ
- キャッシュ効率が高ければ CPU RAM利用でもパフォーマンス低下は軽微
- アクセス頻度が低い・部分的アクセスのみなら影響も限定的
実際のVRAM不足時の問題とカーネルロック
- SteamOSでゲームを起動し、VRAM不足時に 「Not enough memory for command submission」 エラー発生
- コマンドバッファは事前確保済みなのに、 コマンド送信時にメモリエラー
- amdgpuドライバは全ての割り当てメモリがGPUからアクセス可能かを確認
- 一部割り当ては VRAM専用 であり、退避された場合 VRAMへ戻す必要あり
- VRAMが空いていなければ、 他のメモリを退避しなければならない
カーネルのロックとデッドロック問題
- メモリ退避には ロック取得 が必要
- 複数のGPUサブミットが同時にロックを取得しようとすると ABBAデッドロック が発生
- Linuxカーネルは デッドロック検出・回避機能 （wound-abort-retry）を搭載
- drm_execライブラリで抽象化されているが、 TTM（GPUメモリ管理レイヤ）では未使用
- -EDEADLCKエラー発生時、退避処理が失敗しサブミットが拒否
パッチ適用と今後の課題
- drm_execをTTMに組み込むパッチセットを 自らリベース・バグ修正
- 数分でゲームがハングするバグと格闘しながら1週間で修正
- 追加の作業が必要なため、 今後も改良が続く見込み
- VRAM不足時でも アプリがクラッシュしない安定性向上 を実現
- ただしパフォーマンス低下の根本的解決にはさらなる検証が必要
まとめ
- Linux 7.3でVRAM管理が大幅改善
- VRAM不足の際の 安定性問題 の多くが解消
- パフォーマンス低下の本質的な原因 と今後の課題が明確化
- ゲームやGPUアプリの 高設定利用時の信頼性向上