Memoria virtual de GPU en WDDM 2.0

En este artículo se proporcionan detalles sobre la administración de memoria virtual de GPU a partir de Windows 10 (WDDM 2.0). Describe por qué se cambió WDDM para admitir el direccionamiento virtual de GPU y cómo lo usan los controladores.

Introducción

Antes de Windows Display Driver Model (WDDM) 2.0, la interfaz del controlador de dispositivo (DDI) se creó de forma que se esperaba que los motores de GPU hagan referencia a la memoria a través de direcciones físicas de segmento. A medida que los segmentos se comparten entre aplicaciones y se han confirmado demasiado, los recursos se reubicaron a lo largo de su duración y sus direcciones físicas asignadas cambiaron. Este proceso requería el seguimiento de las referencias de memoria dentro de los búferes de comandos a través de listas de ubicaciones de asignación y revisión. Esos búferes deben revisarse con la referencia de memoria física correcta antes de enviar a un motor de GPU. Este seguimiento y aplicación de revisiones era costoso. Básicamente imponía un modelo de programación en el que el administrador de memoria de vídeo (VidMm) tenía que inspeccionar cada paquete antes de que se pudiera enviar a un motor.

Con el tiempo, más proveedores de hardware se trasladaron hacia un modelo de programación basado en hardware. En este modelo, el trabajo se envía a la GPU directamente desde el modo de usuario y la GPU administra las distintas colas de trabajo. Esta evolución hizo necesario eliminar la necesidad de que VidMm inspeccione y revise cada búfer de comandos antes de enviar a un motor de GPU.

Para ello, WDDM admite el direccionamiento virtual de GPU a partir de WDDM 2.0. En este modelo, a cada proceso se le asigna un espacio único de dirección virtual de GPU (GPUVA) en el que cada contexto de GPU se puede ejecutar. A una asignación creada o abierta por un proceso se le asigna una GPUVA única dentro del espacio de direcciones virtuales de GPU del proceso. Esta GPUVA asignada permanece constante y única durante la vigencia de la asignación. Por lo tanto, el controlador de pantalla en modo de usuario (UMD) puede hacer referencia a las asignaciones a través de su dirección virtual de GPU sin tener que preocuparse por el cambio de memoria física subyacente a lo largo de su duración.

Los motores individuales de una GPU pueden funcionar en modo físico o virtual:

• En el modo físico, el modelo de programación sigue siendo el mismo que con WDDM v1.x. El UMD sigue generando las listas de ubicaciones de asignación y revisión. Estas listas de asignación se envían con un búfer de comandos y se usan para aplicar revisiones a las direcciones físicas reales antes de enviarlas a un motor.

• En modo virtual, un motor hace referencia a la memoria a través de direcciones virtuales de GPU. El UMD genera búferes de comandos directamente desde el modo de usuario y usa nuevos servicios para enviar esos comandos al kernel. El UMD no genera listas de ubicaciones de asignación ni de revisión, aunque sigue siendo responsable de administrar la residencia de las asignaciones. Para obtener más información sobre la residencia de controladores, consulte Residencia de controladores en WDDM 2.0.

Modelos de memoria de GPU

WDDM v2 admite dos modelos distintos para el direccionamiento virtual de GPU, GpuMmu e IoMmu. Un controlador debe participar para admitir o ambos modelos. Un único nodo de GPU puede admitir ambos modos simultáneamente.

Modelo de GpuMmu

En el modelo de GpuMmu , VidMm administra la unidad de administración de memoria de GPU y las tablas de páginas subyacentes. VidMm también expone servicios al UMD que le permiten administrar la asignación de direcciones virtuales de GPU a las asignaciones. GpuMmu implica que la GPU usa tablas de páginas de GPU para acceder a los datos. Las tablas de páginas podrían apuntar a la memoria del sistema o a la memoria del dispositivo local.

Para más información, consulte Modelo de GpuMmu.

Modelo de IoMmu

En el modelo de IoMmu , la CPU y la GPU comparten un espacio de direcciones común y tablas de páginas de CPU. Solo se puede acceder a la memoria del sistema en este caso, por lo que IoMmu es adecuado para GPU integradas. IoMmu proporciona un modelo de programación más sencillo, donde tanto la GPU como la CPU pueden usar el mismo puntero para acceder a la memoria. No es necesario administrar un conjunto independiente de tablas de páginas en memoria accesible para GPU. Dicho esto, el modelo de IoMmu puede dar lugar a una degradación del rendimiento debido a la sobrecarga de la traducción de direcciones y la administración.

Para más información, consulte Modelo de IoMmu.