GetCopyableFootprints が返すメモリサイズについて

DirectX12 の GetCopyableFootprints メソッドが返すトータルメモリサイズについて、気になったことがあったのでメモとして記載しています。不具合の話ではなく、しっかりしている点で感心した話です。

GetCopyableFootprints

GetCopyableFootprints メソッドは、以下に示すものです (マイクロソフトのドキュメントより)。

void GetCopyableFootprints(
  [in]            const D3D12_RESOURCE_DESC          *pResourceDesc,
  [in]            UINT                               FirstSubresource,
  [in]            UINT                               NumSubresources,
                  UINT64                             BaseOffset,
  [out, optional] D3D12_PLACED_SUBRESOURCE_FOOTPRINT *pLayouts,
  [out, optional] UINT                               *pNumRows,
  [out, optional] UINT64                             *pRowSizeInBytes,
  [out, optional] UINT64                             *pTotalBytes
);

ファイルから読み込んだ画像をテクスチャとして転送する際の、ピッチやトータルメモリサイズはこの関数を呼び出して取得することができます。画像縦方向の数が pNumRows であり、横方向のバイトサイズ（＝ピッチ）が pRowSizeInBytes、必要とするメモリサイズが pTotalBytes に格納されます。

トータルメモリサイズの値

よく出来ていると驚いたのが、 pTotalBytes の計算の仕方です。 (*pRowSizeInBytes) × (*pNumRows) とすることで画像の必要な全領域サイズは簡単に計算できます。しかし、よく考えてみるとムダがあります。画像の一番最後の行では必ずしも *pRowSizeInBytes バイト数分が必要ではないのです。私が遭遇したときには、2次元的なかけ算の結果とトータルメモリサイズが一致せず、すこし疑問に思いました。最後の行は次の行までのスキマが不要なので、パディング分はメモリ不要ということですね。

遭遇するケース

2べき解像度のテクスチャ画像、RGBA 32bit フォーマットなど、キリのよいデータを扱っていると、 ここで返すピッチサイズと画像の横幅バイト数が一致してスキマ（パディング）が不要なことも多いので、なかなか気付かないかもしれません。 遭遇するのは非2べきの解像度を持つテクスチャを使ったときでしょうか。