Modèle de retournement DXGI
Windows 8 ajoute la prise en charge du modèle de présentation flip et de ses statistiques actuelles associées dans DXGI 1.2. Le modèle de présentation DXGI de Windows 8 est similaire au Présentation en mode flip direct3D 9EX de Windows 7. Les applications de présentation basées sur la fréquence d’images ou vidéo, telles que les jeux, peuvent bénéficier le plus en utilisant le modèle de présentation flip. Les applications qui utilisent le modèle de présentation inversé DXGI réduisent la charge des ressources système et augmentent les performances. Les applications peuvent également utiliser des améliorations de statistiques avec le modèle de présentation flip pour mieux contrôler le taux de présentation en fournissant des mécanismes de commentaires et de correction en temps réel.
- Comparaison du modèle de retournement DXGI et du modèle BitBlt
- Comment utiliser le modèle de retournement DXGI
- synchronisation frame des applications de modèle de basculement DXGI
- Éviter, détecter et récupérer des glitches
- rubriques connexes
Comparaison du modèle de retournement DXGI et du modèle BitBlt
Le runtime utilise le transfert de bloc de bits (bitblt) et retourne les modèles de présentation pour présenter du contenu graphique sur les moniteurs d’affichage. La plus grande différence entre les modèles de présentation bitblt et flip est la façon dont le contenu de la mémoire tampon back-tampon est obtenu dans windows 8 DWM pour la composition. Dans le modèle bitblt, le contenu de la mémoire tampon arrière est copié dans la surface de redirection sur chaque appel vers IDXGISwapChain1 ::P resent1. Dans le modèle de retournement, toutes les mémoires tampons de retour sont partagées avec le Gestionnaire de fenêtres de bureau (DWM). Par conséquent, le DWM peut composer directement à partir de ces mémoires tampons arrière 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 les statistiques présentes améliorées.
Si vous avez des composants hérités qui utilisent l’interface GDI (Windows Graphics Device Interface) pour écrire dans un HWND directement, utilisez le modèle bitblt.
Les améliorations des 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 bande passante mémoire et les lectures et écritures système d’applications fenêtrés qui choisissent un modèle de retournement par rapport au modèle bitblt.
Pas | Modèle BitBlt présent à 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 dans une surface de redirection DWM (lecture, écriture) |
Le runtime Direct3D transmet l’aire de l’application à DWM |
3. | Une fois la copie de surface partagée terminée, DWM restitue l’aire de l’application sur l’écran (lecture, écriture) |
DWM affiche l’aire de l’application sur l’écran (lecture, écriture) |
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 d’images fenêtré par DWM.
Comment utiliser le modèle de retournement DXGI
Les applications Direct3D 11.1 qui ciblent Windows 8 utilisent un modèle de retournement en créant la chaîne d’échange avec la valeur d’énumération DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL définie dans le SwapEffect membre 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 afin d’éviter une pénalité de performances suite à l’attente de DWM pour libérer la mémoire tampon de présentation précédente.
- Format pour DXGI_FORMAT_R16G16B16A16_FLOAT, DXGI_FORMAT_B8G8R8A8_UNORM ou DXGI_FORMAT_R8G8B8A8_UNORM
- count membre de la structure DXGI_SAMPLE_DESC que le membre SampleDesc spécifie à un et le membre Quality de DXGI_SAMPLE_DESC à zéro, car plusieurs 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 un modèle de retournement, vous pouvez utiliser des statistiques présentes en plein écran en mode fenêtré. Le comportement plein écran n’est pas affecté. Si vous passez NULL au paramètre pFullscreenDesc de IDXGIFactory2 ::CreateSwapChainForHwnd pour une chaîne d’échange fenêtrée et définissez SwapEffect sur DXGI_SWAP_EFFECT_FLIP_SEQUENTIAL, le runtime crée une mémoire tampon arrière supplémentaire et fait pivoter le handle qui appartient à la mémoire tampon qui devient la mémoire tampon frontale au moment de la présentation.
Lorsque vous utilisez un modèle de retournement, tenez compte des conseils suivants :
- Utilisez une chaîne d’échange de modèle de retournement par HWND. Ne ciblez pas plusieurs chaînes d’échange de modèle de retournement vers la même HWND.
- N’utilisez pas la chaîne d’échange de modèle de retournement avec la fonction ScrollWindow ou ScrollWindowEx. Certaines applications Direct3D utilisent les ScrollWindow de GDI et fonctions ScrollWindowEx pour mettre à jour le contenu de la fenêtre après un événement de défilement utilisateur. ScrollWindow et ScrollWindowEx effectuer 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 de la fenêtre visible à l’écran lorsque l’application est en mode fenêtré. Nous vous recommandons de ne pas utiliser les fonctions ScrollWindow et ScrollWindowEx de GDI et de redessiner plutôt le contenu GDI et Direct3D à l’écran en réponse au défilement.
- Utilisez un modèle flip dans un HWND qui n’est pas également ciblé par d’autres API, notamment le modèle de présentation DXGI bitblt, 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 via des mises à jour fragmentaires de Direct3D et GDI. Lorsque vous utilisez le modèle de retournement, seul le contenu Direct3D dans les chaînes d’échange de modèle de retournement que le runtime passe à DWM sont visibles. Le runtime ignore toutes les autres mises à jour de contenu direct3D ou GDI du modèle bitblt.
Synchronisation d’images d’applications de modèle de basculement DXGI
Les statistiques présentes sont des informations de minutage d’images que les applications multimédias utilisent pour synchroniser des flux vidéo et audio et récupérer à partir de problèmes de lecture vidéo. Les applications peuvent utiliser les informations de minutage des images dans les statistiques actuelles pour ajuster le taux de présentation de leurs images vidéo pour une présentation plus fluide. Pour obtenir des informations de statistiques, 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 inversé fournit des informations de statistiques dans les modes plein écran et fenêtrés. 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 afficher les statistiques du modèle flip, IDXGISwapChain ::GetFrameStatistics retourne DXGI_ERROR_FRAME_STATISTICS_DISJOINT dans ces situations :
- Premier appel à GetFrameStatistics, qui indique le début d’une séquence
- Modification du mode : mode fenêtré vers ou en plein écran ou plein écran vers les transitions plein écran
Les valeurs dans PresentRefreshCount, SyncRefreshCountet membres syncQPCTime de DXGI_FRAME_STATISTICS ont les caractéristiques suivantes :
- PresentRefreshCount est égal à SyncRefreshCount lorsque l’application présente sur chaque vsync.
- SyncRefreshCount est obtenu sur l’intervalle de synchronisation vsync lorsque le présent a été envoyé, SyncQPCTime correspond approximativement à l’heure associée à l’intervalle de synchronisation vsync.
La méthode IDXGISwapChain ::GetLastPresentCount retourne le dernier nombre actuel, c’est-à-dire l’ID actuel du dernier IDXGISwapChain1 ::P resent1 effectué par un appareil 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, tandis qu’en mode fenêtré, toutes les valeurs DXGI_FRAME_STATISTICS sont des zéros.
Éviter, détecter et récupérer des problèmes
Procédez comme suit pour éviter, détecter et récupérer des erreurs dans la présentation d’images :
File d’attente IDXGISwapChain1 ::P resent1 appels (autrement dit, appeler IDXGISwapChain1 ::P resent1 plusieurs fois, ce qui les amène à collecter dans une file d’attente).
Créez une structure de file d’attente présente pour stocker tous les éléments soumis correctement IDXGISwapChain1 ::P resent1's present ID (retourné par IDXGISwapChain ::GetLastPresentCount) et associés, calculés/attendus PresentRefreshCount valeurs.
Pour détecter un problème :
- Appelez IDXGISwapChain ::GetFrameStatistics.
- Pour cette trame, obtenez l’ID présent (PresentCount) et le nombre 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 présent et que vous avez précédemment stocké dans la structure de file d’attente actuelle.
- Si la PresentRefreshCount est ultérieure à la PresentRefreshCountattendue, une glitch s’est produite.
Pour récupérer à partir du problème :
Calculez le nombre d’images à ignorer pour récupérer à partir du problème. Par exemple, si l’étape 3 révèle que le nombre vsync attendu (PresentRefreshCount) pour un ID présent (PresentCount) est égal à 5 et que le nombre vsync réel pour l’ID présent est 8, le nombre d’images à ignorer pour récupérer à partir du 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.
Note
Si le glitch 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 toutes les présentations en attente en attente.
Voici un exemple de scénario de récupération à partir de problèmes dans la présentation d’images :
Dans l’exemple de scénario, vous vous attendez à ce que l’image A passe à l’écran sur un nombre vsync de 1. Mais vous détectez en fait le nombre vsync que le frame A apparaît sur 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, autrement dit, passer 0 au paramètre SyncInterval dans 3 appels à IDXGISwapChain1 ::P resent1. Dans l’exemple de scénario précédent, pour récupérer à partir du problème, vous avez besoin d’un total de 8 IDXGISwapChain1 ::P resent1 appels. Le 9e frame est alors visible conformément au nombre vsync attendu.
Voici une ligne de temps d’événements de présentation. Chaque ligne verticale représente un vsync. La direction horizontale est le temps, ce qui augmente à droite. Vous pouvez utiliser la figure pour imaginer comment des problèmes peuvent se produire.
La figure illustre cette séquence :
L’application se réveille sur vsync, affiche le bleu, appelle IDXGISwapChain1 ::P resent1, puis revient en veille.
L’unité de traitement graphique (GPU) se réveille de l’inactivité, effectue le rendu en bleu, puis revient en veille.
Le DWM se réveille au prochain vsync, compose du bleu dans sa mémoire tampon arrière, appelle IDXGISwapChain1 ::P resent1, puis revient en veille.
L’application se réveille, affiche le vert, appelle IDXGISwapChain1 ::P resent1, puis revient au sommeil.
Note
L’application s’exécute simultanément pendant que le GPU effectue la composition de bleu.
Ensuite, le GPU affiche le vert pour l’application.
Enfin, le convertisseur numérique en 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 actuelles et la façon dont les problèmes peuvent se produire. Par exemple, pour afficher une glitchE DWM pour la couleur verte apparaissant sur l’écran, imaginez élargir la zone verte/rouge afin que le côté droit de la zone verte/rouge corresponde au côté droit de la zone violette/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 à partir de la lecture des statistiques présentes.
Rubriques connexes