Remarque Cette structure, introduite dans Windows 10, version 1703 (Creators Update), remplace la structure D3D12_FEATURE_DATA_ARCHITECTURE. Si votre application cible Windows 10, version 1703 (Creators Update) ou ultérieure, utilisez D3D12_FEATURE_DATA_ARCHITECTURE1 (et D3D12_FEATURE_ARCHITECTURE1).
Syntaxe
Membres
NodeIndexType : UINT Dans un fonctionnement multiadaptateur, indique l’adaptateur physique de l’appareil concerné. Consultez Systèmes multiadaptateurs. NodeIndex est renseigné par l’application avant l’appel à CheckFeatureSupport, car l’application peut récupérer des détails sur l’architecture de chaque adaptateur. TileBasedRenderer
Type : BOOL Spécifie si le matériel et le pilote prennent en charge un rendu par tuiles. Le runtime définit ce membre sur TRUE si le matériel et le pilote prennent en charge un rendu par tuiles. UMA
Type : BOOL 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
Type : BOOL Spécifie si le matériel et le pilote prennent en charge UMA avec cohérence de cache. Le runtime définit ce membre sur TRUE si le matériel et le pilote prennent en charge UMA avec cohérence de cache. IsolatedMMU
Type : BOOL SAL :
Out
Spécifie si le matériel et le pilote prennent en charge une unité de gestion de la mémoire (MMU) isolée.
Le runtime définit ce membre sur TRUE si le GPU respecte les propriétés de la table des pages du processeur, telles que MEM_WRITE_WATCH (pour plus d’informations, consultez VirtualAlloc) et PAGE_READONLY (pour plus d’informations, consultez Constantes de protection de la mémoire).
Si la valeur est TRUE, l’application doit veiller à ne pas utiliser avec le GPU de la mémoire dotée de ces propriétés de table des pages, car le GPU pourrait déclencher ces propriétés de manière inattendue. Par exemple, les opérations d’écriture du GPU peuvent être plus grossières que ce que l’application attend, en particulier les écritures effectuées depuis les nuanceurs. Certaines pages sous surveillance d’écriture peuvent sembler modifiées, même lorsqu’on ne voit pas clairement comment les écritures du GPU ont pu les affecter. Les opérations GPU associées aux scénarios d’utilisation des tas de chargement et de relecture fonctionnent bien avec les pages sous surveillance d’écriture, mais peuvent occasionnellement générer des faux positifs qui peuvent être ignorés sans risque.
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 simples et fonctionner raisonnablement bien sur de nombreuses architectures GPU en gérant uniquement la résidence des ressources dans les tas D3D12_HEAP_TYPE_DEFAULT. Ces applications doivent uniquement appeler IDXGIAdapter3::QueryVideoMemoryInfo pour DXGI_MEMORY_SEGMENT_GROUP_LOCAL, et elles doivent tolérer 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 repoussent les limites. Ainsi, D3D12_FEATURE_DATA_ARCHITECTURE aide les applications à mieux s’optimiser pour les propriétés de l’adaptateur sous-jacent. Certaines applications peuvent vouloir mieux s’optimiser pour les adaptateurs dédiés et assumer la complexité supplémentaire liée à la gestion des budgets de mémoire système et de mémoire vidéo. Si la taille des tas de chargement rivalise avec celle des textures par défaut, l’utilisation de la mémoire peut presque doubler. Pour prendre en charge de telles optimisations, une application peut soit détecter deux budgets de résidence, soit reconnaître que UMA est false. Certaines applications peuvent vouloir mieux s’optimiser pour les adaptateurs intégrés/UMA, en particulier celles qui cherchent à prolonger l’autonomie de la batterie sur les appareils mobiles. Les applications D3D12 simples sont contraintes de copier des données entre des tas ayant des attributions différentes, alors que ce 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 supposez pas qu’UMA signifie que toute la mémoire accessible par le GPU peut être librement rendue accessible par le processeur, car ce n’est pas le cas. Une propriété correspond plus étroitement à ce type de raisonnement : CacheCoherentUMA. Lorsque CacheCoherentUMA est false, un seul budget de résidence est disponible, mais la conception UMA tire généralement parti des trois attributions de tas. Il existe des possibilités d’éliminer la copie de ressources grâce à une utilisation judicieuse des ressources et des tas de chargement et de relecture, qui fournissent au processeur un accès à la mémoire. Ces possibilités ne sont toutefois pas évidentes. Les applications doivent donc faire preuve de prudence ; il est conseillé d’expérimenter sur divers systèmes « UMA », car il peut s’avérer justifié d’activer ou d’exclure certains ID d’appareil. Il est recommandé de comprendre l’architecture mémoire du GPU et la manière dont les types de tas se traduisent en propriétés de cache. Les chances de succès dépendent 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 : lorsque UMA est true et que CacheCoherentUMA est false, la caractéristique la plus distinctive de ces adaptateurs est que les tas de chargement utilisent toujours la combinaison d’écritures (write-combine). Toutefois, certains adaptateurs UMA tirent parti à la fois des propriétés sans accès processeur et de combinaison d’écritures des tas par défaut et de chargement. Pour plus de détails, consultez GetCustomHeapProperties. Lorsque CacheCoherentUMA est true, les applications peuvent plus sérieusement envisager d’abandonner l’attribution des tas et d’utiliser partout l’équivalent en tas personnalisé des tas de chargement. Les optimisations UMA sans copie, telles que celles offertes par WriteToSubresource, sont plus généralement encouragées, car davantage de scénarios tireront simplement parti de l’utilisation partagée. Le modèle de mémoire se prête très bien à davantage de scénarios et à une adoption plus large. Certains cas particuliers peuvent encore exister dans lesquels les avantages ne sont pas faciles à obtenir, mais ils devraient être beaucoup plus rares et moins préjudiciables que les autres options. Pour les développeurs avancés : CacheCoherentUMA signifie qu’une part importante des caches de la hiérarchie mémoire est également unifiée ou intégrée entre le processeur et le GPU. La caractéristique observable la plus distinctive est que les tas de chargement sont en réalité en écriture différée (write-back) sur CacheCoherentUMA. Pour ces architectures, l’utilisation de la combinaison d’écritures sur les tas de chargement est généralement préjudiciable. Les détails de bas niveau peuvent être ignorés par la grande majorité des applications à adaptateur unique. Comme d’habitude, les applications à adaptateur unique peuvent simplifier les choses et s’assurer que les écritures du processeur dans les tas de chargement utilisent des modèles compatibles avec la combinaison d’écritures. Les détails de plus bas niveau aident à renforcer les concepts pour les applications multiadaptateurs. Les applications multiadaptateurs doivent probablement comprendre suffisamment bien les propriétés d’architecture des adaptateurs pour choisir les propriétés de tas personnalisé optimales afin de déplacer efficacement les données entre les adaptateurs.Configuration requise
En-tête : d3d12_xs.h ou d3d12_x.hBibliothèque : d3d12_xs.lib ou d3d12_x.lib
Plateformes prises en charge : consoles XBOX Series et famille XBOX One