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 processeur ou GPU. L’implémentation de la suspension et de la reprise par les applications Game OS fait partie des exigences XBOX (XR) pour XBOX One. Si une application reçoit l’événement Suspending, elle doit appeler SuspendX. Sinon, l’application 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 enregistré 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 toute API Direct3D entre les appels Direct3D SuspendX et ResumeX, comme 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.

Incidences 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, il n’est pas possible pour le système de restaurer de façon sécuritaire la planification établie et son état temporel après l’événement de reprise subséquent. Afin d’offrir un comportement robuste et prévisible, la planification des images de l’application est effacée par le système pendant le 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 abandonnées. Par conséquent, après le retour de l’appel ResumeX, l’application doit rétablir la planification des images souhaitée au moyen d’appels à ID3D12Device::SetFrameIntervalX et à ID3D12Device::ScheduleFrameEventX avant de se mettre en attente de sa prochaine origine d’image. L’application doit supposer 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 pendant qu’elle attend qu’une origine d’image (ou un autre événement d’image) soit signalée lors d’un appel à ID3D12Device::WaitFrameEventX. Si le thread de l’application responsable de l’appel de 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 qu’il ait été lancé avant l’appel SuspendX) peut échouer avec D3DERR_DEVICEREMOVED.
Les statistiques d’images ne sont pas conservées d’un côté à l’autre des limites de suspension/reprise. Tous les jetons d’image émis avant une suspension seront considérés comme non valides après la reprise, et les appels ID3D12Device::GetFrameStatisticsX qui y font référence pour obtenir les informations statistiques associées échoueront.

Modèle d’appel

Les applications Game OS reçoivent des notifications au moyen de rappels inscrits. Il n’y a 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, cela permet d’appeler directement les méthodes Direct3D SuspendX et ResumeX à partir du gestionnaire de messages 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 les 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). Lorsque l’appel SuspendX est effectué, le runtime Direct3D enregistre l’état des registres de contexte, de la RAM CE, de l’ESRAM, du magasin de données global (GDS), des mémoires tampons d’index, de certains registres du GPU (les registres du GPU ne sont pas tous 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 : Non restreint, Restreint, Suspendu et Arrêté. Pour plus d’informations, consultez Gestion de la durée de vie des processus (Developer Education Materials, All NDA Whitepapers).

Tests

Pour permettre des tests réalistes de la suspension et de la reprise, la commande à distance Gestion des applications (xbapp.exe) offre des options. Consultez la section sur xbapp suspend dans cette rubrique, et notez l’exemple de fichier de commandes.
Last modified on October 6, 2026