Pourquoi l'application Direct3D fonctionne mieux en mode plein écran?

Question

Les performances d'une application Direct3D semblent être nettement meilleures en mode plein écran par rapport au mode fenêtré. Quelles sont les raisons techniques derrière cela?

Je suppose que cela a quelque chose à voir avec le fait qu’une application plein écran peut obtenir le contrôle exclusif de l’affichage. Mais pourquoi l’application ne peut pas obtenir le contrôle exclusif de la partie de l’écran (c’est-à-dire de la fenêtre) et bénéficier des mêmes avantages en termes de performances?

Answer 1

Voici les notes de la falaise sur la façon dont les choses fonctionnent en dessous.

L’écran de contrôle doit toujours être associé à une surface dite primaire pour pouvoir afficher quoi que ce soit, c’est-à-dire qu'une carte vidéo ne peut numériser qu'une surface dans la mémoire vidéo.

Lorsque l'application est en plein écran (et que tout a été configuré correctement pour permettre le basculement), la surface principale n'est qu'un des backbuffers de l'application et est basculée vers un autre backbuffer à chaque image. C’est le moyen le plus efficace de présenter à l’écran, mais cela nécessite une application permettant de posséder la totalité de la zone de contrôle (c’est-à-dire toute la surface principale).

Lorsqu'il n'y a pas d'application plein écran et que DWM est désactivé, la surface principale appartient à OS et chaque application à fenêtre effectue une fusion de la mémoire tampon de l'application sur une surface principale. Ce blit prend un certain temps sur le GPU (ainsi que les blits des autres applications visibles à l'écran), il n'est donc pas aussi efficace que la présentation en plein écran. XP a fonctionné de cette façon.

Lorsque DWM compose l'écran, les choses se compliquent encore. Ici, DWM est propriétaire de la surface principale et doit y dessiner des fenêtres d’application. Pour rendre cela possible, chaque fenêtre a une surface associée contenant son contenu, appelée surface de redirection (ce qui permet à DWM d'activer le fantôme de fenêtre, les effets de verre et tout ce qui est bien). Chaque fois que l'application D3D émet un cadre, elle ajoute un blit à une surface de redirection. De cette façon, plusieurs blits doivent se produire: blit à une surface de redirection par l'application, blit d'une surface de redirection au primaire par DWM, ce qui représente encore une fois un surcoût par rapport au plein écran.

Notez que tout ce travail supplémentaire concerne le processeur graphique, de sorte qu'il n'affecte pas les performances du processeur.

Stuff pour lire plus loin:

http://blogs.msdn.com/greg_schechter/ archive / 2006/03/19 / 555087.aspx

http://blogs.msdn.com/greg_schechter/ archive / 2006/05/02 / 588934.aspx

http://blogs.msdn.com/greg_schechter/ archive / 2006/03/05 / 544314.aspx

Answer 2

Il existe un peu sur MSDN cela signifie que le mode plein écran utilise le retournement de la mémoire tampon, s'il est configuré correctement, par opposition au blitting. C'est logique.

Bien sûr, vous pouvez (et d’une certaine manière le faire) attribuer le contrôle exclusif d’une partie de l’écran à une application, mais qu’advient-il du reste de l’écran? Vous devez toujours effectuer des vérifications d'occlusion, etc. sur le reste des fenêtres, et je pense que c'est ce qui cause les performances.

Answer 3

J'ajouterai au @ aib est que le reste de l'écran est géré par le système d'exploitation. Donc, si quelque chose doit être dessiné / travaillé simultanément, il doit y avoir un coup dur pour la performance.

Par exemple, si une vidéo est lue dans le lecteur Windows Media dans une fenêtre, puis démarrez Civilization dans une autre, lorsque Civ commencera à utiliser ses graphismes sophistiqués, il devra partager l'espace d'écran avec tout le reste (comme la vidéo.

Alors que si l'application DirectX est en plein écran, tout le reste pourrait être "mise à jour". ou "en train de jouer", mais pas en cours d'élaboration.

Answer 4

En gros, le matériel vidéo est entièrement dédié à l’application en mode exclusif.

Il n'y a pas de conflit pour les ressources vidéo (pipeline, mémoire de texture, etc.)

En particulier, le téléchargement de texture peut être un gros goulot d'étranglement. Moins vous devez le faire (parce que vous avez tout), mieux c'est.