Prise en charge de WDDM pour la détection et la récupération du délai d’expiration

Cet article décrit comment le modèle de pilote d’affichage Windows (WDDM) prend en charge la détection et la récupération du délai d’attente (TDR). Il fournit une vue d'ensemble du processus TDR, explique comment fonctionne la détection de timeout dans WDDM et décrit les étapes à suivre pour se rétablir après un timeout.

Cet article s'adresse aux développeurs de pilotes d'affichage et graphiques.

Pour plus d’informations sur TDR dans WDDM, consultez les articles suivants :

• Modifications de TDR dans Windows 8 et versions ultérieures
• Synchronisation de threads et TDR
• Test et débogage TDR

Aperçu

TDR est une fonctionnalité de Windows qui détecte quand la carte graphique prend plus de temps que prévu pour effectuer une opération. Il réinitialise ensuite la carte graphique pour empêcher l’ensemble du système de ne pas répondre.

L’un des problèmes de stabilité les plus courants dans les graphiques se produit lorsqu’un ordinateur semble « bloquer » ou être complètement « figé » pendant qu’il traite en fait une commande ou une opération de l’utilisateur final. De nombreux utilisateurs attendent quelques secondes, puis décident de redémarrer l’ordinateur. L’apparence figée de l’ordinateur se produit fréquemment, car le GPU est occupé à traiter des opérations graphiques intensives, généralement pendant le jeu, et ne met donc pas à jour l’écran d’affichage. TdR permet au système d’exploitation de détecter que l’interface utilisateur n’est pas réactive.

La figure suivante montre le processus TDR.

Le système d’exploitation tente de détecter les situations dans lesquelles les ordinateurs semblent « figés ». Le système d’exploitation tente ensuite de récupérer dynamiquement des situations figées afin que les ordinateurs de bureau soient à nouveau réactifs, réduisant ainsi la situation dans laquelle les utilisateurs finaux redémarrent inutilement leurs systèmes.

Par défaut, le système d’exploitation effectue un contrôle de bogue sur l’ordinateur lors du sixième (ou plus) blocage de GPU lorsqu’il détecte que cinq (5) ou plusieurs blocages de GPU (0x117) et les récupérations suivantes se produisent en une (1) minute. Pour plus d’informations, consultez TdrLimitCount et TdrLimitTime.

À titre de note complémentaire, les délais d’expiration du moteur (0x141) n’augmentent pas le nombre de blocages GPU, bien que le système d’exploitation puisse convertir un délai d’expiration du moteur en un blocage GPU si le délai d’expiration du moteur échoue. Pour les délais d’expiration du moteur (0x141), le nombre maximal est inférieur à celui des délais d’expiration de l’adaptateur (0x117). Le processus de réinitialisation du moteur bloque l’accès GPU pour le processus à l’origine de tels délais d’expiration, et le système enregistre 0x142 pour indiquer cela. De cette façon, le processus défaillant n'effectue pas de vérification de bogue du système.

Détection du temps d'attente dans WDDM

Le planificateur GPU, qui fait partie du sous-système du noyau graphique DirectX (Dxgkrnl.sys), détecte quand le GPU prend plus que le temps autorisé pour exécuter une tâche particulière. Le planificateur GPU tente ensuite de préempter cette tâche spécifique. L’opération prédéfinie a un délai d’attente, qui est le délai d’expiration TDR réel. La période d’expiration par défaut dans Windows est de deux secondes. Si le GPU ne peut pas terminer ou préempter la tâche actuelle dans la période d'expiration TDR, le système d’exploitation diagnostique que le GPU est figé.

Pour empêcher la détection du délai d’expiration, les fournisseurs de matériel doivent s’assurer que les opérations graphiques (autrement dit, l’achèvement de la mémoire tampon DMA) ne prennent pas plus de deux secondes dans les scénarios de l’utilisateur final, tels que la productivité et le jeu de jeux.

Préparation de la récupération

Le planificateur GPU appelle la fonction DxgkDdiResetFromTimeout du pilote miniport d’affichage pour informer le pilote que le système d’exploitation a détecté un délai d’expiration. Le pilote doit ensuite se réinitialiser et réinitialiser le GPU. En outre, le pilote doit cesser d’accéder à la mémoire et ne doit pas accéder au matériel. Le système d’exploitation et le pilote collectent du matériel et d’autres informations d’état qui peuvent être utiles pour le diagnostic post-récupération.

Pour plus d’informations, consultez TDR dans Windows 8 et versions ultérieures.

Récupération du bureau

Le système d’exploitation réinitialise l’état approprié de la pile graphique. Le gestionnaire de mémoire vidéo, qui fait également partie de Dxgkrnl.sys, purge toutes les allocations de la mémoire vidéo. Le pilote miniport d’affichage réinitialise l’état du matériel GPU. La pile graphique effectue les actions finales et restaure le bureau à l’état réactif.

Le seul artefact visible lors de la détection d'un blocage à la réinitialisation est un scintillement d’écran. Ce scintillement se produit lorsque le système d’exploitation réinitialise certaines parties de la pile graphique, ce qui entraîne un redessinage d’écran. Le pilote miniport d’affichage peut éliminer ce redessinage lorsqu’il est conforme à WDDM 1.2 et ultérieur (voir Fournir des transitions d’état transparentes dans WDDM 1.2 et versions ultérieures).

Lorsque le système d’exploitation récupère correctement le bureau, il effectue les actions suivantes :

• Affiche un message d’information à l’utilisateur final, indiquant « Le pilote d'affichage a cessé de répondre et a été récupéré ».
• Enregistre le message précédent dans l’application Observateur d’événements et collecte les informations de diagnostic sous la forme d’un rapport de débogage. Si l’utilisateur final choisit de fournir des commentaires, le système d’exploitation retourne ce rapport de débogage à Microsoft via le mécanisme OCA (Online Crash Analysis).

Certaines applications DirectX héritées peuvent simplement afficher le noir à la fin de cette récupération, ce qui oblige l’utilisateur final à redémarrer ces applications. Les applications DirectX 9Ex et DirectX 10 et ultérieures bien écrites qui gèrent la technologie Device Remove continuent de fonctionner correctement. Une application doit libérer, puis recréer son appareil Microsoft Direct3D et tous les objets de l’appareil.

Synchronisation de threads et TDR

Pour plus d’informations, consultez synchronisation de threads et TDR .

Test et débogage de TDR

Pour obtenir plus d’informations, consultez Tests et débogage TDR.