VRAMの過剰な需要が悪影響を及ぼす理由
2026年8月18日付の開発者による技術報告によると、グラフィックスメモリー管理を改善するためのカーネルパッチがアップストリームにマージされ、Linux 7.3向けの待機列に入った。この作業は、ゲームがグラフィックスカードに物理的に搭載されている容量を超えるビデオメモリーを要求したときに何が起きるかに焦点を当てている。
GPUドライバーは以前から、VRAMの過剰割り当てを認めてきた。割り当てがデバイスメモリーを超えた場合、一部のデータをシステムRAMへ退避できる。理論上は、これによって処理が不安定になるのではなく、速度が低下するはずだ。実際には、VRAMを使い果たすとRADVとAMDGPUのスタックでコマンド送信の失敗も起こり得ることを、著者は発見した。
避けられない性能上の代償は、GPUとシステムメモリー間の接続から始まる。ディスクリートGPUにとってCPUのRAMへのアクセスは遅く、転送はPCI Expressバスを通過しなければならない。PCIe 4.0 x16リンクが提供する帯域幅は毎秒32GiBをわずかに下回り、1ミリ秒当たり約32.2MiBとなる。毎秒30フレームでは、1フレームは約33.3ミリ秒続くため、理論上転送できる量は約1,075.5MiBとなる。1フレームが退避済みデータを約1GiBより多く必要とする場合、バスだけを見ても30fpsの達成は不可能になる。
この制限は、CPUメモリーへのアクセスがすべて性能を台無しにするという意味ではない。ドライバーは、利用可能なVRAMがあっても、コマンド関連の割り当てをシステムRAMに残す場合がある。キャッシュとアクセスパターンが影響を左右する。データが上位レベルのキャッシュに残っていれば、それを支える保存場所が変わっても、キャッシュヒット時のレイテンシーは変わらない。そのため、アクセス頻度が低い割り当てやキャッシュと相性のよい割り当ては、退避先として選ばれても悪影響が比較的小さい場合がある。
レイテンシーと安定性は別の問題
RDNA3 GPUでのマイクロベンチマークは、その違いを示した。バッファーが6MBのL2キャッシュを超えると、CPU側メモリーへのアクセスには約2,400サイクルかかった。著者の推定では、PCIe経由のフェッチのレイテンシーはInfinity Cacheへのヒットの約7.3倍、VRAMからのフェッチの4.6倍だった。この負担を吸収するには、高いキャッシュヒット率が必要となる。
これらの測定値は、過剰割り当て時の性能を予測することが難しい理由を説明している。数ギガバイトを退避しても、1フレーム内で読み込まれるのがごく一部であれば、必ずしも致命的ではない。逆に、量が少なくても、アクセスパターンとの相性が悪く、頻繁にアクセスされる場合は、深刻な停止を引き起こし得る。
カーネルの問題は、こうした想定内の速度低下にとどまらなかった。ゲームがバッファーの割り当てに成功した後、すでに準備されたコマンドを送信する際にメモリー不足エラーを受け取ることがあった。コマンド送信自体は新しいリソースを要求していなかったにもかかわらず、カーネルが`-ENOMEM`を返した場合、RADVはその状態を報告した。
Linux 7.3向けの待機列に入った作業は、割り当ての成功と使用時の失敗との間にあるこの不一致の調査から生まれた。提示された抜粋には、最終的なパッチの仕組みの詳細やゲームのベンチマークは記載されていないため、裏づけられる結論はより限定的だ。すなわち、アップストリームの変更が予定されており、それは、VRAMの逼迫を帯域幅の制約だけで必要となる以上に悪化させていた安定性上の挙動を対象としている。



