Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Este artigo fornece detalhes sobre o gerenciamento de memória virtual de GPU a partir do Windows 10 (WDDM 2.0). Ele descreve por que o WDDM 2.0 foi alterado para dar suporte ao endereçamento virtual de GPU e como os drivers o usam.
Introdução
Antes do WDDM 2.0, a DDI (interface do driver do dispositivo) foi projetada de modo que os motores da GPU deveriam referenciar a memória por meio de endereços físicos de segmento. À medida que os segmentos eram compartilhados entre aplicativos e superalocados, os recursos eram realocados durante sua vida útil e seus endereços físicos atribuídos eram alterados. Esse processo exigia que as referências de memória fossem rastreadas nos buffers de comando por meio de listas de alocação e localização do patch. Esses buffers precisavam ser atualizados com a referência de memória física correta antes do envio para um motor de processamento de GPU. Esse monitoramento e aplicação de patches foi caro. Ele essencialmente impôs um modelo de agendamento em que o VidMm (gerenciador de memória de vídeo) tinha que inspecionar todos os pacotes antes que pudesse ser enviado para um mecanismo.
Com o tempo, mais fornecedores de hardware foram movidos para um modelo de agendamento baseado em hardware. Nesse modelo, o trabalho é enviado para a GPU diretamente do modo de usuário e a GPU gerencia as várias filas de trabalho propriamente ditas. Essa evolução tornou necessário eliminar a necessidade de o VidMm inspecionar e corrigir todos os buffers de comando antes de enviar para um mecanismo de GPU.
Para fazer isso, o WDDM dá suporte ao endereçamento virtual de GPU a partir do WDDM 2.0. Nesse modelo, cada processo recebe um espaço de GPUVA (endereço virtual de GPU) exclusivo no qual cada contexto de GPU pode ser executado. Uma alocação criada ou aberta por um processo recebe uma GPUVA exclusiva dentro do espaço de endereço virtual da GPU desse processo. Essa GPUVA atribuída permanece constante e exclusiva durante o tempo de vida da alocação. O driver de exibição no modo de usuário (UMD) é capaz de referenciar alocações por meio de seu endereço virtual de GPU, sem precisar se preocupar com a alteração da memória física subjacente ao longo de seu tempo de vida.
Mecanismos individuais de uma GPU podem operar no modo físico ou virtual:
No modo físico, o modelo de agendamento permanece o mesmo que é com o WDDM v1.x. O UMD continua a gerar as listas de alocação e localização de patches. Essas listas de alocação são enviadas com um buffer de comando e são usadas para ajustar buffers de comando para endereços físicos reais antes do envio a um engine.
No modo virtual, um mecanismo faz referência à memória por meio de endereços virtuais de GPU. O UMD gera buffers de comando diretamente do modo de usuário e usa novos serviços para enviar esses comandos para o kernel. O UMD não gera listas de alocação ou localização de patch, embora ainda seja responsável por gerenciar a presença das alocações. Para obter mais informações sobre a residência do driver, consulte a residência do driver no WDDM 2.0.
Modelos de memória de GPU
O WDDM v2 dá suporte a dois modelos distintos para endereçamento virtual de GPU, GpuMmu e IoMmu. Um driver deve aceitar para dar suporte a ambos ou aos dois modelos. Um único nó de GPU pode dar suporte a ambos os modos simultaneamente.
Modelo GpuMmu
No modelo gpuMmu , o VidMm gerencia a unidade de gerenciamento de memória de GPU e as tabelas de páginas subjacentes. O VidMm também expõe serviços ao UMD que permitem gerenciar o mapeamento de endereço virtual de GPU para alocações. GpuMmu implica que a GPU usa tabelas de página da GPU para acessar dados. As tabelas de página podem apontar para memória do sistema ou memória do dispositivo local.
Para obter mais informações, consulte o modelo gpuMmu.
Modelo de IoMmu
No modelo IoMmu , a CPU e a GPU compartilham um espaço de endereço comum e tabelas de página de CPU. Somente a memória do sistema pode ser acessada nesse caso, portanto, o IoMmu é adequado para GPUs integradas. O IoMmu fornece um modelo de programação mais simples, em que a GPU e a CPU podem usar o mesmo ponteiro para acessar a memória. Não é necessário gerenciar um conjunto separado de tabelas de páginas na memória acessível por GPU. Dito isto, o modelo IoMmu pode resultar em um desempenho degradado devido à sobrecarga de conversão e gerenciamento de endereços.
Para obter mais informações, consulte o modelo IoMmu.