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 des données en mémoire physique pendant que le GPU peut y accéder. Ce processus est appelé « création d’un élément résident » et doit être effectué 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 quantité de mémoire accessible par GPU. Cette mémoire accessible par GPU est rendue résidente pendant 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 mémoire vidéo. Le budget peut varier sensiblement à mesure que les processus en arrière-plan se réveillent et veillent ; et varie considérablement lorsque l’utilisateur bascule vers une autre application. L’application peut être avertie lorsque le budget change et interroge à la fois le budget actuel et la quantité de mémoire actuellement consommée. Si une application ne reste pas dans son budget, le processus est gelé par intermittence pour permettre à d’autres applications d’exécuter et/ou les API de création retournent un échec. L’interface IDXGIAdapter3 fournit les méthodes relatives à cette fonctionnalité, notamment QueryVideoMemoryInfo et RegisterVideoMemoryBudgetChangeNotificationEvent.

Les applications sont encouragées à utiliser une réservation pour indiquer la quantité de mémoire qu’elles ne peuvent pas utiliser. Dans l’idéal, les paramètres graphiques « bas » spécifiés par l’utilisateur, ou quelque chose d’encore plus bas, sont la valeur appropriée pour une telle réservation. La définition d’une réservation ne donnera jamais à une application un budget supérieur à celui qu’elle recevrait 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 pression de mémoire volumineuses. Même la réservation n’est pas garantie d’être disponible pour l’application lorsque l’application n’est pas au premier plan de l’application.

Ressources de tas

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

  • Les tas ne peuvent pas être partiellement résidents, mais les 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. Bien qu’il soit 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 que comme un dernier recours extrême. Les applications ne doivent pas s’appuyer sur le comportement trop budgétaire 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 à leur contenu d’être paginé sur disque. Mais la destruction des tas est une technique plus fiable pour libérer la résidence sur toutes les architectures d’adaptateurs. Sur les adaptateurs où le champ MaxGPUVirtualAddressBitsPerProcess D3D12_FEATURE_DATA_GPU_VIRTUAL_ADDRESS_SUPPORT est proche de la taille du budget, evict ne récupérera pas de manière fiable la résidence.
  • La création de 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 afin d’éviter de faire glisser le thread de rendu. Dans D3D12, plusieurs threads peuvent appeler en toute sécurité des routines simultanément.

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

  • 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 le placement d’une ressource à un décalage non nul au sein d’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 l’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 remappées directement vers un autre tas ; mais ils permettent une réaffectation simple des données de ressources entre les segments de mémoire. Après avoir créé une ressource placée dans un segment de mémoire différent et copié les données de ressource, de nouveaux descripteurs de ressources devront être utilisés pour le nouvel emplacement des données de ressource.
  • Les ressources réservées sont disponibles uniquement lorsque l’adaptateur prend en charge le niveau de ressources en mosaïques 1 ou supérieur. Lorsqu’ils sont disponibles, ils offrent les techniques de gestion des résidences les plus avancées disponibles ; mais pas tous les adaptateurs les prennent actuellement en charge. Ils permettent de remapper une ressource sans nécessiter la régénération des descripteurs de ressources, la résidence au niveau mip partiel et les scénarios de texture éparse, etc. Tous les types de ressources ne sont pas pris en charge même lorsque des ressources réservées sont disponibles. Par conséquent, un gestionnaire de résidence basé sur une page générale n’est pas encore possible.

Priorités de résidence

Windows 10 Creators Update permet aux développeurs d’influencer les tas et les ressources qui seront préférés rester résident lorsque la pression de la mémoire exige que certaines de ses ressources soient rétrogradées. Cela permet aux développeurs de créer de meilleures applications 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 confortables et capables de spécifier les priorités à mesure qu’ils passent de l’utilisation de ressources validées à des ressources réévérées et en mosaïques.

L’application de ces priorités doit être plus facile que de gérer deux budgets de mémoire dynamique, rétrograder manuellement et promouvoir les 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 attribuées à chaque tas ou ressource lors de sa création. Pour plus d’informations, consultez ID3D12Device1 ::SetResidencyPriority et l’énumération D3D12_RESIDENCY_PRIORITY.

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

  • Augmentez la priorité de quelques tas exceptionnels afin de mieux atténuer l’impact des performances expérimentés de ces tas rétrogradés tôt ou plus fréquemment que leurs modèles d’accès naturels seraient demandés. Cette approche devrait être exploitée par les applications transférées à partir d’API graphiques telles que Direct3D 11 ou OpenGL, qui sont considérablement différentes de celles de Direct3D 12.
  • Remplacez presque toutes les priorités de tas par le propre schéma de compartimentation de l’application, soit fixe, en fonction des 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 exiger une intevention du programmeur au fur et à 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, par exemple 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 tout tas qu’elle tente de gérer sans d’abord instancier l’algorithme de priorité par défaut. Cela est dû au fait que la valeur d’affectation d’une priorité particulière à un tas est dérivée de sa priorité relative à d’autres tas hiérarchisés qui rivalisent 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) segments supposés être écrits fréquemment par le GPU sur des segments 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). Il s’agit des valeurs de priorité attribuées dans la plage commençant à D3D12_RESIDENCY_PRIORITY_HIGH; pour hiérarchiser davantage ces tas et ces 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 à 0xFFFF pour les tas extrêmement volumineux). Cette hiérarchisation supplémentaire favorise les tas et les ressources plus volumineux.

Le compartiment à faible priorité contient tous les autres tas et ressources, qui ont une valeur de priorité de D3D12_RESIDENCY_PRIORITY_NORMAL. Aucune autre hiérarchisation entre ces tas et ressources n’est tentée.

Gestion de la résidence 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 échecs de mémoire insuffisante. En cas de défaillance, l’application peut détruire d’autres ressources validées ou objets API pour permettre la réussite des créations de ressources supplémentaires. Toutefois, même les applications simples sont fortement recommandées pour surveiller les modifications budgétaires négatives et détruire les objets API inutilisés environ une fois par image.

La complexité d’une conception de gestion de résidence s’étend lors de la tentative d’optimisation pour les architectures d’adaptateurs ou l’incorporation de priorités de résidence. Le budget discret et la gestion 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 augmente la complexité, car la mauvaise ressource dans la mémoire système peut avoir un impact grave sur la fréquence d’images. Et il n’existe aucune fonctionnalité simple pour aider à identifier les ressources qui bénéficieraient d’une bande passante GPU supérieure ou tolérer 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_TIERet D3D12_RESOURCE_HEAP_TIER.

Plusieurs parties d’une application se retrouveront probablement à l’aide de différentes techniques. Par exemple, certaines textures volumineuses et des chemins de code rarement exercices 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