D3D12_FEATURE_DATA_ARCHITECTURE1

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

UMA と CacheCoherentUMA の使用方法

D3D12 アプリケーションは、メモリの常駐管理と最適なヒープ プロパティの指定に注意を払う必要があります。 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 の場合、アプリケーションはヒープに属性を割り当てるという考え方を捨て、あらゆる場所でアップロード ヒープ相当のカスタム ヒープを使用することを、より積極的に検討できます。 WriteToSubresource が提供するようなゼロコピーの UMA 最適化は、より多くのシナリオが共有使用の恩恵を受けるため、一般により強く推奨されます。 このメモリ モデルは、より多くのシナリオとより幅広い採用に非常に適しています。 利点が容易に得られないコーナー ケースが依然として存在する可能性はありますが、他の選択肢と比べればはるかにまれであり、悪影響も小さいはずです。 上級開発者向け: CacheCoherentUMA は、メモリ階層内のキャッシュのかなりの部分が CPU と GPU の間で統合または一体化されていることを意味します。 最も特徴的で観察しやすい点は、CacheCoherentUMA ではアップロード ヒープが実際にはライトバックであることです。 これらのアーキテクチャでは、アップロード ヒープにライトコンバインを使用することは一般に不利になります。

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

#include <windows.h>

// D3D12_FEATURE_DATA_ARCHITECTURE1  (x64 20 / x86 20 バイト)
typedef struct D3D12_FEATURE_DATA_ARCHITECTURE1 {
    DWORD NodeIndex;
    BOOL TileBasedRenderer;
    BOOL UMA;
    BOOL CacheCoherentUMA;
    BOOL IsolatedMMU;
} D3D12_FEATURE_DATA_ARCHITECTURE1;

using System;
using System.Runtime.InteropServices;

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

Imports System.Runtime.InteropServices

<StructLayout(LayoutKind.Sequential, CharSet:=CharSet.Unicode)>
Public Structure D3D12_FEATURE_DATA_ARCHITECTURE1
    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
    <MarshalAs(UnmanagedType.Bool)> Public IsolatedMMU As Boolean
End Structure

import ctypes
from ctypes import wintypes

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

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

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

type D3D12_FEATURE_DATA_ARCHITECTURE1 struct {
	NodeIndex uint32
	TileBasedRenderer int32
	UMA int32
	CacheCoherentUMA int32
	IsolatedMMU int32
}

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

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

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

struct D3D12_FEATURE_DATA_ARCHITECTURE1
{
    uint NodeIndex;
    int TileBasedRenderer;
    int UMA;
    int CacheCoherentUMA;
    int IsolatedMMU;
}

; HSP3.7/3.8 は構造体機能が無いため、4byte整数の配列変数で操作します。(x64 レイアウト)
; D3D12_FEATURE_DATA_ARCHITECTURE1 サイズ: 20 バイト(x64)
dim st, 5    ; 4byte整数×5(構造体サイズ 20 / 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 も可)
; IsolatedMMU : BOOL (+16, 4byte)  st.4 = 値  /  値 = st.4   (lpoke/lpeek も可)
; ※4byte境界の整数は添字 st.N(N=オフセット/4)で読み書き可。それ以外は peek/poke 系を使用。

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

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