Skip to main content
Cette rubrique décrit le processus de suspension et de reprise du rendu graphique Direct3D d’un titre Game OS.

Événements de suspension et de reprise

Sur XBOX One, les applications Game OS peuvent être suspendues et reprises par la gestion de la durée de vie des processus (PLM). À l’état suspendu, la mémoire de l’application reste intacte, mais l’application ne dispose d’aucune ressource CPU ou GPU. L’implémentation de la suspension et de la reprise par les applications Game OS fait partie des exigences XBOX (XR) pour la XBOX One. Si une application reçoit l’événement Suspending, elle doit appeler SuspendX. Sinon, elle sera arrêtée. Les appels à SuspendX et à ResumeX doivent tous deux s’exécuter sur le thread de rendu du titre afin de garantir que l’état du GPU est correctement sauvegardé par l’appel à SuspendX. Lorsque le titre est suspendu, il ne peut rien afficher tant que le GPU n’a pas repris. L’appel de n’importe quelle API Direct3D entre les appels Direct3D SuspendX et ResumeX, par exemple l’appel des méthodes ID3D12GraphicsCommandList::DrawInstanced ou ID3D12CommandQueue::ExecuteCommandLists, lève une exception. Voici les méthodes de suspension et de reprise de Direct3D sur XBOX One. Ces méthodes doivent être appelées sur la file d’attente de commandes graphiques, car elles ne sont pas prises en charge par les files d’attente de calcul et de copie.

Conséquences sur la planification des images et les statistiques

La suspension de l’application introduit une perturbation non déterministe dans la planification des images qu’elle a établie. Étant donné le caractère imprévisible du moment où un événement de suspension peut se produire, le système ne peut pas restaurer en toute sécurité la planification établie et son état temporel après l’événement de reprise qui suit. Pour garantir un comportement robuste et prévisible, le système efface la planification des images de l’application lors du traitement de l’appel à SuspendX. La file d’attente de présentation est vidée vers l’écran, et toutes les images commencées par WaitFrameEventX mais pas encore envoyées à l’écran au moyen de PresentX sont ignorées. Par conséquent, après le retour de l’appel à ResumeX, l’application doit rétablir la planification des images souhaitée en appelant ID3D12Device::SetFrameIntervalX et ID3D12Device::ScheduleFrameEventX avant d’attendre sa prochaine origine d’image. L’application doit considérer que le pipeline d’images est vide après sa reprise.
Il peut être courant qu’une application reçoive un événement de suspension alors qu’elle attend qu’une origine d’image (ou un autre événement d’image) soit signalée pendant un appel à ID3D12Device::WaitFrameEventX. Si le thread de l’application chargé d’appeler SuspendX sur la file d’attente de commandes graphiques est différent de celui utilisé pour attendre les événements d’image, l’appel à ID3D12Device::WaitFrameEventX (bien que lancé avant l’appel à SuspendX) peut échouer avec D3DERR_DEVICEREMOVED.
Les statistiques d’images ne sont pas conservées d’une suspension/reprise à l’autre. Tous les jetons d’image créés avant une suspension sont considérés comme non valides après la reprise, et les appels à ID3D12Device::GetFrameStatisticsX qui y font référence pour obtenir les statistiques associées échouent.

Modèle d’appel

Les applications Game OS reçoivent des notifications au moyen de rappels inscrits. Il n’existe qu’un événement de suspension et un événement de reprise, et il n’y a plus de phase d’activation explicite. Une approche d’implémentation simple consiste à gérer la suspension et la reprise en publiant un message WM_USER.
Si la pompe de messages s’exécute sur un thread de rendu disposant d’un accès exclusif à la file d’attente de commandes graphiques, il est possible d’appeler directement les méthodes Direct3D SuspendX et ResumeX depuis le gestionnaire du message WM_USER. Tous les threads distincts qui soumettent du travail à des files d’attente de commandes de calcul asynchrone ou de copie doivent recevoir l’instruction de cesser les opérations sur ces files d’attente avant l’appel à SuspendX.
Si la pompe de messages s’exécute sur un thread différent d’un ou de plusieurs des threads ayant accès à la file d’attente de commandes graphiques, elle doit demander au thread de rendu d’effectuer l’appel à SuspendX et de cesser d’utiliser la file d’attente (et gérer de la même façon ResumeX et les opérations associées). Lors de l’appel à SuspendX, le runtime Direct3D enregistre l’état des registres de contexte, de la CE RAM, de l’ESRAM, du magasin de données global (GDS), des tampons d’index, de certains registres du GPU (tous les registres du GPU ne sont pas lisibles) et de la mémoire interne du CP. Cet état est restauré lors de l’appel à ResumeX. Le système PLM définit quatre états dans lesquels une application peut se trouver : Unconstrained (non contraint), Constrained (contraint), Suspended (suspendu) et Terminated (arrêté). Pour plus d’informations, consultez Gestion de la durée de vie des processus (Developer Education Materials, All NDA Whitepapers).

Test

Pour permettre un test réaliste de la suspension et de la reprise, la commande à distance Gestion des applications (xbapp.exe) propose des options. Consultez la section relative à xbapp suspend dans cette rubrique et notez l’exemple de fichier batch.
Last modified on October 6, 2026