Modelo de GpuMmu

En este artículo se describe el modelo de GpuMmu , que se introdujo en Windows 10 (WDDM 2.0).

En el modelo gpuMmu, la GPU tiene su propia unidad de administración de memoria (MMU) que traduce las direcciones virtuales de GPU por proceso a direcciones físicas.

Cada proceso tiene espacios de direcciones virtuales de CPU y GPU independientes que usan tablas de página distintas. El administrador de memoria de vídeo (VidMm) administra el espacio de direcciones virtuales de GPU de todos los procesos. VidMm también es responsable de asignar, expandir, actualizar, asegurar la residencia y liberar tablas de páginas. El formato de hardware de las tablas de páginas que usa la MMU de GPU es desconocido para VidMm y se abstrae mediante interfaces de controlador de dispositivo (DDIs). La abstracción admite una traducción de nivel multinivel, incluida una tabla de páginas de tamaño fijo y una tabla de página raíz que se puede cambiar de tamaño.

Aunque VidMm es responsable de administrar el espacio de direcciones virtuales de GPU y sus tablas de páginas subyacentes, VidMm no asigna automáticamente direcciones virtuales de GPU a asignaciones. Esta responsabilidad se encuentra en el controlador en modo de usuario (UMD).

VidMm ofrece dos servicios principales al UMD:

• Asignación y desasignación de memoria. El UMD puede asignar memoria de vídeo a través de la devolución de llamada Asignar existente y liberar esa memoria a través de la devolución de llamada Desasignar existente. Asignar devuelve un identificador a una asignación de VidMm al UMD. Una unidad de GPU puede operar en este identificador. Esta asignación hace referencia específicamente a la memoria de vídeo física, a la que un motor de GPU puede acceder y procesar a través de una lista de asignación.

• Administración del espacio de direcciones virtuales de GPU. Para los motores que se ejecutan en el modo virtual, una dirección virtual de GPU debe asignarse explícitamente a una asignación para poder acceder a ella virtualmente. Para ello, VidMm ofrece los servicios UMD para reservar o liberar direcciones virtuales de GPU y asignar intervalos de asignación específicos en el espacio de direcciones virtuales de GPU de un proceso. Estos servicios son flexibles y permiten el control detallado del UMD sobre un espacio de direcciones virtuales de proceso de la GPU. El UMD puede decidir asignar una dirección virtual de GPU específica a una asignación o permitir que VidMm elija automáticamente una disponible, posiblemente especificando algunas restricciones de direcciones virtuales de GPU mínimas y máximas. Una sola asignación puede tener varios mapeos de direcciones virtuales de GPU asociados y se proporcionan servicios al UMD para implementar el contrato de recursos de mosaico.

Del mismo modo, en una configuración del adaptador de pantalla vinculado, el UMD puede asignar explícitamente direcciones virtuales de GPU a instancias de asignación específicas. Para cada asignación, UMD puede elegir si la asignación debe ser a sí mismo o a una GPU específica compartida. En este modelo, las direcciones virtuales de CPU y GPU asignadas a una asignación son independientes. Un UMD puede decidir mantenerlos iguales en ambos espacios de direcciones o mantenerlos independientes.

Las direcciones virtuales de GPU se administran lógicamente en una granularidad fija de página de 4 KB a través de la interfaz DDI. Las direcciones virtuales de GPU pueden hacer referencia a asignaciones que residen en un segmento de memoria o en una memoria del sistema. La memoria del sistema se administra con granularidad física de 4 KB mientras que los segmentos de memoria se administran en 4 KB o 64 KB en la elección del controlador. Todas las asignaciones VidMm están alineadas y dimensionadas para ser un múltiplo del tamaño de página elegido por el controlador.

El acceso a un intervalo no válido de direcciones virtuales de GPU produce una infracción de acceso y una terminación del contexto o dispositivo que provocó el error de acceso. Para recuperarse de este error, VidMm inicia un reinicio del motor que, si no tiene éxito, se convierte en una recuperación de detección de tiempo de espera (TDR) a nivel del adaptador.

El modelo de GpuMmu se muestra en el diagrama siguiente: