Introduction
Contrairement à la plupart des applications informatiques, où plusieurs applications doivent pouvoir s’exécuter simultanément sur le matériel, les consoles de jeux essaient de garantir au jeu un accès exclusif aux ressources de l’appareil. Bien que la plupart des consoles aient des caractéristiques inférieures à celles des PC de jeu haut de gamme, cela permet aux jeux sur console d’être optimisés explicitement pour leur plateforme cible et d’offrir ainsi des expériences de très haute qualité qui dépassent ce que l’on pourrait attendre en examinant les caractéristiques brutes du matériel. Aujourd’hui, les joueurs attendent des fonctionnalités (en particulier sociales et en ligne) qui ont un coût et nécessitent un certain assouplissement de la garantie de ressources. Cela permet aux fournisseurs de services et de plateformes comme XBOX d’implémenter ces fonctionnalités de manière cohérente d’un jeu à l’autre. Le Microsoft Game Development Kit (GDK) offre aux développeurs de jeux un accès hautes performances, déterministe et prévisible à la mémoire physique. Bien que notre précédent gestionnaire de mémoire du système d’exploitation ERA de XBOX One ait répondu à de nombreux besoins des développeurs de jeux, nous avons reçu de nombreux commentaires sur la façon de l’améliorer. Par exemple, historiquement, le partage des ressources mémoire entre le code du jeu et les services de la plateforme n’était pas aussi déterministe qu’il aurait pu l’être. Nous avons reconstruit le gestionnaire de mémoire pour résoudre ces problèmes, tout en veillant à conserver les aspects qui avaient le mieux fonctionné. Notre nouvelle architecture fournit les garanties plus concrètes et déterministes que les développeurs de jeux souhaitent et attendent. L’architecture conserve les optimisations de performances et la flexibilité sur lesquelles les jeux XBOX One se sont appuyés.Diagramme d’architecture
Le diagramme suivant présente l’architecture de la mémoire du Microsoft Game Development Kit (GDK).
Fonctionnalités clés
- Forte similarité avec le système ERA de XBOX One afin de tirer parti des connaissances et de l’expertise existantes des développeurs :
- Y compris les optimisations pour l’allocation de pages de 64 Ko/2 Mo en tant que mémoire non initialisée
- Famille d’API
XMemAlloc - Allocation et mappage de pages physiques avec une granularité de 64 Ko
- Isolation stricte de la consommation de mémoire entre les composants du jeu et les composants hors jeu (plateforme)
- Suivi au moment de l’exécution de toute la consommation de mémoire dans l’espace de la partition de titre
- Tous les tas Win32 utilisent des pages de 2 Mo pour les performances
[!NOTE] Le code source de l’implémentation par défaut deXMemAllocetXMemFreeest installé avec le Microsoft Game Development Kit (GDK). Consultez \GXDK\gameKit\Source\amd64\heap.c.
Vue d’ensemble
Partitions de mémoire
L’architecture de la mémoire du Microsoft Game Development Kit (GDK) reprend le modèle à « trois pools » créé pour le système d’exploitation ERA de XBOX One. Dans cette architecture, chaque pool est explicitement propriétaire de catégories spécifiques d’utilisation de la mémoire.- Partition système : responsable des processus système et des allocations de la plateforme, ainsi que des pages exécutables de la plateforme
- Partition de titre : responsable de toute la consommation de mémoire générée par le processus de jeu et des pages exécutables du jeu
- Partition d’outils : pool de mémoire facultatif qui peut être utilisé pour isoler la mémoire étendue/de débogage de la mémoire commerciale (disponible uniquement sur les kits de développement)
- Normalement, lors de l’allocation, le gestionnaire de mémoire de Windows remplit les pages de mémoire de zéros par mesure de sécurité. Pour la partition de titre, cette fonctionnalité est désactivée, ce qui restitue ces performances à votre titre.
Séparation des allocations de mémoire du titre et du système
Le système d’exploitation de jeu du Microsoft Game Development Kit (GDK) garantit l’isolation de l’utilisation de la mémoire du système et du jeu au moyen des partitions de mémoire. Une partition de mémoire est attribuée à chaque processus au moment de son lancement. Comme tous les processus système sont lancés dans la partition de mémoire système, ces processus ne peuvent allouer aucune mémoire à partir de la partition de titre utilisée par le jeu. Le processus de titre, quant à lui, utilise la partition de titre et obtient sa mémoire de ce pool dédié. Plusieurs personnalisations sont appliquées au processus de titre lors de son lancement afin d’isoler les allocations de mémoire entre le titre et le code système. En voici quelques-unes :- Un pilote de mini-filtre du système de fichiers surveille chaque mappage de fichier et classe le fichier comme fichier système (par exemple kernelbase.dll) ou fichier de jeu. Les fichiers système sont marqués pour être alloués sur la partition système, tandis que les fichiers de jeu sont imputés à la partition de titre.
- Des tas Win32 distincts sont créés dans la partition système et dans la partition de titre (le tas du titre est créé lors de la première utilisation), qui détiennent respectivement les allocations de tas effectuées par le code système et par le code du titre.
- Les API liées à l’allocation appelées via la table d’adresses d’importation de chaque module sont redirigées au moment du chargement vers des implémentations distinctes qui traitent l’allocation à partir de la partition système ou de la partition de titre, selon la DLL source.
Coûts de mémoire imputés au titre
La partition de titre reste responsable de la couverture des éléments suivants :- Empreinte mémoire du code et des données/du contenu propres au processus de jeu.
- Toutes les sections de données modifiées (c’est-à-dire les sections de copie sur écriture) des modules chargés par le processus de jeu.
- Espace de pile des threads.
- Entrées de table de pages nécessaires à la traduction des adresses virtuelles en adresses physiques par le processus de jeu.
- Mémoire nécessaire à la création des mémoires tampons transmises aux appels d’API système.
- Mémoire nécessaire à la capture des résultats des appels d’API système, des opérations asynchrones et des notifications.
- Autres métadonnées nécessaires à l’utilisation des fonctionnalités. Par exemple, le tas nécessite des métadonnées pour suivre les allocations. Elles sont imputées à la partition de titre pour toutes les allocations qu’il effectue.
Surveillance de l’utilisation de la mémoire et des appels d’allocation
Le système de mémoire du Microsoft Game Development Kit (GDK) offre une prise en charge étendue de la surveillance et du suivi de l’utilisation de la mémoire au moment de l’exécution. La macroXMEM_SET_ALLOCATION_HOOKS permet de suivre la mémoire renvoyée par les appels à XMemAlloc. En outre, toutes les allocations de tas Win32 peuvent être surveillées au moyen d’un rappel de suivi configuré (consultez XMemSetWin32HeapTrackingHooks) afin d’intercepter toute utilisation de malloc/new/HeapAlloc.
Enfin, les API XMemGetWorkingSetStatistics et XMemVirtualQuery peuvent être utilisées pour fournir des instantanés détaillés de l’utilisation de la mémoire physique et virtuelle. XMemVirtualQuery est très similaire à VirtualQuery, mais renvoie des informations supplémentaires non disponibles avec VirtualQuery, notamment la taille de page et la propriété (système ou jeu) de la mémoire.
Pour plus d’informations sur les API disponibles pour le suivi de la mémoire au moment de l’exécution, consultez la section Suivi de la mémoire de Portage de votre titre pour utiliser le gestionnaire de mémoire du système d’exploitation de jeu Microsoft GDK.
Tailles des partitions
Un changement important de cette version par rapport aux versions précédentes est que la console est configurée pour fournir la même configuration de mémoire que celle que votre titre devrait rencontrer dans l’environnement commercial grand public. En outre, la prise en charge de la partition d’outils a été ajoutée. La rubrique Portage de votre titre pour utiliser le gestionnaire de mémoire du système d’exploitation de jeu Microsoft GDK décrit les modifications apportées pour fournir un modèle de comptabilisation de la mémoire déterministe. Les développeurs disposent désormais de la garantie d’un pool de mémoire cohérent pour leur code, tandis que les binaires de la plateforme et les allocations temporaires sont imputés à un pool de mémoire système distinct de l’espace mémoire adressable du titre.Mode de profilage
Le mode de profilage est une option qui détourne certaines ressources du système d’exploitation système au profit du jeu ; il est nécessaire pour que des outils tels que PIX fonctionnent à pleine capacité. Certaines fonctionnalités, telles que les applications Hub, Game DVR et Microsoft Edge, peuvent offrir une expérience dégradée ou ne pas fonctionner du tout lorsque le mode de profilage est activé. Il peut être activé ou désactivé avec XBOX Manager, xbconfig.exe (sur Windows PC), wdconfig.exe (sur la console) ou le Developer Home Shell sur la console afin de rétablir le fonctionnement de ces fonctionnalités. Lorsque le mode de profilage est activé, de la mémoire étendue/de débogage supplémentaire peut éventuellement être ajoutée au pool du titre si davantage de mémoire est nécessaire. Pour ajouter de la mémoire à l’espace du titre, utilisez la commande suivante :Configuration de la mémoire
La configuration de la mémoire est décrite dans le tableau suivant.La mémoire des outils indiquée dans le tableau précédent n’est disponible que si le mode de profilage est activé.