Compartir a través de

TDR en Windows 8 y versiones posteriores

  • Artículo

A partir de Windows 8, el comportamiento de detección y recuperación de tiempo de espera (TDR) de GPU permite restablecer partes de adaptadores físicos individuales, en lugar de requerir un restablecimiento en todo el adaptador.

Para obtener más información, consulte Detección y recuperación de tiempo de espera (TDR).

Requisitos

  • Versión mínima de WDDM: 1.2
  • Versión mínima de Windows: 8
  • Implementación del controlador: solo gráficos completos y representación: obligatorio
  • Requisitos y pruebas de WHLK: Device.Graphics…TDRResiliency

Interfaz del controlador de dispositivo (DDI) de TDR

Para dar cabida a este cambio de comportamiento, los controladores de minipuerto de pantalla en modo kernel (KMD) pueden implementar estas funciones:

Un KMD indica la compatibilidad con estas funciones estableciendo el miembro DXGK_DRIVERCAPS.SupportPerEngineTDR, en cuyo caso debe implementar todas las funciones enumeradas.

Un controlador que admita estas funciones también debe admitir la sincronización de nivel cero para la función DxgkDdiCollectDbgInfo. Este requisito garantiza que las llamadas de KMD de nivel cero puedan continuar si la operación de restablecimiento no les afecta. Consulte los comentarios de DxgkDdiCollectDbgInfo.

Las estructuras siguientes están asociadas a las funciones anteriores:

Nodos

Como se usa en las funciones de TDR enumeradas, un nodo es una de varias partes de un único adaptador físico que se puede programar de forma independiente. Por ejemplo, un nodo 3D, un nodo de descodificación de vídeo y un nodo de copia pueden existir en el mismo adaptador físico, y a cada uno se le puede asignar un ordinal de nodo independiente. Esta asignación se almacena en el miembro DXGKARG_QUERYDEPENDENTENGINEGROUP.NodeOrdinal en una llamada a DxgkDdiQueryDependentEngineGroup.

El número de nodos del adaptador físico se notifica mediante el controlador de minipuerto de pantalla en el miembro NbAsymetricProcessingNodes de DXGK_DRIVERCAPS.GpuEngineTopology.

El valor ordinal del nodo se pasa al miembro NodeOrdinal de la estructura DXGKARG_CREATECONTEXT cuando se crea un contexto.

Motores

Como se usa en las funciones de DDI de TDR, un motor es uno de varios adaptadores físicos (o GPU) que actúan conjuntamente como un adaptador lógico. Dxgkrnl admite estas configuraciones, pero requiere que cada motor tenga el mismo número de nodos.

Por ejemplo, el programador de GPU considera que el motor 0 se corresponde con el adaptador físico 0. El motor 0 debe tener el mismo número de nodos que el motor 1, que corresponde al adaptador 1.

Valor ordinal del motor en la creación del contexto

Cuando se crea un contexto, se establece un solo bit correspondiente al valor ordinal del motor en el miembro EngineAffinity de la estructura DXGKARG_CREATECONTEXT. El miembro EngineOrdinal de esta y otras estructuras relacionadas con el programador es un índice de base cero. El valor de EngineAffinity es 1 <<EngineOrdinal y EngineOrdinal es la posición de bits más alta en EngineAffinity.

Paquetes no afectados por el restablecimiento del motor

Es posible que el programador de GPU pida al controlador que vuelva a enviar paquetes que se enviaron demasiado tarde a la cola de hardware del motor para que se procese completamente antes de que se complete el restablecimiento del motor. El controlador debe seguir estas instrucciones para volver a enviar estos paquetes:

  • Paquetes de paginación: el programador de GPU pide al controlador que vuelva a enviar paquetes de paginación con sus identificadores de barrera originales y en el mismo orden en que se enviaron originalmente. Los paquetes de este tipo se vuelven a enviar antes de que se agreguen nuevos paquetes a la cola de hardware.
  • Paquetes de representación: el programador de GPU asigna nuevos identificadores de barrera para los paquetes de representación y, a continuación, los vuelve a enviar.

Secuencia de llamadas para restablecer un motor

Cuando DxgkDdiResetEngine se realiza correctamente, el programador de GPU garantiza que el valor LastAbortedFenceId devuelto desde la llamada de restablecimiento del motor corresponde a:

  • Un identificador de barrera existente en la cola de hardware.
  • El último identificador de barrera completado en la GPU. Esta situación puede ocurrir cuando se vacía la cola de hardware después de que se detecte el tiempo de espera de GPU, pero antes de invocar la devolución de llamada de restablecimiento del motor.

El controlador siempre debe mantener el último valor de ID de barrera completado en la GPU porque ese identificador de barrera es necesario para establecer el miembro DmaPreempted.LastCompletedFenceId de una estructura de notificación de interrupción adelantada DXGKARGCB_NOTIFY_INTERRUPT_DATA. El último identificador de barrera completado solo debe avanzarse en estas situaciones:

  • Cuando se completa un paquete (sin adelantar), el último identificador de barrera completado debe establecerse en el identificador de barrera del paquete completado.
  • Cuando DxgkDdiResetEngine se realiza correctamente, el último identificador de barrera completado debe establecerse con el valor del miembro LastCompletedFenceId devuelto por la llamada de restablecimiento del motor.
  • Para el restablecimiento en todo el adaptador, el último identificador de barrera completado en todos los nodos debe avanzar hasta el último identificador de barrera enviado en el momento del restablecimiento.

Esta es una secuencia cronológica de un restablecimiento correcto del motor, como lo ve el programador de GPU:

  1. Se emite un intento de adelantamiento.

  2. Se detecta un tiempo de espera de GPU.

  3. El programador de GPU toma una instantánea de los identificadores de barrera enviados y completados por última vez, y se omiten las interrupciones del motor de tiempo de espera. Esta combinación es una operación atómica en el nivel de interrupción del dispositivo.

  4. Si no hay paquetes en la cola de hardware en este momento, sale. Esta situación puede ocurrir cuando se completó un paquete en el período de tiempo entre los pasos 2 y 3.

  5. Todos los DPC en cola se vacían.

  6. Preparación para el restablecimiento del motor.

  7. Se llama a DxgkDdiResetEngine.

  8. Si el miembro LastAbortedFenceId es menor que el último identificador de barrera completado o es mayor que el último identificador de barrera enviado, Dxgkrnl hace que se produzca una comprobación de errores del sistema. En un archivo de volcado de memoria, el mensaje Comprobación de errores 0x119 indica el error, que tiene estos cuatro parámetros:

    • 0xA, lo que significa que el controlador notificó un identificador de barrera anulado no válido
    • Valor LastAbortedFenceId devuelto por el controlador
    • Identificador de barrera completado por última vez
    • Parámetro interno del sistema operativo

  9. Si el valor LastAbortedFenceId es válido, continúa con la recuperación del restablecimiento del motor como se indica a continuación. Si el restablecimiento del motor afecta a un paquete de paginación, el programador de GPU sigue el restablecimiento del motor con un restablecimiento de todo el adaptador. Todos los dispositivos que poseen asignaciones a las que hace referencia ese paquete de paginación también se colocan en el estado de error. El propio dispositivo del sistema no se coloca en el estado de error y reanuda la ejecución una vez completado el restablecimiento.

Casos especiales

Una situación especial puede producirse cuando se completa un paquete en la GPU entre los pasos 3 y 7. En este caso, el controlador debe establecer LastAbortedFenceId en el identificador de barrera del último paquete completado si no hay paquetes en la cola de hardware desde el punto de vista del controlador. Desde el punto de vista del programador, parece que se anuló dicho paquete. Por lo tanto, el programador colocará el dispositivo correspondiente en un estado de error aunque el paquete se complete finalmente.

Si el controlador no puede realizar una operación de restablecimiento por cualquiera de los siguientes motivos, debe devolver un código de estado de error:

  • El estado del hardware no es válido.
  • El hardware no puede restablecer los nodos.

Si el programador de GPU recibe un código de estado de error, realiza una operación de restablecimiento y reinicio de todo el adaptador siguiendo el comportamiento de TDR antes de Windows 8.

Incluso si un controlador opta por el comportamiento de Windows 8 y versiones posteriores de TDR, hay casos en los que el programador de GPU solicita un restablecimiento y reinicio de todo el adaptador lógico. Por lo tanto, el controlador debe seguir implementando las funciones DxgkDdiResetFromTimeout y DxgkDdiRestartFromTimeout y su semántica sigue siendo la misma que antes de Windows 8. Cuando un intento de restablecer un adaptador físico con DxgkDdiResetEngine conduce a un restablecimiento del adaptador lógico, el comando !analyze del depurador de Windows muestra que el valor TdrReason del contexto de recuperación de TDR se establece con un nuevo valor de TdrEngineTimeoutPromotedToAdapterReset = 9.