Partager via

Appareils perdus (Direct3D 9)

  • Article

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. Dans ce cas, le code d’erreur D3DERR_DEVICELOST est retourné par IDirect3DDevice9 ::P resent.

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 IDirect3DDevice9 ::Reset place l’appareil dans un état perdu.

Toutes les méthodes dérivées de 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 :

  • Échouer avec D3DERR_DEVICELOST : 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 de S_OK ou d’autres codes 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 ».
  • La fonction retourne un code de retour.
Différences entre Direct3D 9 et Direct3D 9Ex :
Un appareil Direct3D 9 retourne D3DERR_DEVICELOST. Une fois qu’il a été retourné par IDirect3DDevice9 ::P resent, le comportement d’émulation ne fonctionne plus et tous les appels futurs échouent jusqu’à ce que l’appareil soit correctement réinitialisé.
Un appareil Direct3D 9Ex ne retourne jamais D3DERR_DEVICELOST, mais peut retourner de nouveaux messages d’état (voir changements de comportement de l’appareil).

 

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. Ensuite, l’application appelle la méthode IDirect3DDevice9 ::Reset. La réinitialisation est la seule méthode qui a un effet lorsqu’un appareil est perdu et est la seule méthode par laquelle 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 dans D3DPOOL_DEFAULT, y compris celles créées par les méthodes IDirect3DDevice9 ::CreateRenderTarget et IDirect3DDevice9 ::CreateDepthStencilSurface méthodes.

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, telles que IDirect3DDevice9 ::D rawPrimitive, 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.

L’application peut déterminer ce qu’il faut faire lors de la rencontre d’un appareil perdu en interrogeant la valeur de retour de la méthode IDirect3DDevice9 ::TestCooperativeLevel.

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 en retournant D3D_OK, 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 appelle IDirect3DDevice9 ::P resent et 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. Cela signifie que l’application doit libérer toutes les chaînes d’échange créées avec IDirect3DDevice9 ::CreateAdditionalSwapChain et toutes les ressources placées dans la classe de mémoire D3DPOOL_DEFAULT. L’application n’a pas besoin de libérer des ressources dans les classes de mémoire D3DPOOL_MANAGED ou D3DPOOL_SYSTEMMEM. 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 à pas unique par le matériel à l’aide de IDirect3DDevice9 ::ValidateDevice. Cette méthode, généralement appelée lors de l’initialisation de l’application, retourne D3DERR_DEVICELOST si l’appareil a été perdu.

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.

En ce qui concerne les requêtes asynchrones, IDirect3DQuery9 ::GetData retourne D3DERR_DEVICELOST si l’indicateur FLUSH est spécifié, afin d’indiquer à l’application que IDirect3DQuery9 ::GetData ne retournera jamais S_OK.

L’opération de copie, IDirect3DDevice9 ::GetFrontBufferData, peut échouer avec D3DERR_DEVICELOST, car il n’existe aucune surface principale lorsque l’appareil est perdu. IDirect3DDevice9 ::CreateAdditionalSwapChain peut également échouer avec D3DERR_DEVICELOST, car une mémoire tampon de retour ne peut pas être créée lorsque l’appareil est perdu. Notez que ces cas sont la seule instance de D3DERR_DEVICELOST en dehors des IDirect3DDevice9 ::P resent, IDirect3DDevice9 ::TestCooperativeLevelet méthodes IDirect3DDevice9 ::Reset.

Nuanceurs programmables

Dans Direct3D 9, les nuanceurs de vertex et les nuanceurs de pixels n’ont pas besoin d’être recréés après la réinitialisation. Ils seront mémorisés. Dans les versions précédentes de DirectX, un appareil perdu exige la recréation des nuanceurs.

appareils Direct3D