Stratégies de gestion de la mémoire
Un gestionnaire de mémoire pour Direct3D 12 peut devenir très rapidement compliqué avec tous les différents niveaux de prise en charge, pour les adaptateurs UMA ou discrets (non-UMA), et avec un large éventail de différences d’architecture entre les cartes GPU.
La stratégie recommandée pour la gestion de la mémoire Direct3D 12, décrite dans cette section, est « classifier, budget et flux ».
Types de ressource
Le concept de base d’une « ressource validée » (création d’espaces d’adressage virtuels et physiques initialisés dans la mémoire physique managée) existe depuis Direct3D 9, bien que l’adressage virtuel (VA) et l’adressage physique puissent être séparés dans Direct3D 12 pour permettre à l’application de gérer soigneusement la mémoire physique.
En plus des ressources validées, la construction de tas de Direct3D 12 active deux autres types de ressources : « placé » et « réservé ». Dans Direct3D 11, une ressource « réservée » était appelée « ressource mosaïque ».
Les ressources réservées diffèrent des ressources placées en ce que les ressources réservées ont leur propre espace d’adressage virtuel GPU unique. Cela permet une allocation importante de l’espace VA à l’avance, puis permet le mappage des pages VA à certaines sections du tas ultérieurement, et l’application reconfigure la disposition à la volée. L’espace VA est contigu et peut être partiellement mappé.
La ressource réservée peut être envoyée à des régions de référence dans le tas avec des appels d’API tels que UpdateTileMappings et elles peuvent être rendues résidentes par l’application en mettant à jour les tables de pages à la volée. Lorsqu’une plage VA est mappée à NULL ou à un tas non résident, cette partie de la ressource est considérée comme non-résidente. Lorsqu’une plage VA est mappée à un tas résident, cette partie de la ressource est considérée comme résidente. Les tas sont résidents lors de la création.
Les ressources placées sont une conception beaucoup plus simple, étant simplement un pointeur vers une certaine région d’un tas (par exemple, une région de 1 Mo pour une texture dans un tas de 5 Mo). Les barrières d’alias permettent d’utiliser des ressources placées qui se chevauchent (reportez-vous à CreatePlacedResource et ResourceBarrier).
Les ressources réservées ne sont pas disponibles sur tout le matériel Direct3D 12 et les ressources placées constituent un secours raisonnable, bien que les ressources placées doivent être contiguës et ne peuvent pas être partiellement résidentes.
Budget mémoire
Dans Direct3D 12, lorsque vous allouez un tas, vous créez l’aspect mémoire physique d’une ressource validée. Un choix de segment de mémoire plus explicite est disponible dans Direct3D 12 (choix entre la vidéo et la mémoire système). Les adaptateurs UMA n’ont qu’un seul segment de mémoire, la mémoire système.
Les GPU ne prenant pas en charge les erreurs de page, les développeurs doivent donc être conscients qu’ils ne dépassent pas la validation, en particulier pour les systèmes avec seulement 1 Go de mémoire système. Si une application effectue une validation supérieure, le système d’exploitation utilise une planification plus grossière des processus en fonction de leur demande sur la mémoire physique. Le planificateur va figer les processus de premier plan et essentiellement en pager une partie, afin de mettre en page un processus en arrière-plan qui veut s’exécuter. La mémoire physique disponible peut varier considérablement en fonction de ce que l’utilisateur fait en arrière-plan (par exemple, l’exécution d’un navigateur ou le visionnage d’une vidéo).
L’API pour le budget de mémoire est QueryVideoMemoryInfo. Pour les adaptateurs discrets , « local » est la mémoire vidéo, « non local » est la mémoire système. Pour les adaptateurs UMA, la valeur non locale est toujours égale à zéro. Une question de conception est de savoir si votre moteur gérera les deux budgets ou uniquement le budget local. La gestion uniquement du budget local est plus simple, mais présente quelques réserves; par exemple, supposons qu’il existe un budget local maximal de 1 Go, puis que tous les tas provient de ce 1 Go dans un système UMA et qu’il n’y a pas de dépassement de capacité de la mémoire système (clairement, car il n’y en a pas).
Depuis la mémoire managée Direct3D11 pour les applications, les ressources inutilisées sont essentiellement paginées.
Choisissez les dimensions de ressource les plus appropriées. Déterminez si la taille d’une ressource est appropriée pour la situation dans laquelle l’application s’exécute réellement. Certains utilisateurs peuvent exécuter l’application dans une fenêtre ou avec une résolution d’écran de 800x600.
Stratégie de classification
Pour gérer efficacement les ressources dans les scénarios liés à la mémoire, envisagez de classer les ressources dans les éléments suivants :
| Classification | Exemples | Objets et fonctionnalités d’API | Notes de gestion |
|---|---|---|---|
| Critique | Interface utilisateur du jeu | Allocateur de commandes, files d’attente de commandes, tas de requêtes, ressources et tas de ressources. | Ces éléments doivent être inclus dans la mémoire non paginable/toujours validée. |
| Mis à l’échelle/ Facultatif | Modèles et textures spécifiques aux niveaux, chaînes d’échange, sky box, modèles de personnages joueurs à la première personne | Ressources et tas. Les ressources validées, mais également les ressources placées et réservées peuvent fonctionner tout aussi bien. | Intégrez la budgétisation de la résidence de la mémoire dans les algorithmes de rendu. Choisissez le niveau de détail disponible approprié et réévaluez moins d’une fois par image. Les techniques incluent l’utilisation de ressources de taille variable et la mise à l’échelle de la chaîne d’échange. |
| Ressources réutilisées | Mémoires tampons d’ombre, ressources de rendu différé, ressources de post-traitement, caches de données d’éclairage | Ressources et tas. Chevauchement des ressources placées sur des tas et des barrières d’aliasing. | Réutilisez des ressources volumineuses ou des régions de tas au sein d’un cadre pour réduire les exigences pour l’ensemble du cadre. Utilisez la technique de réutilisation de la mémoire intra-frame. Dans Direct3D 11, les applications ne pouvaient réutiliser que des ressources avec le même type et des dimensions potentiellement suffisamment grandes. Les tas Direct3D 12 permettent le chevauchement des ressources pour une réutilisation beaucoup plus simple et plus importante. |
| Ressources de streaming | Terrain, textures et géométrie en monde ouvert | Ressources et tas. Création de threads libres, threads d’uc en arrière-plan et listes de commandes de copie en arrière-plan. | La résidence partielle, généralement basée sur la visibilité (à l’aide de la vue-frustum ou de l’évaluation basée sur la distance) et la réévaluation de la résidence ont besoin de chaque image. La technique consistant à utiliser une gestion de résidence partielle par vignette et une réutilisation inter-images est disponible lorsque l’adaptateur GPU prend en charge des ressources réservées dans des tas. À l’aide de la technique consistant à utiliser la réutilisation de la mémoire inter-images, la résidence partielle de sous-ressource peut être effectuée, mais est moins optimale. Les ressources placées avec des tas doivent permettre un recyclage plus rapide, mais les ressources validées peuvent être utilisées comme secours. |
Plus les applications gravitent vers les ressources de streaming pour la majeure partie du travail, plus elles tireront parti des ressources placées et réservées, ce qui optimisera la réutilisation de la mémoire entre ces quatre classifications. Plus les applications diffusent, plus elles budgetent et hiérarchisent la bande passante.
En règle générale, avec Direct3D 12, les moteurs graphiques doivent respecter un budget plus diversifié et dynamique, et le faire plus strictement qu’ils ne l’ont fait dans le passé. Les meilleures applications localiseront les quatre catégories dans le budget donné au processus, en faisant évoluer le jeu de l’application mobile en arrière-plan aux budgets discrets en plein écran. Toutefois, de nombreuses applications auront probablement des difficultés en commençant par un trop grand nombre de types de catégories critiques de ressources. Les ressources direct3D 11 ont été créées de manière anonyme et occupent des status critiques sans affecter les performances. Toutefois, pour Direct3D 12, les développeurs doivent rechercher avec diligence les ressources créées de manière aléatoire dans leur moteur et intergicieliel et les réappa assigner à l’une des autres catégories.
Les autres problèmes sont les composants d’intergiciels, les contrôles utilisateur et la diffusion en continu intra-frame. Les composants d’intergiciels ne peuvent pas être exposés à un budget, ni avoir à travailler étroitement ensemble. Les composants d’intergiciel peuvent probablement exposer des fonctionnalités en tant que techniques de rendu ; et l’application peut s’appuyer sur l’exposition des paramètres du middleware et du moteur. Les développeurs pouvaient s’appuyer sur Direct3D 11 pour effectuer la pagination et obtenir la bonne fréquence d’images. Dans certains cas, les applications Direct3D 11 ont peut-être paginé le contenu des ressources dans et vers chaque image ; et cela a donné lieu à des fréquences d’images acceptables pour l’utilisateur. La plupart des moteurs diffusent uniquement les données de ressources en tant qu’activité en arrière-plan, où ils ne disposent pas de secours grâce à la diffusion en continu intra-image à priorité élevée. Demander aux moteurs d’implémenter cela érodera certains des gains de surcharge processeur qu’ils recherchent en passant à Direct3D 12. Les développeurs de moteurs pourraient envisager de transformer leurs images en phases pour offrir plus de possibilités de ressources réutilisables ; et travaillent probablement avec des fournisseurs d’intergiciels pour prendre en charge les ressources et les tas placés pour la réutilisation de la mémoire intra-image.