structure D3D12_FEATURE_DATA_ARCHITECTURE1 (d3d12.h)
Fournit des détails sur les détails architecturaux de chaque adaptateur, afin que votre application puisse mieux optimiser certaines propriétés de l’adaptateur.
Syntaxe
typedef struct D3D12_FEATURE_DATA_ARCHITECTURE1 {
UINT NodeIndex;
BOOL TileBasedRenderer;
BOOL UMA;
BOOL CacheCoherentUMA;
BOOL IsolatedMMU;
} D3D12_FEATURE_DATA_ARCHITECTURE1;
Membres
NodeIndex
Dans l’opération multi-adaptateur, cela indique quelle carte physique de l’appareil est pertinente. 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 renderer basé sur des vignettes. Le runtime définit ce membre sur TRUE si le matériel et le pilote prennent en charge un renderer 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 avec le cache. Le runtime définit ce membre sur TRUE si le matériel et le pilote prennent en charge l’UMA cohérente avec le cache.
IsolatedMMU
SAL: Out
Spécifie si le matériel et le pilote prennent en charge l’unité de gestion de mémoire isolée (MMU). Le runtime définit ce membre sur TRUE si le GPU respecte les propriétés de la table de pages processeur telles que MEM_WRITE_WATCH (pour plus d’informations, voir VirtualAlloc) et PAGE_READONLY (pour plus d’informations, voir constantes de protection de la mémoire).
Si TRUE, l’application doit s’occuper de ne pas utiliser de mémoire avec ces propriétés de table de pages avec le GPU, car le GPU peut déclencher ces propriétés de table de pages de manière inattendue. Par exemple, les opérations d’écriture GPU peuvent être plus grossières que prévu par l’application, en particulier les écritures à partir de nuanceurs. Certaines pages d’écriture-espion peuvent sembler incorrectes, même si ce n’est pas évident comment les écritures GPU peuvent les avoir affectées. Les opérations GPU associées aux scénarios d’utilisation du tas de chargement et de lecture différée fonctionnent bien avec les pages d’écriture-espion, mais peuvent parfois générer de faux positifs qui peuvent être ignorés en toute sécurité.
Remarques
Comment utiliser UMA et CacheCoherentUMA
Les applications D3D12 doivent être préoccupés par la gestion de la résidence de mémoire et 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 que D3D12_HEAP_TYPE_UPLOAD et 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 poussent les limites. Par conséquent, D3D12_FEATURE_DATA_ARCHITECTURE aide les applications à optimiser mieux les propriétés de l’adaptateur sous-jacent.
Certaines applications souhaitent peut-être mieux optimiser les adaptateurs discrets et prendre en compte 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 détecter deux budgets de résidence ou reconnaître UMA est faux.
Certaines applications souhaitent peut-être mieux optimiser les adaptateurs intégrés/UMA, en particulier ceux qui s’intéressent à l’extension de la durée de vie de la batterie sur un appareil mobile. Les applications D3D12 simples sont forcées à copier des données entre des tas avec différentes attributions, quand elles ne sont pas toujours nécessaires sur UMA. Toutefois, la propriété UMA, par lui-même, englobe une zone grise raisonnablement vague de conceptions GPU. Ne supposez pas que l’UMA signifie que toute la mémoire accessible par GPU peut être librement rendue accessible au processeur, car elle ne l’est pas. Il existe une propriété qui s’aligne plus étroitement sur ce type de pensée : CacheCoherentUMA.
Lorsque CacheCoherentUMA est faux, un budget de résidence unique est disponible, mais la conception UMA bénéficie généralement des trois attributions de tas. Les opportunités existent pour supprimer la copie des 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. Ces opportunités ne sont pas clairement coupées, cependant. Par conséquent, les applications doivent être prudentes ; et l’expérimentation sur un large éventail de systèmes « UMA » est conseillée, car il est conseillé de recourir à l’activation ou à la précédation de certains ID d’appareil. Une compréhension de l’architecture de mémoire GPU et de la façon dont les types de tas se traduisent en propriétés de cache est recommandée. La faisabilité du succès dépend probablement de la fréquence à laquelle chaque processeur lit ou écrit les données, la taille et la localité des accès aux données, etc. Pour les développeurs avancés : lorsque UMA a la valeur true et CacheCoherentUMA est faux, 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 au processeur et de combinaison d’écriture des segments de mémoire par défaut et de chargement. Pour plus d’informations, consultez GetCustomHeapProperties.
Lorsque cacheCoherentUMA est vrai, les applications peuvent plus fortement divertir l’abandon de l’attribution des tas et l’utilisation de l’équivalent de tas personnalisé des tas de chargement partout. Les optimisations UMA de copie zéro telles que celles offertes par WriteToSubresource 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é significative des caches de la hiérarchie de mémoire sont également unifiées ou intégrées entre l’UC et le GPU. La caractéristique observable la plus unique est que les tas de chargement sont réellement réécrits sur CacheCoherentUMA. Pour cette architecture, l’utilisation de la combinaison d’écritures sur les tas de chargement est généralement un détriment.
Les détails de bas niveau doivent être ignorés par une grande majorité d’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 aident à renforcer les concepts des applications multi-adaptateurs. Les applications multi-adaptateurs doivent probablement comprendre les propriétés de l’architecture de l’adaptateur suffisamment bien pour choisir les propriétés de tas personnalisées optimales pour déplacer efficacement les données entre les adaptateurs.
Exigences
| Exigence | Valeur |
|---|---|
| d’en-tête | d3d12.h |