D3D12_FEATURE_DATA_ARCHITECTURE structure (d3d12.h)

Fournit des détails sur l’architecture de l’adaptateur, afin que votre application puisse mieux optimiser certaines propriétés de l’adaptateur.

Note Cette structure a été remplacée par la structure D3D12_FEATURE_DATA_ARCHITECTURE1 . Si votre application cible Windows 10, la version 1703 (Creators' Update) ou ultérieure, utilisez D3D12_FEATURE_DATA_ARCHITECTURE1 (et D3D12_FEATURE_ARCHITECTURE1) à la place.

 

Syntaxe

typedef struct D3D12_FEATURE_DATA_ARCHITECTURE {
  UINT NodeIndex;
  BOOL TileBasedRenderer;
  BOOL UMA;
  BOOL CacheCoherentUMA;
} D3D12_FEATURE_DATA_ARCHITECTURE;

Membres

NodeIndex

Dans l’opération multi-adaptateur, cela indique l’adaptateur physique de l’appareil qui est pertinent. Consultez Systèmes multi-adaptateurs. NodeIndex est rempli par l’application avant d’appeler CheckFeatureSupport, car l’application peut récupérer des détails sur l’architecture de chaque adaptateur.

TileBasedRenderer

Spécifie si le matériel et le pilote prennent en charge un convertisseur basé sur des vignettes. Le runtime définit ce membre sur TRUE si le matériel et le pilote prennent en charge un convertisseur basé sur des vignettes.

UMA

Spécifie si le matériel et le pilote prennent en charge UMA. Le runtime définit ce membre sur TRUE si le matériel et le pilote prennent en charge UMA.

CacheCoherentUMA

Spécifie si le matériel et le pilote prennent en charge l’UMA cohérente du cache. Le runtime définit ce membre sur TRUE si le matériel et le pilote prennent en charge l’UMA cohérente dans le cache.

Remarques

Comment utiliser UMA et CacheCoherentUMA

Les applications D3D12 doivent se préoccuper de la gestion de la résidence de la mémoire et de la fourniture des propriétés de tas optimales. Les applications D3D12 peuvent rester simplifiées et s’exécuter raisonnablement bien sur de nombreuses architectures GPU en gérant uniquement la résidence des ressources dans D3D12_HEAP_TYPE_DEFAULT tas. Ces applications doivent uniquement appeler IDXGIAdapter3 ::QueryVideoMemoryInfo pour DXGI_MEMORY_SEGMENT_GROUP_LOCAL, et elles doivent être tolérantes à ce que les D3D12_HEAP_TYPE_UPLOAD et les D3D12_HEAP_TYPE_READBACK proviennent de ce même groupe de segments de mémoire.

Toutefois, une conception aussi simple est trop contraignante pour les applications qui repoussent les limites. Ainsi, D3D12_FEATURE_DATA_ARCHITECTURE permet aux applications de mieux optimiser les propriétés de l’adaptateur sous-jacent.

Certaines applications peuvent souhaiter optimiser les adaptateurs discrets et prendre en charge la complexité supplémentaire de la gestion des budgets de mémoire système et de mémoire vidéo. Si la taille des tas de chargement rivalise avec la taille des textures par défaut, un quasi doublement de l’utilisation de la mémoire est disponible. Lors de la prise en charge de ces optimisations, une application peut soit détecter deux budgets de résidence, soit reconnaître que l’UMA est false.

Certaines applications souhaitent peut-être mieux optimiser les adaptateurs intégrés/UMA, en particulier ceux qui souhaitent prolonger l’autonomie de la batterie sur un appareil mobile. Les applications D3D12 simples sont forcées de copier des données entre des tas avec des attributions différentes, quand cela n’est pas toujours nécessaire sur UMA. Toutefois, la propriété UMA, à elle seule, englobe une zone grise relativement vague de conceptions GPU. Ne partez pas du principe que l’UMA signifie que toute la mémoire accessible par GPU peut être librement rendue accessible au processeur, car ce n’est pas le cas. Il existe une propriété qui s’aligne plus étroitement sur ce type de pensée : CacheCoherentUMA.

Lorsque CacheCoherentUMA a la valeur false, un seul budget de résidence est disponible, mais la conception UMA bénéficie généralement des trois attributions de tas. Il existe des possibilités de supprimer la copie de ressources par le biais d’une utilisation judicieuse des ressources de chargement et de lecture différée et des tas, qui fournissent un accès processeur à la mémoire. De telles possibilités ne sont cependant pas claires. Par conséquent, les applications doivent être prudentes ; et l’expérimentation sur une variété de systèmes « UMA » est recommandée, car le recours à l’activation ou à l’exception de certains ID d’appareil peut être justifié. Il est recommandé de comprendre l’architecture de la mémoire GPU et la façon dont les types de tas se traduisent en propriétés de cache. La faisabilité de la réussite dépend probablement de la fréquence à laquelle chaque processeur lit ou écrit les données, de la taille et de la localité des accès aux données, etc. Pour les développeurs avancés : quand UMA a la valeur true et Que CacheCoherentUMA a la valeur false, la caractéristique la plus unique pour ces adaptateurs est que les tas de chargement sont toujours combinés en écriture. Toutefois, certains adaptateurs UMA bénéficient à la fois des propriétés sans accès processeur et écriture-combinaison des tas par défaut et de chargement. Pour plus d’informations, consultez GetCustomHeapProperties .

Lorsque CacheCoherentUMA est vrai, les applications peuvent plus fortement envisager d’abandonner l’attribution des tas et d’utiliser l’équivalent de tas personnalisé de tas de chargement partout. Les optimisations UMA de copie zéro sont plus généralement encouragées, car d’autres scénarios tirent simplement parti de l’utilisation partagée. Le modèle de mémoire est très propice à davantage de scénarios et à une adoption plus large. Certains cas de coin peuvent encore exister où les avantages ne sont pas facilement obtenus, mais ils devraient être beaucoup plus rares et moins préjudiciables que d’autres options. Pour les développeurs avancés : CacheCoherentUMA signifie qu’une quantité importante des caches dans la hiérarchie de mémoire sont également unifiés ou intégrés entre le processeur et le GPU. La caractéristique observable la plus unique est que les tas de chargement sont en fait en écriture différée sur CacheCoherentUMA. Pour ces architectures, l’utilisation de la combinaison d’écritures sur les tas de chargement est généralement un inconvénient.

Les détails de bas niveau doivent être ignorés par une grande majorité des applications à adaptateur unique. Comme d’habitude, les applications à adaptateur unique peuvent simplifier le paysage et s’assurer que les écritures du processeur pour charger des tas utilisent des modèles compatibles avec l’écriture combinée. Les détails de niveau inférieur renforcent les concepts des applications multi-adaptateurs. Les applications multi-adaptateurs doivent probablement comprendre suffisamment bien les propriétés de l’architecture de l’adaptateur pour choisir les propriétés de tas personnalisées optimales pour déplacer efficacement les données entre les adaptateurs.

Configuration requise

Condition requise	Valeur
En-tête	d3d12.h

Voir aussi

Structures principales

D3D12_FEATURE