Partager via


Appareils perdus

Un appareil Direct3D peut être dans un état opérationnel ou un état perdu. L’état opérationnel est l’état normal de l’appareil dans lequel l’appareil s’exécute et présente tout le rendu comme prévu. L’appareil effectue une transition vers l’état perdu lorsqu’un événement, tel que la perte de focus clavier dans une application plein écran, rend le rendu impossible. L’état perdu est caractérisé par l’échec silencieux de toutes les opérations de rendu, ce qui signifie que les méthodes de rendu peuvent retourner des codes de réussite même si les opérations de rendu échouent.

Par conception, l’ensemble complet de scénarios qui peuvent entraîner la perte d’un appareil n’est pas spécifié. Certains exemples classiques incluent la perte de focus, par exemple lorsque l’utilisateur appuie sur ALT+TAB ou lorsqu’une boîte de dialogue système est initialisée. Les appareils peuvent également être perdus en raison d’un événement de gestion de l’alimentation ou lorsqu’une autre application suppose une opération en plein écran. En outre, toute défaillance de la réinitialisation d’un appareil place l’appareil dans un état perdu.

Toutes les méthodes dérivées d’IUnknown sont garanties pour fonctionner une fois qu’un appareil est perdu. Après la perte d’appareil, chaque fonction a généralement les trois options suivantes :

  • Échec avec une erreur « appareil perdu » : cela signifie que l’application doit reconnaître que l’appareil a été perdu, afin que l’application identifie que quelque chose ne se produit pas comme prévu.
  • Échec silencieux, retour S_OK ou tout autre code de retour : si une fonction échoue silencieusement, l’application ne peut généralement pas faire la distinction entre le résultat du « succès » et un « échec silencieux ».
  • Retourne un code de retour.

Réponse à un appareil perdu

Un appareil perdu doit recréer des ressources (y compris des ressources de mémoire vidéo) une fois qu’il a été réinitialisé. Si un appareil est perdu, l’application interroge l’appareil pour voir s’il peut être restauré à l’état opérationnel. Si ce n’est pas le cas, l’application attend que l’appareil puisse être restauré.

Si l’appareil peut être restauré, l’application prépare l’appareil en détruisant toutes les ressources de mémoire vidéo et toutes les chaînes d’échange. La réinitialisation est la seule procédure qui a un effet lorsqu’un appareil est perdu et est la seule façon dont une application peut changer l’appareil d’un état opérationnel perdu. La réinitialisation échoue, sauf si l’application libère toutes les ressources allouées, y compris les cibles de rendu et les surfaces de gabarit de profondeur.

Dans la plupart des cas, les appels à haute fréquence de Direct3D ne retournent aucune information sur la perte de l’appareil. L’application peut continuer à appeler des méthodes de rendu, sans recevoir de notification d’un appareil perdu. En interne, ces opérations sont ignorées jusqu’à ce que l’appareil soit réinitialisé à l’état opérationnel.

Opérations de verrouillage

En interne, Direct3D effectue suffisamment de travail pour s’assurer qu’une opération de verrouillage réussit une fois qu’un appareil est perdu. Toutefois, il n’est pas garanti que les données de la ressource de mémoire vidéo soient précises pendant l’opération de verrouillage. Il est garanti qu’aucun code d’erreur ne sera retourné. Cela permet aux applications d’être écrites sans souci de perte d’appareil pendant une opération de verrouillage.

Ressources

Les ressources peuvent consommer de la mémoire vidéo. Étant donné qu’un appareil perdu est déconnecté de la mémoire vidéo détenue par l’adaptateur, il n’est pas possible de garantir l’allocation de la mémoire vidéo lorsque l’appareil est perdu. Par conséquent, toutes les méthodes de création de ressources sont implémentées pour réussir, mais n’allouent en fait que la mémoire système factice. Étant donné que toute ressource de mémoire vidéo doit être détruite avant que l’appareil ne soit redimensionné, il n’existe aucun problème de sur-allocation de mémoire vidéo. Ces surfaces factices permettent aux opérations de verrouillage et de copie d’apparaître normalement jusqu’à ce que l’application découvre que l’appareil a été perdu.

Toute la mémoire vidéo doit être libérée avant qu’un appareil puisse être réinitialisé d’un état perdu à un état opérationnel. D’autres données d’état sont automatiquement détruites par la transition vers un état opérationnel.

Vous êtes encouragé à développer des applications avec un chemin de code unique pour répondre à la perte d’appareil. Ce chemin de code est susceptible d’être similaire, s’il n’est pas identique, au chemin de code pris pour initialiser l’appareil au démarrage.

Données récupérées

Direct3D permet aux applications de valider les états de texture et de rendu par rapport au rendu unique par le matériel.

Direct3D permet également aux applications de copier des images générées ou écrites précédemment à partir de ressources de mémoire vidéo vers des ressources de mémoire système non volatiles. Étant donné que les images sources de ces transferts peuvent être perdues à tout moment, Direct3D permet à ces opérations de copie d’échouer lorsque l’appareil est perdu.

Les opérations de copie peuvent échouer, car il n’existe aucune surface principale lorsque l’appareil est perdu. La création de chaînes d’échange peut également échouer, car une mémoire tampon de retour ne peut pas être créée lorsque l’appareil est perdu.

Appareils