Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Este artigo fornece detalhes sobre o gerenciamento de memória virtual GPU a partir do Windows 10 (WDDM 2.0). Ele descreve por que o WDDM 2.0 foi alterado para oferecer suporte ao endereçamento virtual da GPU e como os drivers o usam.
Introdução
Antes do WDDM 2.0, a interface do driver de dispositivo (DDI) era construída de tal forma que os mecanismos de GPU deveriam fazer referência à memória por meio de endereços físicos de segmento. À medida que os segmentos eram compartilhados entre aplicativos e excessivamente comprometidos, os recursos eram realocados ao longo de 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 dentro de buffers de comando por meio de listas de alocação e localização de patches. Esses buffers precisavam ser atualizados com a referência de memória física correta antes do envio para um motor de GPU. Esse rastreamento e correção eram caros. Essencialmente, impôs um modelo de agendamento onde o gerenciador de memória de vídeo (VidMm) tinha que inspecionar cada pacote antes que pudesse ser submetido a um mecanismo.
Com o tempo, mais fornecedores de hardware migraram para um modelo de agendamento baseado em hardware. Neste modelo, o trabalho é enviado para a GPU diretamente do modo de usuário e a GPU gerencia as várias filas de trabalho em si. Essa evolução tornou necessário eliminar a necessidade de o VidMm inspecionar e corrigir cada buffer de comandos antes do envio para um mecanismo de GPU.
Para fazer isso, o WDDM suporta endereçamento virtual de GPU a partir do WDDM 2.0. Neste modelo, cada processo recebe um espaço exclusivo de endereço virtual de GPU (GPUVA) no qual cada contexto de GPU pode ser executado. Uma alocação criada ou aberta por um processo recebe um endereço GPUVA exclusivo dentro do espaço de endereçamento virtual da GPU desse processo. Esta GPUVA atribuída permanece constante e única durante a duração da alocação. O driver de exibição de modo de usuário (UMD) é, portanto, capaz de referenciar alocações através de seu endereço virtual GPU sem ter que se preocupar com a memória física subjacente mudando ao longo de sua vida útil.
Os mecanismos individuais de uma GPU podem operar no modo físico ou virtual:
No modo físico, o modelo de agendamento permanece o mesmo do 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 comandos e são usadas para corrigir buffers de comandos para endereços físicos reais antes do envio para um mecanismo.
No modo virtual, um mecanismo faz referência à memória por meio de endereços virtuais da GPU. O UMD gera buffers de comandos 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 de localização de patches, embora ainda seja responsável por gerir a residência das alocações. Para obter mais informações sobre residência de controlador, consulte Residência de controlador no WDDM 2.0.
Modelos de memória GPU
WDDM v2 suporta dois modelos distintos para endereçamento virtual GPU, GpuMmu e IoMmu. O condutor tem de optar por suportar um ou ambos os modelos. Um único nó GPU pode suportar ambos os modos simultaneamente.
Modelo GpuMmu
No modelo GpuMmu , o VidMm gerencia a unidade de gerenciamento de memória GPU e as tabelas de página subjacentes. O VidMm também expõe serviços ao UMD que permitem gerenciar o mapeamento de endereços virtuais da GPU para alocações. GpuMmu implica que a GPU usa tabelas de página GPU para aceder a dados. As tabelas de página podem apontar para a memória do sistema ou para a memória do dispositivo local.
Para obter mais informações, consulte Modelo GpuMmu.
Modelo IoMmu
No modelo IoMmu , tanto a CPU quanto a GPU compartilham um espaço de endereço comum e tabelas de páginas da CPU. Neste caso, apenas a memória do sistema pode ser acessada, portanto, o IoMmu é adequado para GPUs integradas. O IoMmu fornece um modelo de programação mais simples, onde a GPU e a CPU podem usar o mesmo ponteiro para acessar a memória. Não há necessidade de gerenciar um conjunto separado de tabelas de páginas na memória acessível por GPU. Dito isso, o modelo IoMmu pode resultar em desempenho degradado devido à sobrecarga de tradução e gerenciamento de endereços.
Para obter mais informações, consulte Modelo IoMmu.