Partager via


Optimisations UMA : textures accessibles par le processeur et Swizzle standard

Les GPU UMA (Unified Memory Architecture) offrent des avantages d’efficacité par rapport aux GPU discrets, en particulier lors de l’optimisation pour les appareils mobiles. Accorder l’accès au processeur des ressources lorsque le GPU est UMA peut réduire la quantité de copie qui se produit entre l’UC et le GPU. Même si nous déconseillons les applications d’accorder un accès au processeur à toutes les ressources sur les conceptions UMA, il existe des possibilités d’améliorer l’efficacité en donnant aux ressources appropriées l’accès au processeur. Contrairement aux GPU discrets, l’UC peut techniquement avoir un pointeur vers toutes les ressources auxquelles le GPU peut accéder.

Vue d’ensemble des textures accessibles au processeur

Les textures accessibles au processeur, dans le pipeline graphique, sont une fonctionnalité de l’architecture UMA, ce qui permet aux processeurs d’accéder en lecture et en écriture aux textures. Sur les GPU plus courants, le processeur n’a pas accès aux textures dans le pipeline graphique.

La meilleure pratique générale pour les textures consiste à prendre en charge les GPU discrets, qui impliquent généralement de suivre les processus de chargement des données de texture via des mémoires tampons, résumés comme suit :

  • Il n’y a pas d’accès au processeur pour la majorité des textures.
  • Définition de la disposition de texture sur D3D12_TEXTURE_LAYOUT_UNKNOWN.
  • Chargement des textures sur le GPU avec CopyTextureRegion.

Toutefois, dans certains cas, le processeur et le GPU peuvent interagir si fréquemment sur les mêmes données, que les textures de mappage deviennent utiles pour économiser de l’énergie ou accélérer une conception particulière sur des adaptateurs ou des architectures spécifiques. Les applications doivent détecter ces cas et optimiser les copies inutiles. Dans ce cas, pour de meilleures performances, tenez compte des éléments suivants :

  • Commencez uniquement à divertir les meilleures performances des textures de mappage lorsque D3D12_FEATURE_DATA_ARCHITECTURE ::UMA a la valeur TRUE. Ensuite, faites attention à CacheCoherentUMA si vous choisissez les propriétés du cache du processeur à choisir sur le tas.

  • L’utilisation de l’accès processeur pour les textures est plus complexe que pour les mémoires tampons. Les dispositions de texture les plus efficaces pour les GPU sont rarement row_major. En fait, certaines GPU peuvent uniquement prendre en charge row_major textures lors de la copie des données de texture autour.

  • Les GPU UMA doivent bénéficier universellement d’une optimisation simple pour réduire les temps de chargement au niveau. Après avoir reconnu UMA, l’application peut optimiser l’initial CopyTextureRegion pour remplir les textures que le GPU ne modifiera pas. Au lieu de créer la texture dans un tas avec D3D12_HEAP_TYPE_DEFAULT et de marshaler les données de texture, l’application peut utiliser WriteToSubresource pour éviter de comprendre la disposition de texture réelle.

  • Dans D3D12, les textures créées avec D3D12_TEXTURE_LAYOUT_UNKNOWN et aucun accès au processeur ne sont les plus efficaces pour le rendu et l’échantillonnage fréquents du GPU. Lorsque vous testez les performances, ces textures doivent être comparées aux D3D12_TEXTURE_LAYOUT_UNKNOWN avec l’accès processeur, et D3D12_TEXTURE_LAYOUT_STANDARD_SWIZZLE avec l’accès processeur, et D3D12_TEXTURE_LAYOUT_ROW_MAJOR pour la prise en charge inter-adaptateurs.

  • L’utilisation de D3D12_TEXTURE_LAYOUT_UNKNOWN avec l’accès processeur permet aux méthodes WriteToSubresource, ReadFromSubresource, Map (précluding application access to pointer) et Unmap ; mais peut sacrifier l’efficacité de l’accès GPU.

  • L’utilisation de D3D12_TEXTURE_LAYOUT_STANDARD_SWIZZLE avec l’accès processeur active WriteToSubresource, ReadFromSubresource, Map (qui retourne un pointeur valide à l’application) et Unmap. Il peut également sacrifier l’efficacité de l’accès GPU plus que D3D12_TEXTURE_LAYOUT_UNKNOWN avec l’accès processeur.

Vue d’ensemble de Standard Swizzle

D3D12 (et D3D11.3) introduisent une disposition de données multidimensionnelle standard. Cela permet d’activer plusieurs unités de traitement sur les mêmes données sans copier les données ou basculer les données entre plusieurs dispositions. Une disposition standardisée permet des gains d’efficacité par le biais d’effets réseau et permet aux algorithmes d’effectuer des réductions courtes en supposant un modèle particulier.

Pour obtenir une description détaillée des dispositions de texture, reportez-vous à D3D12_TEXTURE_LAYOUT.

Notez que ce swizzle standard est une fonctionnalité matérielle et peut ne pas être pris en charge par toutes les GPU.

Pour plus d’informations sur le swizzling, reportez-vous à la courbe de l’ordre Z.

API

Contrairement à D3D11.3, D3D12 prend en charge le mappage de texture par défaut. Il n’est donc pas nécessaire d’interroger D3D12_FEATURE_DATA_D3D12_OPTIONS. Toutefois, D3D12 ne prend pas toujours en charge swizzle standard : cette fonctionnalité doit être interrogée avec un appel à CheckFeatureSupport et en vérifiant le champ StandardSwizzle64KBSupported de D3D12_FEATURE_DATA_D3D12_OPTIONS.

Les API suivantes référencent le mappage de texture :

Énumérations

  • D3D12_TEXTURE_LAYOUT : contrôle le modèle swizzle des textures par défaut et active la prise en charge de la carte sur les textures accessibles au processeur.

Structures

  • D3D12_RESOURCE_DESC : décrit une ressource, telle qu’une texture, il s’agit d’une structure largement utilisée.
  • D3D12_HEAP_DESC : décrit un tas.

Méthodes

Les ressources et les tas parents ont des exigences d’alignement :

  • D3D12_DEFAULT_MSAA_RESOURCE_PLACEMENT_ALIGNMENT (4 Mo) pour les textures à plusieurs échantillons.
  • D3D12_DEFAULT_RESOURCE_PLACEMENT_ALIGNMENT (64 Ko) pour des exemples uniques de textures et de mémoires tampons.
  • La copie de sous-source linéaire doit être alignée sur D3D12_TEXTURE_DATA_PLACEMENT_ALIGNMENT (512 octets), avec un pas de ligne aligné sur D3D12_TEXTURE_DATA_PITCH_ALIGNMENT (256 octets).
  • Les vues de mémoire tampon constante doivent être alignées sur D3D12_CONSTANT_BUFFER_DATA_PLACEMENT_ALIGNMENT (256 octets).

Les textures inférieures à 64 Ko doivent être traitées via CreateCommittedResource.

Avec des textures dynamiques (textures qui changent chaque image), le processeur écrit linéairement dans le tas de chargement, suivi d’une opération de copie GPU.

En règle générale, pour créer des ressources dynamiques, créez une mémoire tampon volumineuse dans un tas de chargement (reportez-vous à la sous-allocation dans les mémoires tampons). Pour créer des ressources intermédiaires, créez une mémoire tampon volumineuse dans un tas de lecture différée. Pour créer des ressources statiques par défaut, créez des ressources adjacentes dans un tas par défaut. Pour créer des ressources alias par défaut, créez des ressources qui se chevauchent dans un tas par défaut.

WriteToSubresource et ReadFromSubresource réorganisent les données de texture entre une disposition principale de ligne et une disposition de ressource non définie. L’opération est synchrone. L’application doit donc garder à l’esprit la planification du processeur. L’application peut toujours décomposer la copie dans des régions plus petites ou planifier cette opération dans une autre tâche. Les ressources MSAA et les ressources de gabarit de profondeur avec des dispositions de ressources opaques ne sont pas prises en charge par ces opérations de copie du processeur et entraînent un échec. Les formats qui n’ont pas de taille d’élément power-of-two ne sont pas non plus pris en charge et entraînent également un échec. Les codes de retour hors mémoire peuvent se produire.

Constantes principales

ID3D12Heap

Liaison de ressources