Appareils perdus (Direct3D 9)

  • Article

Un appareil Direct3D peut être dans un état opérationnel ou 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 du focus du clavier dans une application en 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 des scénarios qui peuvent entraîner la perte d’un appareil n’est pas spécifié. Certains exemples classiques incluent la perte du 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 d’IUnknown sont garanties de fonctionner après la perte d’un appareil. Après la perte de l’appareil, chaque fonction dispose généralement des trois options suivantes :

  • Échec 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 de tout autre code de retour : si une fonction échoue en mode silencieux, l’application ne peut généralement pas faire la distinction entre le résultat de « réussite » 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é à partir de 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 renvoyer de nouveaux messages status (voir Modifications 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) après sa réinitialisation. 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 perdu à un état opérationnel. 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 .

Dans la plupart des cas, les appels à haute fréquence de Direct3D ne retournent aucune information indiquant si l’appareil a été perdu. 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 en cas de perte d’appareil en interrogeant la valeur de retour de la méthode IDirect3DDevice9::TestCooperativeLevel .

Opérations de verrouillage

En interne, Direct3D fait suffisamment de travail pour s’assurer qu’une opération de verrouillage réussit après la perte d’un appareil. Toutefois, il n’est pas garanti que les données de la ressource vidéo-mémoire seront exactes pendant l’opération de verrouillage. Il est garanti qu’aucun code d’erreur ne sera retourné. Cela permet d’écrire des applications sans se soucier de la 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 appartenant à l’adaptateur, il n’est pas possible de garantir l’allocation de la mémoire vidéo en cas de perte de l’appareil. 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 de 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’y a aucun problème de sur-allocation de la mémoire vidéo. Ces surfaces factices permettent aux opérations de verrouillage et de copie de fonctionner 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 pour 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. Les autres données d’état sont automatiquement détruites par la transition vers un état opérationnel.

Nous vous encourageons à 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, sinon 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 à passage unique par le matériel à l’aide de IDirect3DDevice9::ValidateDevice. Cette méthode, qui est 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 précédemment écrites à partir de ressources vidéo-mémoire 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 autorise l’échec de telles opérations de copie en cas de perte de l’appareil.

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 qu’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 arrière ne peut pas être créée lorsque l’appareil est perdu. Notez que ces cas sont les seuls instance de D3DERR_DEVICELOST en dehors des méthodes IDirect3DDevice9::P resent, IDirect3DDevice9::TestCooperativeLevel et 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. On se souviendra d’eux. Dans les versions précédentes de DirectX, un appareil perdu nécessitait la recréation de nuanceurs.

Appareils Direct3D