Introducción a la residencia

Visión general

En la actualidad, el controlador en modo de usuario compila la información de la lista de ubicaciones de revisión y asignación junto con cada búfer de comandos que compila. El administrador de memoria de vídeo usa esta información para dos propósitos:

• La lista de asignación y la lista de ubicaciones de revisión se usan para aplicar búferes de comandos con direcciones de segmento reales antes de enviarse a un motor de unidad de procesamiento de gráficos (GPU). La compatibilidad con direcciones virtuales de GPU en windows Display Driver Model (WDDM) v2 elimina la necesidad de aplicar esta revisión.
• El administrador de memoria de vídeo usa la lista de asignación y la lista de ubicaciones de revisión para controlar la residencia de la asignación. El administrador de memoria de vídeo garantiza que las asignaciones a las que hace referencia un búfer de comandos se realicen residentes antes de que el búfer de comandos se envíe a la ejecución de un motor determinado.

Con la introducción del nuevo modelo de residencia, la residencia se mueve a una lista explícita en el dispositivo en lugar de la lista de búferes por comando. El administrador de memoria de vídeo garantizará que todas las asignaciones de una lista de requisitos de residencia de dispositivos en particular estén residentes antes de que los contextos que pertenezcan a ese dispositivo estén programados para su ejecución.

Para administrar la residencia, el controlador en modo de usuario tendrá acceso a dos nuevas interfaces de controlador de dispositivo (DDIs), MakeResident y Evict, así como ser necesario para implementar una nueva devolución de llamada TrimResidency . MakeResident agregará una o varias asignaciones a una lista de requisitos de residencia de dispositivos. Evict quitará una de las asignaciones de esa lista. El administrador de memoria de vídeo llamará a la devolución de llamada TrimResidency cuando necesite el controlador del modo de usuario para reducir su requisito de residencia.

MakeResident y Evict también se han actualizado para mantener un recuento de referencias interno, lo que significa que varias llamadas a MakeResident requerirán un número igual de llamadas de Evict para expulsar realmente la asignación.

En el nuevo modelo de residencia, la asignación de búferes por comando y la lista de ubicaciones de revisión se están eliminando gradualmente. Aunque estas listas existirán en algunos escenarios, ya no tendrán ningún control sobre la residencia.

Importante La residencia en WDDM v2 se controla exclusivamente mediante la lista de requisitos de residencia de dispositivos. Esto es cierto en todos los motores de la GPU y para cada API.

Lista de ubicaciones de asignación de revisiones y eliminación gradual

El rol de la lista de ubicaciones de asignación y revisión se reducirá significativamente con la introducción del nuevo modelo de residencia y en realidad desaparecerá completamente con la introducción de la programación asistida por hardware.

En el modelo de programación basada en paquetes, la lista de asignación seguirá existiendo de la siguiente manera:

• En el caso de los motores que no admiten el direccionamiento virtual de GPU, la lista de asignación y la lista de ubicaciones de revisión seguirán existiendo; sin embargo, se usarán exclusivamente con fines de aplicación de revisiones y ya no tendrán ningún control sobre la residencia. La lista de asignación y la lista de ubicaciones de revisión se proporcionarán tanto al controlador de modo de usuario como al controlador del modo kernel en los distintos DDIs habituales, pero las referencias a las asignaciones que no son residentes harán que el programador de GPU rechace el envío y coloque el dispositivo en error (perdido). Este modo de operación se considera heredado y esperamos que todos los motores de GPU obtengan compatibilidad con el direccionamiento virtual de GPU en futuras versiones de hardware. Se espera que este modo de operación se quite en futuras versiones del WDDM.
• En el caso de los motores que admiten el direccionamiento virtual de GPU, se agrega una nueva marca de creación de contexto (DXGK_CONTEXTINFO_NO_PATCHING_REQUIRED) para indicar que el contexto en particular no requiere ninguna aplicación de revisiones. Cuando se especifica esta marca, no se asignará ninguna lista de ubicaciones de revisión y solo se asignará una lista de asignación muy pequeña (16 entradas). La lista de asignación se usará para realizar un seguimiento de las referencias de escritura a las superficies principales y sin ningún otro propósito. El programador de GPU debe saber cuándo un búfer de comandos determinado está escribiendo en una superficie principal para que pueda sincronizar correctamente la ejecución de ese búfer con respecto a voltear potencialmente a la superficie principal.

De forma similar, la lista de asignación se usa en el controlador de modo kernel Ruta de acceso presente hoy para pasar información al controlador sobre el origen y el destino de la operación Present . En este contexto, la lista de asignación seguirá existiendo para pasar parámetros, pero la lista de asignación no se usará para la residencia. En las GPU que requieren aplicar revisiones a la lista de asignación actual contendrá información anterior a la revisión como lo hace hoy y el paquete Present se volverá a aplicar una revisión antes de que se programe si alguno de los recursos se mueve alrededor de la memoria entre el momento en que se ponen en cola al programador y la hora en que están programadas para su ejecución en la GPU.

En la tabla siguiente se resume cuándo un controlador WDDM v2 debe esperar recibir una lista de ubicaciones de asignación y revisión en varios controladores de modo de usuario y DDIs del controlador en modo kernel.

Motor de GPU	¿Lista de asignación?	¿Lista de ubicaciones de revisión?
No se admite ninguna dirección virtual de GPU (se requiere aplicación de revisiones, valor predeterminado)	Sí, tamaño completo, pero solo se usa con fines de aplicación de revisiones. Cualquier referencia a la asignación que no sea residente dará lugar a que el dispositivo de envío se ponga en error (perdido) y el envío rechazado por el programador.	Sí, tamaño completo.
Compatibilidad con direcciones virtuales de GPU (DXGK_CONTEXTINFO_NO_PATCHING_REQUIRED conjunto de marcas)	Sí, 16 entradas. Hace referencia a la superficie principal, si existe, que el búfer de comandos escribe en . Usado por el programador de GPU para la sincronización con labios que se producen en el controlador de pantalla. La superficie principal ya debe estar en la lista de requisitos de residencia del dispositivo o se rechazará la referencia.	No
Compatibilidad con direcciones virtuales de GPU + programación de hardware	No	No