Compartir a través de


Residencia de controladores en WDDM 2.0

En esta sección se proporcionan detalles sobre los cambios de residencia del controlador para windows Display Driver Model (WDDM) 2.0. La funcionalidad descrita está disponible a partir de Windows 10.

En esta sección

Tema Descripción

Introducción a la residencia

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.

Seguimiento del uso de asignación

Con la lista de asignación que desaparece, el administrador de memoria de vídeo ya no tiene visibilidad sobre las asignaciones a las que se hace referencia en un búfer de comandos determinado. Como resultado de esto, el administrador de memoria de vídeo ya no está en una posición para realizar un seguimiento del uso de la asignación y controlar la sincronización relacionada. Esta responsabilidad se caerá ahora en el controlador en modo de usuario. En concreto, el controlador en modo de usuario tendrá que controlar la sincronización con respecto al acceso directo a la CPU a la asignación, así como cambiar el nombre.

Oferta y reclamación de cambios

En el caso de WDDM v2, los requisitos en torno a la oferta y la reclamación se están relajando. Los controladores en modo de usuario ya no son necesarios para usar la oferta y reclamar las asignaciones internas. Las aplicaciones inactivas o suspendidas se deshacerán de los recursos internos del controlador mediante la API trimque se introdujo en Microsoft DirectX 11.1.

Acceso a la asignación no residente

El acceso de la unidad de procesamiento gráfico (GPU) a las asignaciones que no son residentes es ilegal y provocará que un dispositivo se quite para la aplicación que generó el error.

Hay dos modelos distintos de control de este acceso no válido en función de si el motor de error admite el direccionamiento virtual de GPU o no:

  • En el caso de los motores que no admiten el direccionamiento virtual de GPU y usan la lista de ubicaciones de asignación y revisión para aplicar revisiones a las referencias de memoria, se produce un acceso no válido cuando el controlador en modo de usuario envía una lista de asignación que hace referencia a una asignación que no reside en el dispositivo (es decir, el controlador del modo de usuario no ha llamado a MakeResidentCb en esa asignación). Cuando esto ocurre, el kernel de gráficos coloca el contexto o dispositivo defectuoso en error.
  • Para los motores que admiten el direccionamiento virtual de GPU, pero acceden a una dirección virtual de GPU que no es válida, ya sea porque no hay ninguna asignación detrás de la dirección virtual o hay una asignación válida, pero no se ha hecho residente, se espera que la GPU genere un error de página irrecuperable en forma de interrupción. Cuando se produce la interrupción del error de página, el controlador de modo kernel debe reenviar el error al kernel de gráficos a través de una nueva notificación de error de página. Tras recibir esta notificación, el kernel de gráficos inicia un restablecimiento del motor en el motor con errores y coloca el contexto o dispositivo defectuoso en error. Si el restablecimiento del motor no se realiza correctamente, el kernel de gráficos promueve el error a una detección y recuperación de tiempo de espera (TDR) del adaptador completo.

Presupuestos de residencia de procesos

En WDDM v2, a los procesos se les asignarán presupuestos para la cantidad de memoria que pueden mantener residentes. Este presupuesto puede cambiar con el tiempo, pero generalmente solo se impondrá cuando el sistema esté bajo presión de memoria. Antes de Microsoft Direct3D 12, el presupuesto se controla mediante el controlador de modo de usuario en forma de notificaciones de recorte y errores MakeResident con STATUS_NO_MEMORY. TrimToBudget notification, Evict y failed MakeResident llama a all return the latest budget in the form of an integer NumBytesToTrim value that indicates how much needs to be trimmed in order to fit in the new budget.