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 vidéo tentent de garantir au jeu un accès exclusif aux ressources de l’appareil. Bien que la plupart des consoles aient des spécifications inférieures à celles des PC de jeu haut de gamme, cela permet d’optimiser les jeux pour console explicitement pour leur plateforme cible et ainsi d’offrir des expériences de très haute qualité qui surpassent ce à quoi on pourrait s’attendre en examinant les statistiques brutes du matériel. Aujourd’hui, les joueurs s’attendent à des fonctionnalités (en particulier des fonctionnalités sociales et en ligne) qui ont un coût et qui exigent un certain assouplissement de la garantie de ressources pour être prises en charge. Cela permet aux fournisseurs de services et de plateformes comme XBOX de mettre en œuvre ces fonctionnalités de façon cohérente d’un jeu à l’autre. Le Microsoft Game Development Kit (GDK) offre aux développeurs de jeux un accès performant, 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 la XBOX One répondait à de nombreux besoins des développeurs de jeux, nous avons reçu beaucoup de commentaires sur la façon de l’améliorer. Par exemple, historiquement, le partage des ressources de 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égler ces problèmes tout en prenant soin de conserver les aspects qui avaient connu le plus de succès. Notre nouvelle architecture fournit les garanties plus concrètes et déterministes que les développeurs de jeux souhaitent et attendent. L’architecture maintient les optimisations de performance et la flexibilité sur lesquelles les jeux XBOX One en sont venus à compter.Diagramme de l’architecture
Le diagramme suivant présente l’architecture de la mémoire du Microsoft Game Development Kit (GDK).
Fonctionnalités clés
- Grande similarité avec le système ERA de la 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 à une granularité de 64 Ko
- Isolation stricte de la consommation de mémoire entre les composants du jeu et les composants autres que le jeu (plateforme)
- Suivi à l’exécution de toute la consommation de mémoire dans l’espace de la partition du titre
- Tous les tas Win32 utilisent des pages de 2 Mo pour assurer les performances
[!NOTE] Le code source de l’implémentation par défaut deXMemAllocet deXMemFreeest 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) poursuit le modèle à « trois pools » créé pour le système d’exploitation ERA de la XBOX One. Dans cette architecture, chaque pool a une propriété explicite sur des catégories précises 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 du titre : responsable de toute la consommation de mémoire générée par le processus du jeu et des pages exécutables du jeu
- Partition des outils : pool de mémoire facultatif qui peut être utilisé pour isoler la mémoire étendue/de débogage de la mémoire commerciale (offert uniquement sur les kits de développement)
- Normalement, lors de l’allocation, le gestionnaire de mémoire de Windows remplit de zéros les pages de mémoire par mesure de sécurité. Pour la partition du titre, cette fonctionnalité est désactivée, ce qui redonne 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) assure 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 affectée à tous les processus au moment de leur 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 du titre utilisée par le jeu. Le processus du titre, quant à lui, utilise la partition du titre et obtient sa mémoire de ce pool dédié. Plusieurs personnalisations sont appliquées au processus du titre au lancement afin d’isoler les allocations de mémoire entre le titre et le code système. Elles comprennent les suivantes :- Un pilote mini-filtre du système de fichiers surveille chaque mappage de fichier et classe le fichier comme fichier système (tel que kernelbase.dll) ou fichier du jeu. Les fichiers système sont marqués pour être alloués à la partition système, tandis que les fichiers du jeu sont imputés à la partition du titre.
- Des tas Win32 distincts sont créés dans la partition système et dans la partition du titre (le tas du titre est créé à la première utilisation); ils possèdent 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 au moyen de 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 du titre, selon la DLL source.
Coûts de mémoire imputés au titre
La partition du titre demeure responsable de couvrir les éléments suivants :- Empreinte mémoire du code et des données/du contenu propres au processus du 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 du 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 du jeu.
- Mémoire nécessaire pour créer les mémoires tampons transmises aux appels d’API système.
- Mémoire nécessaire pour capturer les 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 a besoin de métadonnées pour assurer le suivi des allocations. Elles sont imputées à la partition du 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 à l’exécution. La macroXMEM_SET_ALLOCATION_HOOKS permet le suivi de la mémoire retournée par les appels à XMemAlloc. De plus, toutes les allocations de tas Win32 peuvent être surveillées au moyen d’un rappel de suivi configuré (consultez XMemSetWin32HeapTrackingHooks) afin de détecter 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 semblable à VirtualQuery, mais elle retourne des informations supplémentaires qui ne sont pas offertes par 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 offertes pour le suivi de la mémoire à 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 dont votre titre devrait disposer dans l’environnement commercial grand public. De plus, la prise en charge de la partition des 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 ont désormais la garantie d’un pool de mémoire constant 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 une partie des ressources du système d’exploitation système vers le jeu; il est nécessaire pour que des outils comme PIX fonctionnent à pleine capacité. Certaines fonctionnalités, comme 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 PC Windows), 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 plus de mémoire est nécessaire. Pour ajouter de la mémoire à l’espace du titre, utilisez ce qui suit :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é.