D3D12_FEATURE_DATA_ARCHITECTURE

アダプターのアーキテクチャに関する詳細を提供し、アプリケーションが特定のアダプター特性に合わせてより適切に最適化できるようにします。

UMA と CacheCoherentUMA の使い方

D3D12 アプリケーションは、メモリの常駐 (residency) の管理と、最適なヒーププロパティの指定に注意を払う必要があります。 D3D12 アプリケーションは、D3D12_HEAP_TYPE_DEFAULT ヒープ内のリソースの常駐のみを管理することで、実装をシンプルに保ったまま多くの GPU アーキテクチャで十分に良好な動作を得られます。 そのようなアプリケーションは DXGI_MEMORY_SEGMENT_GROUP_LOCAL について IDXGIAdapter3::QueryVideoMemoryInfo を呼び出すだけで済みますが、D3D12_HEAP_TYPE_UPLOAD と D3D12_HEAP_TYPE_READBACK が同じメモリセグメントグループから確保されることを許容しなければなりません。

しかし、このような単純な設計は、限界まで性能を追求するアプリケーションにとっては制約が大きすぎます。 そこで D3D12_FEATURE_DATA_ARCHITECTURE は、基盤となるアダプターの特性に合わせてアプリケーションがより適切に最適化できるよう支援します。

一部のアプリケーションは、ディスクリートアダプター向けにさらに最適化し、システムメモリとビデオメモリの両方の予算を管理するという追加の複雑さを引き受けたいと考えるかもしれません。 アップロードヒープのサイズが既定のテクスチャのサイズに匹敵する場合、メモリ使用効率をほぼ 2 倍に高められる可能性があります。 このような最適化をサポートする場合、アプリケーションは 2 つの常駐予算を検出するか、UMA が false であることを認識することができます。

一部のアプリケーション、特にモバイルデバイスでのバッテリー駆動時間の延長に関心があるものは、統合型 / UMA アダプター向けにさらに最適化したいと考えるかもしれません。 単純な D3D12 アプリケーションは、UMA では必ずしも必要でない場合でも、属性の異なるヒープ間でデータをコピーせざるを得ません。 ただし UMA というプロパティ自体は、GPU 設計のかなり曖昧なグレーゾーンを含んでいます。 UMA であれば GPU からアクセスできるメモリをすべて自由に CPU からアクセス可能にできる、と考えてはいけません。実際にはそうではありません。 その種の考え方により近いプロパティが CacheCoherentUMA です。

CacheCoherentUMA が false の場合、常駐予算は 1 つだけですが、UMA 設計では通常 3 種類のヒープ属性が有益です。 メモリへの CPU アクセスを提供するアップロードおよびリードバックのリソースとヒープを賢く利用することで、リソースのコピーを削減できる余地は確かに存在します。 ただし、そのような余地は明確ではありません。 そのためアプリケーションは慎重であるべきであり、さまざまな「UMA」システムでの検証が推奨されます。特定のデバイス ID に対して有効化または除外する対応が必要になる場合もあるためです。 GPU のメモリアーキテクチャと、ヒープの種類がキャッシュのプロパティにどのように対応するかを理解しておくことをお勧めします。 成功の見込みは、各プロセッサーがデータを読み書きする頻度、データアクセスのサイズや局所性などに依存する可能性が高いです。 上級開発者向け: UMA が true かつ CacheCoherentUMA が false の場合、これらのアダプターの最も特徴的な点は、アップロードヒープが依然としてライトコンバインであることです。 ただし一部の UMA アダプターは、既定ヒープの CPU アクセス不可という性質と、アップロードヒープのライトコンバインという性質の両方から恩恵を受けます。 詳細については GetCustomHeapProperties を参照してください。

CacheCoherentUMA が true の場合、アプリケーションはヒープの属性分けをやめ、あらゆる場所でアップロードヒープ相当のカスタムヒープを使用することを、より積極的に検討できます。 共有利用によって恩恵を受けるシナリオが増えるため、ゼロコピーの UMA 最適化が一般により強く推奨されます。 このメモリモデルは、より多くのシナリオとより広範な採用に適しています。 恩恵を得にくい特殊なケースが残る可能性はありますが、他の選択肢に比べればはるかにまれであり、影響も小さいはずです。 上級開発者向け: CacheCoherentUMA は、メモリ階層内のキャッシュのかなりの部分が CPU と GPU の間で統合または一体化されていることを意味します。 最も特徴的で観測しやすい点は、CacheCoherentUMA ではアップロードヒープが実際にはライトバックであることです。 これらのアーキテクチャでは、アップロードヒープでライトコンバインを使用することは通常は不利になります。

これらの低レベルの詳細は、大多数のシングルアダプターアプリケーションでは無視して構いません。 通常どおり、シングルアダプターアプリケーションは状況を単純化し、CPU からアップロードヒープへの書き込みがライトコンバインに適したパターンになるようにすれば十分です。 低レベルの詳細は、マルチアダプターアプリケーションにとっての概念を補強するのに役立ちます。 マルチアダプターアプリケーションでは、アダプター間でデータを効率的に移動するために最適なカスタムヒーププロパティを選択できるよう、アダプターのアーキテクチャ特性を十分に理解する必要があるでしょう。

#include <windows.h>

// D3D12_FEATURE_DATA_ARCHITECTURE  (x64 16 / x86 16 バイト)
typedef struct D3D12_FEATURE_DATA_ARCHITECTURE {
    DWORD NodeIndex;
    BOOL TileBasedRenderer;
    BOOL UMA;
    BOOL CacheCoherentUMA;
} D3D12_FEATURE_DATA_ARCHITECTURE;

using System;
using System.Runtime.InteropServices;

[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Unicode)]
public struct D3D12_FEATURE_DATA_ARCHITECTURE
{
    public uint NodeIndex;
    [MarshalAs(UnmanagedType.Bool)] public bool TileBasedRenderer;
    [MarshalAs(UnmanagedType.Bool)] public bool UMA;
    [MarshalAs(UnmanagedType.Bool)] public bool CacheCoherentUMA;
}

Imports System.Runtime.InteropServices

<StructLayout(LayoutKind.Sequential, CharSet:=CharSet.Unicode)>
Public Structure D3D12_FEATURE_DATA_ARCHITECTURE
    Public NodeIndex As UInteger
    <MarshalAs(UnmanagedType.Bool)> Public TileBasedRenderer As Boolean
    <MarshalAs(UnmanagedType.Bool)> Public UMA As Boolean
    <MarshalAs(UnmanagedType.Bool)> Public CacheCoherentUMA As Boolean
End Structure

import ctypes
from ctypes import wintypes

class D3D12_FEATURE_DATA_ARCHITECTURE(ctypes.Structure):
    _fields_ = [
        ("NodeIndex", wintypes.DWORD),
        ("TileBasedRenderer", wintypes.BOOL),
        ("UMA", wintypes.BOOL),
        ("CacheCoherentUMA", wintypes.BOOL),
    ]

#[repr(C)]
pub struct D3D12_FEATURE_DATA_ARCHITECTURE {
    pub NodeIndex: u32,
    pub TileBasedRenderer: i32,
    pub UMA: i32,
    pub CacheCoherentUMA: i32,
}

import "golang.org/x/sys/windows"

type D3D12_FEATURE_DATA_ARCHITECTURE struct {
	NodeIndex uint32
	TileBasedRenderer int32
	UMA int32
	CacheCoherentUMA int32
}

type
  D3D12_FEATURE_DATA_ARCHITECTURE = record
    NodeIndex: DWORD;
    TileBasedRenderer: BOOL;
    UMA: BOOL;
    CacheCoherentUMA: BOOL;
  end;

const D3D12_FEATURE_DATA_ARCHITECTURE = extern struct {
    NodeIndex: u32,
    TileBasedRenderer: i32,
    UMA: i32,
    CacheCoherentUMA: i32,
};

type
  D3D12_FEATURE_DATA_ARCHITECTURE {.bycopy.} = object
    NodeIndex: uint32
    TileBasedRenderer: int32
    UMA: int32
    CacheCoherentUMA: int32

struct D3D12_FEATURE_DATA_ARCHITECTURE
{
    uint NodeIndex;
    int TileBasedRenderer;
    int UMA;
    int CacheCoherentUMA;
}

; HSP3.7/3.8 は構造体機能が無いため、4byte整数の配列変数で操作します。(x64 レイアウト)
; D3D12_FEATURE_DATA_ARCHITECTURE サイズ: 16 バイト(x64)
dim st, 4    ; 4byte整数×4(構造体サイズ 16 / 4 切り上げ)
; NodeIndex : DWORD (+0, 4byte)  st.0 = 値  /  値 = st.0   (lpoke/lpeek も可)
; TileBasedRenderer : BOOL (+4, 4byte)  st.1 = 値  /  値 = st.1   (lpoke/lpeek も可)
; UMA : BOOL (+8, 4byte)  st.2 = 値  /  値 = st.2   (lpoke/lpeek も可)
; CacheCoherentUMA : BOOL (+12, 4byte)  st.3 = 値  /  値 = st.3   (lpoke/lpeek も可)
; ※4byte境界の整数は添字 st.N(N=オフセット/4)で読み書き可。それ以外は peek/poke 系を使用。

; IronHSP は NSTRUCT(構造体)をサポート。32bit/64bit どちらでも同じコードで動作します。
#defstruct global D3D12_FEATURE_DATA_ARCHITECTURE
    #field int NodeIndex
    #field bool TileBasedRenderer
    #field bool UMA
    #field bool CacheCoherentUMA
#endstruct

stdim st, D3D12_FEATURE_DATA_ARCHITECTURE        ; NSTRUCT 変数を確保
st->NodeIndex = 100
mes "NodeIndex=" + st->NodeIndex