Partager via

Résidence

  • Article

Un objet est considéré comme résident lorsqu’il est accessible par le GPU.

Budget de résidence

Les GPU ne prennent pas encore en charge les erreurs de page. Les applications doivent donc valider les données dans la mémoire physique pendant que le GPU peut y accéder. Ce processus est appelé « rendre quelque chose de résident » et doit être effectué à la fois pour la mémoire système physique et la mémoire vidéo discrète physique. Dans D3D12, la plupart des objets API encapsulent une certaine quantité de mémoire accessible par GPU. Cette mémoire accessible par GPU est rendue résidente lors de la création de l’objet API et supprimée lors de la destruction de l’objet API.

La quantité de mémoire physique disponible pour le processus est appelée budget de mémoire vidéo. Le budget peut varier sensiblement à mesure que les processus de veille et de veille en arrière-plan sont en cours de veille; et fluctuent considérablement lorsque l’utilisateur passe à une autre application. L’application peut être avertie lorsque le budget change et interroger le budget actuel et la quantité de mémoire actuellement consommée. Si une application ne reste pas dans son budget, le processus est figé par intermittence pour permettre à d’autres applications de s’exécuter et/ou les API de création retournent un échec. L’interface IDXGIAdapter3 fournit les méthodes relatives à cette fonctionnalité, en particulier QueryVideoMemoryInfo et RegisterVideoMemoryBudgetChangeNotificationEvent.

Les applications sont encouragées à utiliser une réservation pour indiquer la quantité de mémoire dont elles ne peuvent pas se passer. Dans l’idéal, les paramètres graphiques « faibles » spécifiés par l’utilisateur, ou quelque chose d’encore plus faible, sont la valeur appropriée pour une telle réservation. La définition d’une réservation ne donne jamais à une application un budget supérieur à celui qu’elle reçoit normalement. Au lieu de cela, les informations de réservation aident le noyau du système d’exploitation à réduire rapidement l’impact des situations de forte sollicitation de la mémoire. Même la réservation n’est pas garantie d’être disponible pour l’application lorsque l’application n’est pas l’application de premier plan.

Ressources de tas

Alors que de nombreux objets API encapsulent une partie de la mémoire accessible par GPU, les ressources de tas sont censées & être la façon la plus significative dont les applications consomment et gèrent la mémoire physique. Un tas étant l’unité de niveau le plus bas pour gérer la mémoire physique, il est bon d’avoir une certaine connaissance de ses propriétés de résidence.

  • Les tas ne peuvent pas être partiellement résidents, mais des solutions de contournement existent avec des ressources réservées.
  • Les tas doivent être budgétés dans le cadre d’un pool particulier. Les adaptateurs UMA ont un pool, tandis que les adaptateurs discrets ont deux pools. S’il est vrai que le noyau peut déplacer certains tas sur des adaptateurs discrets de la mémoire vidéo vers la mémoire système, il ne le fait qu’en dernier recours extrême. Les applications ne doivent pas s’appuyer sur le comportement de sur-budget du noyau et doivent se concentrer sur une bonne gestion budgétaire à la place.
  • Les tas peuvent être supprimés de la résidence, ce qui permet de paginer leur contenu sur le disque. Toutefois, la destruction des tas est une technique plus fiable pour libérer la résidence sur toutes les architectures d’adaptateur. Sur les adaptateurs où le champMaxGPUVirtualAddressBitsPerProcess de D3D12_FEATURE_DATA_GPU_VIRTUAL_ADDRESS_SUPPORT est proche de la taille du budget, Evict ne récupère pas de façon fiable la résidence.
  • La création du tas peut être lente ; mais il est optimisé pour le traitement des threads d’arrière-plan. Il est recommandé de créer des tas sur des threads d’arrière-plan pour éviter les glitchings du thread de rendu. Dans D3D12, plusieurs threads peuvent appeler simultanément des routines de création en toute sécurité.

D3D12 introduit plus de flexibilité et d’orthogonalité dans son modèle de ressource afin d’offrir davantage d’options pour les applications. Il existe trois types généraux de ressources dans D3D12 : validés, placés et réservés.

  • Les ressources validées créent une ressource et un tas en même temps. Le tas est implicite et n’est pas accessible directement. Le tas est correctement dimensionné pour localiser l’intégralité de la ressource dans le tas.
  • Les ressources placées permettent de placer une ressource à un décalage différent de zéro dans un tas. Les décalages doivent généralement être alignés sur 64 Ko ; mais certaines exceptions existent dans les deux sens. Les ressources MSAA nécessitent un alignement de décalage de 4 Mo et un alignement de décalage de 4 Ko est disponible pour les petites textures. Les ressources placées ne peuvent pas être déplacées ou relocalisées directement vers un autre tas ; mais ils permettent un déplacement simple des données de ressource entre les segments de mémoire. Après avoir créé une ressource placée dans un autre tas et copié les données de ressource, de nouveaux descripteurs de ressources devront être utilisés pour le nouvel emplacement de données de ressource.
  • Les ressources réservées sont disponibles uniquement lorsque l’adaptateur prend en charge les ressources en mosaïques de niveau 1 ou supérieur. Lorsqu’elles sont disponibles, elles offrent les techniques de gestion des résidences les plus avancées disponibles; mais tous les adaptateurs ne les prennent pas en charge actuellement. Ils permettent de remapper une ressource sans nécessiter la régénération des descripteurs de ressources, la résidence partielle au niveau mip et les scénarios de texture éparses, etc. Tous les types de ressources ne sont pas pris en charge même lorsque des ressources réservées sont disponibles, de sorte qu’un gestionnaire de résidence basé sur une page entièrement général n’est pas encore possible.

Priorités de résidence

La Windows 10 Creators Update permet aux développeurs d’influencer les tas et les ressources qui seront préférés pour rester résidents lorsque la pression de la mémoire nécessite que certaines de ses ressources soient rétrogradées. Cela aide les développeurs à créer des applications plus performantes en tirant parti des connaissances que le runtime ne peut pas déduire de l’utilisation de l’API. Il s’attendait à ce que les développeurs deviennent plus à l’aise et capables de spécifier des priorités à mesure qu’ils passent de l’utilisation des ressources validées aux ressources réévérées et en mosaïques.

L’application de ces priorités doit être plus facile que la gestion de deux budgets de mémoire dynamique, la rétrogradation manuelle et la promotion des ressources, car les applications peuvent déjà le faire. Par conséquent, la conception de l’API de priorité de résidence est affinée avec des priorités par défaut raisonnables affectées à chaque tas ou ressource au fur et à mesure de sa création. Pour plus d’informations, consultez ID3D12Device1::SetResidencyPriority et l’énumération D3D12_RESIDENCY_PRIORITY .

Avec les priorités, les développeurs sont censés :

  • Augmentez la priorité de quelques tas exceptionnels pour mieux atténuer l’impact sur les performances de ces tas rétrogradés plus tôt ou plus fréquemment que leurs modèles d’accès naturels. Cette approche devrait être exploitée par les applications transférées à partir d’API graphiques telles que Direct3D 11 ou OpenGL, dont le modèle de gestion des ressources est sensiblement différent de celui de Direct3D 12.
  • Remplacez presque toutes les priorités de tas avec le propre schéma de compartimentage de l’application, soit fixe, basé sur les connaissances du programmeur sur la fréquence d’accès, soit dynamique ; Un schéma fixe est plus simple à gérer qu’un schéma dynamique, mais peut être moins efficace et nécessiter une intervention du programmeur à mesure que les modèles d’utilisation changent au cours du développement. Cette approche devrait être exploitée par les applications créées avec la gestion des ressources de style Direct3D 12 à l’esprit, telles que celles qui utilisent la bibliothèque de résidence (en particulier les schémas dynamiques).

Algorithme de priorité par défaut

Une application ne peut pas spécifier de priorités utiles pour un tas qu’elle tente de gérer sans avoir d’abord sous-stanné l’algorithme de priorité par défaut. En effet, la valeur de l’affectation d’une priorité particulière à un tas est dérivée de sa priorité relative à d’autres tas hiérarchisés qui sont en concurrence pour la même mémoire.

La stratégie choisie pour générer des priorités par défaut consiste à catégoriser les tas en deux compartiments, en favorisant (donnant une priorité plus élevée aux tas) qui sont supposés être écrits fréquemment par le GPU sur les tas qui ne le sont pas.

Le compartiment à priorité élevée contient des tas et des ressources créés avec des indicateurs qui les identifient en tant que cibles de rendu, mémoires tampons de gabarit de profondeur ou vues d’accès non ordonnées (UAV). Ces valeurs de priorité sont affectées dans la plage à partir de D3D12_RESIDENCY_PRIORITY_HIGH ; pour hiérarchiser davantage parmi ces tas et ressources, les 16 bits les plus bas de la priorité sont définis sur la taille du tas ou de la ressource divisée par 10 Mo (saturation en 0xFFFF pour les tas extrêmement volumineux). Cette hiérarchisation supplémentaire favorise les tas et les ressources plus grands.

Le compartiment basse priorité contient tous les autres tas et ressources, auxquels une valeur de priorité de D3D12_RESIDENCY_PRIORITY_NORMAL est affectée. Aucune autre hiérarchisation n’est tentée parmi ces tas et ressources.

Gestion des résidences de programmation

Les applications simples peuvent être en mesure d’obtenir en créant simplement des ressources validées jusqu’à ce qu’elles rencontrent des défaillances de mémoire insuffisante. En cas d’échec, l’application peut détruire d’autres ressources validées ou objets API pour permettre à d’autres créations de ressources de réussir. Toutefois, même les applications simples sont fortement recommandées pour watch pour les modifications budgétaires négatives et détruire les objets API inutilisés à peu près une fois par image.

La complexité d’une conception de gestion des résidences va monter en puissance lorsque vous essayez d’optimiser pour les architectures d’adaptateurs ou d’incorporer des priorités de résidence. La budgétisation et la gestion discrètes de deux pools de mémoire discrète seront plus complexes que la gestion d’un seul, et l’affectation de priorités fixes à grande échelle peut devenir une charge de maintenance si les modèles d’utilisation évoluent. Le dépassement de textures dans la mémoire système ajoute plus de complexité, car une ressource incorrecte dans la mémoire système peut avoir un impact important sur la fréquence d’images. De plus, il n’existe aucune fonctionnalité simple permettant d’identifier les ressources qui bénéficieraient d’une bande passante GPU plus élevée ou qui toléreraient une bande passante GPU inférieure.

Des conceptions encore plus complexes interrogeront les fonctionnalités de l’adaptateur actuel. Ces informations sont disponibles dans D3D12_FEATURE_DATA_GPU_VIRTUAL_ADDRESS_SUPPORT, D3D12_FEATURE_DATA_ARCHITECTURE, D3D12_TILED_RESOURCES_TIER et D3D12_RESOURCE_HEAP_TIER.

Plusieurs parties d’une application seront probablement utilisées à l’aide de différentes techniques. Par exemple, certaines textures volumineuses et les chemins de code rarement exercés peuvent utiliser des ressources validées, tandis que de nombreuses textures peuvent être désignées avec une propriété de diffusion en continu et utiliser une technique générale de ressource placée.

ID3D12Heap

Gestion de la mémoire