Partilhar via

Memória virtual de GPU no WDDM 2.0

  • Artigo

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 foi alterado para oferecer suporte ao endereçamento virtual da GPU e como os drivers o usam.

Introdução

Antes do WDDM (Windows Display Driver Model) 2.0, a interface de driver de dispositivo (DDI) foi criada de forma que os mecanismos de GPU fizessem referência à memória por meio de endereços físicos de segmento. À medida que os segmentos eram compartilhados entre aplicativos e superconfirmados, 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 dos buffers de comando por meio de listas de alocação e local de patch. Esses buffers, então, precisavam ser corrigidos com a referência de memória física correta antes de serem enviados a um mecanismo de GPU. Esse rastreamento e correção eram caros. Ele essencialmente impôs um modelo de agendamento onde o gerenciador de memória de vídeo (VidMm) tinha que inspecionar cada pacote antes que ele 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 é submetido à 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 comando antes de enviar para um mecanismo de GPU.

Para fazer isso, o WDDM oferece suporte ao endereçamento virtual da GPU a partir do WDDM 2.0. Nesse 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 uma GPUVA exclusiva dentro do espaço de endereço virtual da GPU desse processo. Essa GPUVA atribuída permanece constante e exclusiva durante a vida útil da alocação. O driver de exibição de modo de usuário (UMD) é, portanto, capaz de referenciar alocações por meio de seu endereço virtual de 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 local de patch. Essas listas de alocação são enviadas com um buffer de comando e são usadas para corrigir buffers de comando para endereços físicos reais antes do envio a 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 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 de locais de patch, embora ainda seja responsável por gerenciar a residência das alocações. Para obter mais informações sobre residência de driver, consulte Residência de driver no WDDM 2.0.

Modelos de memória GPU

O WDDM v2 suporta dois modelos distintos para endereçamento virtual de GPU, GpuMmu e IoMmu. Um motorista deve optar por oferecer suporte a 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 da 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 acessar dados. As tabelas de página podem apontar para a memória do sistema ou memória do dispositivo local.

Para obter mais informações, consulte 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 da CPU. Somente a memória do sistema pode ser acessada neste caso, então 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ágina na memória acessível por GPU. Dito isso, o modelo IoMmu pode resultar em desempenho degradado devido à sobrecarga de conversão e gerenciamento de endereços.

Para obter mais informações, consulte Modelo IoMmu.