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 quel adaptateur physique de l’appareil est concerné. Consultez Systèmes multiadaptateurs. NodeIndex est rempli par l’application avant l’appel à CheckFeatureSupport, puisque 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 moteur de rendu par tuiles. Le runtime définit ce membre à TRUE si le matériel et le pilote prennent en charge un moteur de 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 à 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 à 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 à TRUE si le GPU respecte les propriétés de table de pages du processeur comme 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 de mémoire ayant ces propriétés de table de pages avec le GPU, car le GPU pourrait déclencher ces propriétés de table de pages de manière inattendue. Par exemple, les opérations d’écriture du GPU pourraient être moins granulaires que ce que l’application prévoit, en particulier les écritures effectuées à partir des nuanceurs. Certaines pages sous surveillance d’écriture pourraient sembler modifiées, même lorsqu’il n’est pas évident de savoir comment les écritures du GPU ont pu les affecter. Les opérations du 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 parfois 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 de GPU en gérant uniquement la résidence des ressources dans les tas D3D12_HEAP_TYPE_DEFAULT. Ces applications n’ont qu’à 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 discrets et assumer 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 celle des textures par défaut, une utilisation de la mémoire presque doublée est possible. 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 souhaitent 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. Cependant, la propriété UMA, à elle seule, englobe une zone grise relativement vague de conceptions de 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. Il existe une propriété qui 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 couramment avantage des trois attributions de tas. Il existe des occasions 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. Toutefois, ces occasions ne sont pas toujours évidentes. Les applications doivent donc faire preuve de prudence; il est conseillé d’expérimenter sur divers systèmes « UMA », car il peut être justifié d’activer ou d’exclure certains ID d’appareil. Une compréhension de l’architecture de mémoire du GPU et de la façon dont les types de tas se traduisent en propriétés de cache est recommandée. Les chances de réussite 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 restent en mode d’écriture combinée (write-combine). Toutefois, certains adaptateurs UMA tirent avantage à la fois des propriétés sans accès au processeur et d’écriture combinée des tas par défaut et de chargement. Consultez GetCustomHeapProperties pour plus de détails. Lorsque CacheCoherentUMA est true, les applications peuvent envisager plus sérieusement d’abandonner l’attribution des tas et d’utiliser partout l’équivalent en tas personnalisé des tas de chargement. Les optimisations UMA sans copie, comme celles offertes par WriteToSubresource, sont plus généralement encouragées, car davantage de scénarios tireront simplement avantage 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 limites peuvent encore exister où les avantages ne sont pas facilement obtenus, 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 de 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 fait en mode d’écriture différée (write-back) sur CacheCoherentUMA. Pour ces architectures, l’utilisation de l’écriture combinée sur les tas de chargement est couramment préjudiciable. Les détails de bas niveau devraient être ignorés par la grande majorité des applications à adaptateur unique. Comme d’habitude, les applications à adaptateur unique peuvent simplifier le portrait et s’assurer que les écritures du processeur dans les tas de chargement utilisent des modèles compatibles avec l’écriture combinée. 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 de l’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