Intel GPU のオープンソースドライバーに、Tiger Lake GPU における L1キャッシュに対応するマージリクエストが投稿されている。
その中で、L1キャッシュ対応による性能への効果について触れられていた。
Index
増設された L1データキャッシュ
ここでの L1キャッシュは Xe-LP/Gen12.1 アーキテクチャ より Sub-Slice部に増設された L1データキャッシュのことを指す。
また、HDC は Data Cluster または Data Port の意とされ、キャッシュやローカルメモリへのアクセス帯域に関わる部分である。
MOCS は Memory Object Control State の略。GPU部の L3キャッシュや LLC(Last Level Cache)、eDRAM をキャッシュとして定義するために用いられる。
ただ、Intel は Xe-LP/Gen12.1 アーキテクチャ に関するドキュメントをまだ公開しておらず、L1データキャッシュの容量や帯域等は不明。
上記画像では L1/TEX$ という風に書かれており、元々テクスチャサンプラー部に含まれていたキャッシュを汎用的に扱えるよう移したとも考えられるが。
その効果
今回のマージリクエストでは、テクスチャやイメージの格納、データの移動に用いることを想定した L1 + L3 と、
フレームバッファや定数を想定した L1 + L3 + LLC の MOCS が追加されている。
ここに L2 が無いのは、Intel GPU では L3キャッシュバンクそれぞれの内部を用途別に割り当てる形式を採っており、その中でテクスチャサンプラー等がアクセスするリードオンリーキャッシュ部を L2キャッシュとしているためである。
L3キャッシュの一部が実質 L2キャッシュと扱われ、メモリ階層としてそれより下は CPU と共有する LLC、次に eDRAM や DRAM となる。
コメントによると、Windows の Vulkan/OpenGL ドライバーでも近い対応 (全く同じではない) を行なっているようだ。
L1データキャッシュの対応により、いくつかのゲームタイトルやグラフィクスベンチマークで性能向上が確認され、Unreal Engine 4 Shooter Demo では 11.84%、Doom (2016) では 11.40%、Shadow of the Tomb Raider では 9.40% 性能が向上している。
これらは Vulkan API に対応したゲーム、ベンチマークであり、OpenGL API に対応したゲームでは性能向上幅が Vulkan よりも小さくなり、Xonotic では 2.78%、Counter Strike: Global Offensive では 1.43% となっている。
GFXBench5 では Vulkan、OpenGL 関係無く小さい性能向上に留まり、Vulkan で 1.52%、OpenGL で 1.01％。
また、中には性能が下がったタイトルもあり、Dota 2 では Vulkan で 2.2%、OpenGL で 1.6% 性能が低下している。
L1データキャッシュへの対応で最大で 12% 近く性能が向上するというのは、アーキテクチャの改良においてかなり効果的であるように思える。
Ice Lake や Elkhart /Jasper Lake の GPU部に採用されている Gen11 アーキテクチャ から Xe-LP/Gen12.1 アーキテクチャ への変更点の中には、L1データキャッシュの増設の他に Sub-Sliceあたりの EU(実行ユニット)数を 8基から 16基に増やしたというものがある。
上述したように L1データキャッシュは Sub-Slice部に配置されており、Sub-Sliceあたりの EU数が多ければそれだけ多くの EU数でキャッシュを共有できることになる。
その点では、EU 8基のままに L1データキャッシュを共有するよりも、EU 16基で共有した方が有利だろう。
オーバーヘッドが比較的小さい Vulkan ではこの構成が効果的に働き、OpenGL よりも高い性能向上幅を得られたと考えられる。
API やドライバーとして、テクスチャやイメージの格納方法に違いが性能に影響した可能性もある。
多くの EU で L1データキャッシュを共有する上で、相応のキャッシュサイズと帯域を用意する必要があると思われ、やはり Intel によるドキュメントの公開が待たれるところである。
中には逆に性能低下しているゲームタイトルもあるが、L1データキャッシュは Xe-LP/Gen12.1 アーキテクチャ で増設されたメモリ階層であり、今後の最適化での解消が期待される。
また、L1データキャッシュはコンピュート処理にも効果的と思われるが、compute-runtime では現在無効化されているようだ。1