Introdução
Ao contrário da maioria dos aplicativos de computação, em que vários aplicativos precisam poder ser executados simultaneamente no hardware, os consoles de jogos tentam garantir ao jogo acesso exclusivo aos recursos do dispositivo. Embora a maioria dos consoles tenha especificações inferiores às de PCs para jogos de alto desempenho, isso permite que os jogos de console sejam otimizados explicitamente para a plataforma de destino e, assim, ofereçam experiências de altíssima qualidade que superam o que você poderia esperar ao analisar as estatísticas brutas do hardware. Hoje, os jogadores esperam recursos (especialmente funcionalidades sociais e online) que têm um custo e exigem certo relaxamento da garantia de recursos para dar suporte a essa funcionalidade. Isso permite que provedores de serviços e plataformas como o XBOX implementem esses recursos de forma consistente entre os jogos. O Microsoft Game Development Kit (GDK) oferece aos desenvolvedores de jogos acesso de alto desempenho, determinístico e previsível à memória física. Embora nosso gerenciador de memória anterior do sistema operacional ERA do XBOX One atendesse a muitas das necessidades dos desenvolvedores de jogos, recebemos muitos comentários sobre como melhorá-lo. Por exemplo, historicamente, o compartilhamento de recursos de memória entre o código do jogo e os serviços da plataforma não era tão determinístico quanto poderia ser. Reconstruímos o gerenciador de memória para resolver esses problemas, tomando o cuidado de manter os aspectos em que tivemos mais sucesso. Nossa nova arquitetura oferece as garantias mais concretas e determinísticas que os desenvolvedores de jogos desejam e esperam. A arquitetura mantém as otimizações de desempenho e a flexibilidade das quais os jogos do XBOX One passaram a depender.Diagrama da arquitetura
O diagrama a seguir mostra a arquitetura de memória do Microsoft Game Development Kit (GDK).
Principais recursos
- Semelhança substancial com o sistema ERA do XBOX One para aproveitar o conhecimento e a experiência existentes dos desenvolvedores:
- Incluindo otimizações para alocar páginas de 64 KB/2 MB como memória não inicializada
- Família de APIs
XMemAlloc - Alocação e mapeamento de páginas físicas com granularidade de 64 KB
- Isolamento rígido do consumo de memória entre componentes do jogo e componentes que não são do jogo (plataforma)
- Rastreamento em runtime de todo o consumo de memória no espaço da partição de título
- Todos os heaps Win32 usando páginas de 2 MB para melhor desempenho
[!NOTE] O código-fonte da implementação padrão deXMemAlloceXMemFreeé instalado como parte do Microsoft Game Development Kit (GDK). Consulte \GXDK\gameKit\Source\amd64\heap.c.
Visão geral
Partições de memória
A arquitetura de memória do Microsoft Game Development Kit (GDK) dá continuidade ao modelo de “três pools” criado para o sistema operacional ERA do XBOX One. Nessa arquitetura, cada pool tem propriedade explícita sobre categorias específicas de uso de memória.- Partição do sistema: responsável pelos processos do sistema e pelas alocações da plataforma, bem como pelas páginas executáveis da plataforma
- Partição de título: responsável por todo o consumo de memória gerado pelo processo do jogo e pelas páginas executáveis do jogo
- Partição de ferramentas: um pool de memória opcional que pode ser usado para isolar a memória estendida/de depuração da memória de varejo (disponível apenas em kits de desenvolvimento)
- Normalmente, durante a alocação, o gerenciador de memória do Windows preenche as páginas de memória com zeros como medida de segurança. Para a partição de título, essa funcionalidade é desabilitada, devolvendo esse desempenho ao seu título.
Separação das alocações de memória do título e do sistema
O sistema operacional de jogos do Microsoft Game Development Kit (GDK) garante o isolamento da utilização de memória do sistema e do jogo por meio das partições de memória. Todos os processos recebem uma partição de memória no momento da inicialização. Como todos os processos do sistema são iniciados na partição de memória do sistema, esses processos não podem alocar memória da partição de título usada pelo jogo. O processo do título, por outro lado, usa a partição de título e obtém sua memória desse pool dedicado. Várias personalizações são aplicadas ao processo do título na inicialização para obter o isolamento das alocações de memória entre o código do título e o do sistema. Elas incluem o seguinte:- Um driver de minifiltro do sistema de arquivos monitora cada mapeamento de arquivo e classifica o arquivo como arquivo do sistema (como kernelbase.dll) ou arquivo do jogo. Os arquivos do sistema são marcados para serem alocados na partição do sistema, enquanto os arquivos do jogo são cobrados da partição de título.
- Heaps Win32 separados são criados nas partições do sistema e de título (o heap de título é criado no primeiro uso), que são proprietários das alocações de heap feitas pelo código do sistema e do título, respectivamente.
- As APIs relacionadas à alocação chamadas por meio da tabela de endereços de importação de cada módulo são redirecionadas, no momento do carregamento, para implementações separadas que atendem à alocação a partir da partição do sistema ou da partição de título, dependendo da DLL de origem.
Custos de memória cobrados do título
A partição de título continua responsável por cobrir o seguinte:- O volume de memória do código e dos dados/conteúdo específicos do processo do jogo.
- Todas as seções de dados modificadas (ou seja, seções de cópia na gravação) dos módulos carregados pelo processo do jogo.
- O espaço da pilha de threads.
- As entradas da tabela de páginas necessárias para a tradução de endereços virtuais em físicos pelo processo do jogo.
- A memória necessária para criar buffers passados para chamadas de API do sistema.
- A memória necessária para capturar os resultados de chamadas de API do sistema, operações assíncronas e notificações.
- Outros metadados necessários para usar recursos. Por exemplo, o heap exige metadados para rastrear alocações. Eles são cobrados da partição de título para todas as alocações que ele realiza.
Monitorar a utilização de memória e as chamadas de alocação
O sistema de memória do Microsoft Game Development Kit (GDK) tem amplo suporte para monitorar e rastrear o uso de memória em runtime. A macroXMEM_SET_ALLOCATION_HOOKS habilita o rastreamento da memória retornada por meio de chamadas a XMemAlloc. Além disso, todas as alocações de heap Win32 podem ser monitoradas por meio de um retorno de chamada de rastreamento configurado (consulte XMemSetWin32HeapTrackingHooks) para capturar qualquer uso de malloc/new/HeapAlloc.
Por fim, as APIs XMemGetWorkingSetStatistics e XMemVirtualQuery podem ser usadas para fornecer instantâneos detalhados da utilização de memória física e virtual. XMemVirtualQuery é muito semelhante a VirtualQuery, mas retorna informações adicionais que não estão disponíveis em VirtualQuery, incluindo o tamanho da página e a propriedade (sistema ou jogo) da memória.
Para obter mais informações sobre as APIs disponíveis para rastreamento de memória em runtime, consulte a seção Rastreamento de memória de Portar seu título para usar o gerenciador de memória do Microsoft GDK Game OS.
Tamanhos das partições
Uma mudança significativa nesta versão em comparação com as versões anteriores é que o console é configurado para oferecer a mesma configuração de memória que se espera que seu título tenha no ambiente do consumidor de varejo. Além disso, foi adicionado suporte à partição de ferramentas. O tópico Portar seu título para usar o gerenciador de memória do Microsoft GDK Game OS descreve as alterações feitas para oferecer um modelo determinístico de contabilização de memória. Agora, os desenvolvedores têm a garantia de um pool de memória consistente para seu código, ao mesmo tempo em que os binários da plataforma e as alocações transitórias são cobrados de um pool de memória do sistema separado do espaço de memória endereçável do título.Modo de criação de perfil
O modo de criação de perfil é uma opção que desvia alguns dos recursos do sistema operacional do sistema para o jogo e é necessário para que ferramentas como o PIX funcionem com capacidade total. Alguns recursos, como Hub Apps, Game DVR e Microsoft Edge, podem ter uma experiência degradada ou não funcionar quando o modo de criação de perfil está habilitado. Ele pode ser habilitado ou desabilitado com o XBOX Manager, o xbconfig.exe (no PC com Windows), o wdconfig.exe (no console) ou o Developer Home Shell no console para restaurar a funcionalidade desses recursos. Quando o modo de criação de perfil está habilitado, há memória estendida/de depuração adicional que pode, opcionalmente, ser adicionada ao pool de título se for necessária mais memória. Para adicionar mais memória ao espaço do título, use o seguinte:Configuração de memória
A configuração de memória é descrita na tabela a seguir.A memória de ferramentas na tabela anterior só está disponível se o modo de criação de perfil estiver habilitado.