Share via


Modèle de retournement DXGI

Windows 8 ajoute la prise en charge du modèle de présentation à retournement et des statistiques présentes associées dans DXGI 1.2. Windows 8 le modèle de présentation à retournement DXGI de Windows 7 est similaire à la présentation en mode de retournement Direct3D 9EX de Windows 7. Les applications de présentation vidéo ou basées sur la fréquence d’images, telles que les jeux, peuvent tirer le meilleur parti de l’utilisation du modèle de présentation à retournement. Les applications qui utilisent le modèle de présentation inverséE DXGI réduisent la charge des ressources système et augmentent les performances. Les applications peuvent également utiliser des améliorations des statistiques de présentation avec le modèle de présentation inversée pour mieux contrôler la vitesse de présentation en fournissant des mécanismes de rétroaction et de correction en temps réel.

Comparaison du modèle de retournement DXGI et du modèle BitBlt

Le runtime utilise les modèles de présentation de transfert de bloc de bits (bitblt) et de retournement pour présenter le contenu graphique sur les moniteurs d’affichage. La plus grande différence entre les modèles de présentation bitblt et flip réside dans la façon dont le contenu de la mémoire tampon principale arrive au Windows 8 DWM pour la composition. Dans le modèle bitblt, le contenu de la mémoire tampon d’arrière-mémoire est copié dans la surface de redirection à chaque appel à IDXGISwapChain1::P resent1. Dans le modèle de retournement, toutes les mémoires tampons d’arrière-mémoire sont partagées avec le Gestionnaire de fenêtres de bureau (DWM). Par conséquent, la DWM peut composer directement à partir de ces mémoires tampons d’arrière-mémoire sans aucune opération de copie supplémentaire. En général, le modèle de retournement est plus efficace. Le modèle de retournement fournit également d’autres fonctionnalités, telles que des statistiques actuelles améliorées.

Si vous avez des composants hérités qui utilisent l’interface GDI (Windows Graphics Device Interface) pour écrire directement dans un HWND , utilisez le modèle bitblt.

Les améliorations de performances du modèle de retournement DXGI sont significatives lorsque l’application est en mode fenêtré. La séquence de ce tableau et l’illustration comparent les utilisations de la bande passante mémoire et les lectures et écritures système d’applications fenêtrés qui choisissent le modèle inversé par rapport au modèle binaire.

Étape Modèle BitBlt présent dans DWM Modèle de retournement DXGI présent à DWM
1. L’application met à jour son frame (Écriture)
L’application met à jour son frame (Écriture)
2. Le runtime Direct3D copie le contenu de surface vers une surface de redirection DWM (lecture, écriture)
Le runtime Direct3D transmet la surface de l’application à DWM
3. Une fois la copie de surface partagée terminée, DWM restitue la surface de l’application à l’écran (lecture, écriture)
DWM restitue la surface de l’application à l’écran (lecture, écriture)

 

illustration d’une comparaison du modèle blt et du modèle de retournement

Le modèle inversé réduit l’utilisation de la mémoire système en réduisant le nombre de lectures et d’écritures par le runtime Direct3D pour la composition de cadres fenêtrés par DWM.

Comment utiliser le modèle de retournement DXGI

Les applications Direct3D 11.1 qui ciblent Windows 8 utilisent un modèle inversé en créant la chaîne d’échange avec la valeur d’énumération DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL définie dans le membre SwapEffect de la structure DXGI_SWAP_CHAIN_DESC1. Lorsque vous définissez SwapEffect sur DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL, définissez également ces membres de DXGI_SWAP_CHAIN_DESC1 sur les valeurs indiquées :

  • BufferCount à une valeur comprise entre 2 et 16 pour éviter une pénalité de performances en raison de l’attente de DWM pour libérer la mémoire tampon de présentation précédente.
  • Mettre en forme en DXGI_FORMAT_R16G16B16A16_FLOAT, DXGI_FORMAT_B8G8R8A8_UNORM ou DXGI_FORMAT_R8G8B8A8_UNORM
  • Count member of the DXGI_SAMPLE_DESC structure that the SampleDesc member to one and the Quality member of DXGI_SAMPLE_DESC to zero, car multiple sample antialiasing (MSAA) n’est pas pris en charge

Si vous utilisez DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL sur Windows 7 ou un système d’exploitation antérieur, la création de l’appareil échoue. Lorsque vous utilisez le modèle à retournement, vous pouvez utiliser les statistiques de présentation en plein écran en mode fenêtré. Le comportement plein écran n’est pas affecté. Si vous passez NULL au paramètre pFullscreenDescd’IDXGIFactory2::CreateSwapChainForHwnd pour une chaîne d’échange fenêtrée et que vous définissez SwapEffect sur DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL, le runtime crée une mémoire tampon d’arrière-plan supplémentaire et fait pivoter le handle qui appartient à la mémoire tampon qui devient la mémoire tampon avant au moment de la présentation.

Lorsque vous utilisez un modèle à retournement, tenez compte des conseils suivants :

  • Utilisez une chaîne de permutation de modèle à retournement par HWND. Ne ciblez pas plusieurs chaînes de permutation de modèle à retournement vers le même HWND.
  • N’utilisez pas de chaîne d’échange de modèle à retournement avec la fonction ScrollWindow ou ScrollWindowEx de GDI. Certaines applications Direct3D utilisent les fonctions ScrollWindow et ScrollWindowEx de GDI pour mettre à jour le contenu de la fenêtre après qu’un événement de défilement utilisateur se produit. ScrollWindow et ScrollWindowEx exécutent des bits de contenu de fenêtre à l’écran lorsque l’utilisateur fait défiler une fenêtre. Ces fonctions nécessitent également des mises à jour de modèle bitblt pour le contenu GDI et Direct3D. Les applications qui utilisent l’une ou l’autre fonction n’affichent pas nécessairement le contenu visible de la fenêtre qui défile à l’écran lorsque l’application est en mode fenêtré. Nous vous recommandons de ne pas utiliser les fonctions ScrollWindow et ScrollWindowEx de GDI, mais plutôt de redessiner le contenu GDI et Direct3D à l’écran en réponse au défilement.
  • Utilisez un modèle inversé dans un HWND qui n’est pas également ciblé par d’autres API, y compris le modèle de présentation bitblt DXGI, d’autres versions de Direct3D ou GDI. Étant donné que le modèle bitblt conserve une copie supplémentaire de la surface, vous pouvez ajouter GDI et d’autres contenus Direct3D au même HWND par le biais de mises à jour fragmentaires à partir de Direct3D et GDI. Lorsque vous utilisez le modèle à retournement, seul le contenu Direct3D dans les chaînes d’échange de modèle à retournement que le runtime passe à DWM est visible. Le runtime ignore toutes les autres mises à jour de contenu Direct3D ou GDI du modèle bitblt.

Synchronisation d’images des applications de modèle inversé DXGI

Les statistiques actuelles sont des informations de minutage d’images que les applications multimédias utilisent pour synchroniser les flux vidéo et audio et récupérer en cas de problèmes de lecture vidéo. Les applications peuvent utiliser les informations de minutage des images dans les statistiques actuelles pour ajuster la vitesse de présentation de leurs images vidéo pour une présentation plus fluide. Pour obtenir les informations statistiques actuelles, appelez la méthode IDXGISwapChain::GetFrameStatistics pour obtenir la structure DXGI_FRAME_STATISTICS . DXGI_FRAME_STATISTICS contient des statistiques sur les appels IDXGISwapChain1::P resent1 . Une chaîne d’échange de modèle à retournement fournit des informations de statistiques présentes en mode fenêtré et en mode plein écran. Pour les chaînes d’échange de modèle bitblt en mode fenêtré, toutes les valeurs DXGI_FRAME_STATISTICS sont des zéros.

Pour les statistiques de présentation de modèle à retournement, IDXGISwapChain::GetFrameStatistics retourne DXGI_ERROR_FRAME_STATISTICS_DISJOINT dans les situations suivantes :

  • Premier appel à GetFrameStatistics, qui indique le début d’une séquence
  • Changement de mode : transitions du mode fenêtré vers ou du mode plein écran ou du mode plein écran vers le mode plein écran

Les valeurs des membres PresentRefreshCount, SyncRefreshCount et SyncQPCTime de DXGI_FRAME_STATISTICS présentent les caractéristiques suivantes :

  • PresentRefreshCount est égal à SyncRefreshCount lorsque l’application est présente sur chaque vsync.
  • SyncRefreshCount est obtenu sur l’intervalle vsync lorsque le présent a été envoyé, SyncQPCTime est approximativement l’heure associée à l’intervalle vsync.

La méthode IDXGISwapChain::GetLastPresentCount retourne le dernier nombre actuel, c’est-à-dire l’ID actuel du dernier appel IDXGISwapChain1::P resent1 réussi effectué par un périphérique d’affichage associé à la chaîne d’échange. Cet ID actuel est la valeur du membre PresentCount de la structure DXGI_FRAME_STATISTICS . Pour les chaînes d’échange de modèle bitblt, en mode fenêtré, toutes les valeurs DXGI_FRAME_STATISTICS sont des zéros.

Éviter, détecter et récupérer des problèmes

Effectuez les étapes suivantes pour éviter, détecter et récupérer des problèmes dans la présentation de l’image :

  1. File d’attente DES appels IDXGISwapChain1::P resent1 (c’est-à-dire, appelez IDXGISwapChain1::P resent1 plusieurs fois, ce qui les amène à être collectés dans une file d’attente).

  2. Créez une structure de file d’attente actuelle pour stocker tous les idxGISwapChain1::P resent1 envoyés avec succès (retournés par IDXGISwapChain::GetLastPresentCount) et les valeurs PresentRefreshCount calculées/attendues associées.

  3. Pour détecter un problème :

    • Appelez IDXGISwapChain::GetFrameStatistics.
    • Pour ce frame, obtenez l’ID actuel (PresentCount) et le nombre de vsync où le système d’exploitation a présenté la dernière image au moniteur (PresentRefreshCount).
    • Récupérez le PresentRefreshCount attendu associé à l’ID actuel et que vous avez précédemment stocké dans la structure de file d’attente actuelle.
    • Si le PresentRefreshCount réel est plus tard que le PresentRefreshCount attendu, un problème s’est produit.
  4. Pour récupérer après le problème :

    • Calculez le nombre d’images à ignorer pour récupérer après le problème. Par exemple, si l’étape 3 révèle que le nombre vsync attendu (PresentRefreshCount) pour un ID actuel (PresentCount) est 5 et que le nombre vsync réel pour l’ID actuel est 8, le nombre d’images à ignorer pour récupérer après le problème est de 3 images.

    • Passez 0 au paramètre SyncInterval dans ce nombre d’appels à IDXGISwapChain1::P resent1 pour ignorer et ignorer ce nombre d’images.

      Notes

      Si le problème se compose d’un grand nombre d’images, appelez IDXGISwapChain1::P resent1 avec le paramètre Flags défini sur DXGI_PRESENT_RESTART pour ignorer et ignorer tous les cadeaux en attente en attente.

       

Voici un exemple de scénario de récupération après des problèmes dans la présentation de l’image :

illustration d’un exemple de scénario de récupération après des problèmes dans la présentation frame

Dans l’exemple de scénario, vous vous attendez à ce que l’image A s’affiche à l’écran avec un nombre vsync de 1. Mais vous détectez en fait le nombre de vsyncs dont la trame A apparaît à l’écran sous la forme 4. Par conséquent, vous déterminez qu’un problème s’est produit. Vous pouvez ensuite ignorer 3 images, c’est-à-dire passer 0 au paramètre SyncInterval en 3 appels à IDXGISwapChain1::P resent1. Dans l’exemple de scénario précédent, pour récupérer après le problème, vous avez besoin d’un total de 8 appels IDXGISwapChain1::P resent1 . Le 9e frame est alors visible en fonction du nombre de vsyncs que vous attendez.

Voici une ligne de temps des événements de présentation. Chaque ligne verticale représente un vsync. La direction horizontale est le temps, qui augmente à droite. Vous pouvez utiliser la figure pour imaginer comment les problèmes peuvent se produire.

illustration d’une ligne de temps d’événements de présentationl

La figure illustre cette séquence :

  1. L’application se réveille sur vsync, s’affiche en bleu, appelle IDXGISwapChain1::P resent1, puis se met en veille.

  2. L’unité de traitement graphique (GPU) se réveille de l’inactivité, effectue le rendu en bleu, puis se met en veille.

  3. Le DWM se réveille au vsync suivant, compose le bleu dans sa mémoire tampon arrière, appelle IDXGISwapChain1::P resent1, puis se met en veille.

  4. L’application se réveille, s’affiche en vert, appelle IDXGISwapChain1::P resent1, puis se met en veille.

    Notes

    L’application s’exécute simultanément pendant que le GPU effectue la composition de bleu.

     

  5. Ensuite, le GPU est rendu en vert pour l’application.

  6. Enfin, le convertisseur numérique-analogique (DAC) affiche les résultats de la composition DWM sur le moniteur sur le vsync suivant.

À partir de la ligne de temps, vous pouvez imaginer la latence des statistiques présentes et la façon dont les problèmes peuvent se produire. Par exemple, pour afficher un problème DWM pour la couleur verte qui apparaît à l’écran, imaginez élargir la zone vert/rouge afin que le côté droit de la zone vert/rouge corresponde au côté droit de la zone violet/rouge. Dans ce scénario, la DAC affiche deux images de bleu, puis le cadre vert. Vous pouvez voir que ce problème s’est produit lors de la lecture des statistiques présentes.

Amélioration de la présentation avec le modèle de retournement, les rectangles sale et les zones défilantes