Chaîne d'échange DirectX 11 avec 7 mémoires tampon arrière

Question

J'ai un lecteur média privé qui fonctionne sous Windows 8 en mode bureau. La version Runtime DirectX est 11, mais la prise en charge du pilote graphique natif est pour DirectX 9.
Sur certains ordinateurs avec exactement la même configuration, je vois que le nombre de tampons arrière de la chaîne d'échange est de 2, et les performances sont excellentes, et sur d'autres le compte tampon arrière est 7 et il y a des trames abandonnées.
Je n'ai pas le code source de ce lecteur et je me demande quelle pourrait être la raison pour déterminer le nombre de compteurs de tampon arrière en cours d'exécution.
Quelqu'un peut-il expliquer pourquoi un tel compte backbuffer conduit à un tel changement de performance? Ou juste pointez-moi à la documentation pertinente qui explique les implications du nombre de backbuffers? En utilisant GPUView, je vois que lorsque le compte-rendu de backbuffer est de 2, le matériel fonctionne en mode synchronisé, c'est-à-dire un paquet dans la file d'attente matérielle dans chaque seconde VSync (Frame rate est de 30fps). backbuffers le travail est fait pour 5-7 images ensemble, puis quelques VSyncs vides, puis 5-7 cadres encore et ainsi de suite).

Merci d'avance!

Answer 1

Eh bien, j'ai reçu une réponse de Microsoft. C'est pour économiser de l'énergie lorsque vous travaillez sur DC (batterie) - de cette façon le processeur peut être réveillé pour traiter tous les tampons disponibles, les envoyer au GPU pour travailler et passer à un mode d'économie d'énergie plus profond pendant plus longtemps.

Answer 2

Je ne vois pas vraiment l'utilisation de plus de 4 tampons (tamponnage quad, qui est utilisé pour stereoscopy). La plupart des applications utilisent 2 buffers (double buffering) pour que l'application puisse commencer à dessiner l'image suivante sur le second buffer (arrière) pendant que le premier tampon (avant) est présenté au moniteur, sinon l'application devra attendre jusqu'à Le tampon avant est terminé de dessiner à l'écran avant de pouvoir commencer à dessiner l'image suivante. Le triple buffering se développe juste sur cette idée, de sorte qu'il y a deux tampons arrières. De cette façon, si l'application est capable de finir de dessiner un tampon entier plus vite que le tampon avant ne doit être présenté à l'écran, alors il peut commencer à dessiner l'image suivante sur le troisième tampon au lieu d'attendre que le tampon avant finisse de présenter. Je ne suis pas sûr si cela répond vraiment à votre question sur les autres applications utilisant 7 tampons, mais encore une fois je ne pense pas que ce soit nécessaire, car les moniteurs ne rafraîchissent généralement à une fréquence de 60 à 75Hz habituellement. Si votre application s'exécute si rapidement qu'elle est capable de dessiner 2 tampons avant la fin de la présentation du premier tampon, il suffit de mettre l'application en veille jusqu'à ce que le tampon avant soit terminé pour donner à d'autres programmes une chance d'utiliser le CPU. ou passez ce temps supplémentaire à effectuer d'autres traitements pour votre application. Si c'est un lecteur multimédia, vous pouvez passer plus de temps à faire des opérations plus coûteuses pour augmenter la qualité de la lecture du média.

Voici un lien décrivant la mise en mémoire tampon, mais ils ne parlent pas de plus de 4 tampons, probablement parce qu'il n'y en a pas besoin.

http://en.wikipedia.org/wiki/Multiple_buffering

post-scriptum peut-être la raison pour laquelle l'application perd probablement une fréquence d'image lors de l'utilisation de 7 tampons, est parce que l'application ne peut probablement pas continuer à écrire à tous les tampons avant qu'ils doivent être présentés à l'écran. Ce ne serait probablement pas le cas si le multi-threading était utilisé, car alors le tampon suivant pourrait être présenté à l'écran avant que l'application ait fini de dessiner dans tous les autres tampons arrières.