前回は NVIDIA, AMD と両者での差異を見るために同じコードで実験しました。今回は AMD ならではの OpenGL 拡張を用いてどう変化が起こるかを見てみたいと思います。
AMD_pinned_memory
拡張に AMD_pinned_memory というものがあります。これは GPU から物理メモリへのアクセスをさせるという拡張です。
こちらを用いると、以前実験したように中身を書き換えても再送コマンドの実行が必要なかったりします。
実験
pinned_memory の機能を用いて前回と同じように、頂点バッファ (VBO) を作成してみます。この際に使用メモリと使用 VRAM がどのように変化するかを観測します。
確保する頂点バッファは 32MB とし、今回もまたプロセスヒープの影響がないように、それと、アライメント調節の手間を減らすため OS からの直接ページのアロケートを使っています。
実験結果
実験は RADEON 5450, 7750 で行っていますが、傾向が異なることはなかったので、 5450 のほうを記載しています。また pinned memory の場合は元データ解放処理ができないのでその項目は除外しています.
状態 | メモリ(MB) | Dedicate(MB) | 共有メモリ(MB) |
---|---|---|---|
初期化終了後 | 1193.7 | 44 | 19 |
元データ準備 | 1226.2 | 44 | 19 |
glBufferData実行後 | 1226.2 | 44 | 19 |
初回描画後 | 1220.1 | 47 | 52 |
32MB の VBO は Shared Memory の扱いとして処理されたようです。おおよそ 32.5 MB 消費されています。
注目すべきは glBufferData の内部で追加のメモリが要求されていないことです。前回 NVIDIA, AMD 双方で標準的な方法で glBufferData を実行の際にはこの部分で内部で勝手に追加のメモリを消費されていました。また初回の描画で初めてリソースが確保されるようです。
まとめ
pinned memory 拡張は暗黙のメモリ確保がないという点でよさそうに感じました。前回の時もそうでしたが、 AMD の場合には定常状態においては、元データサイズ分程度のシャドウコピーがどこかに存在するようです。 NVIDIA の場合と違い、バッファサイズ分を見積もっておけば良さそうなのでまだ制御がしやすそうです。
コメント