Est double mise en mémoire tampon plus besoin de

Comme les cartes d'aujourd'hui semblent garder une liste de rendre les commandes et les rincer uniquement sur un appel à glFlush ou glFinish, est le double buffering vraiment besoin de plus? Un OpenGL jeu que je suis en train d'élaborer sur Linux (ATI Mobility radeon carte) avec SDL/OpenGL fait scintille moins quand SDL_GL_swapbuffers() est remplacé par glFinish() et avec SDL_GL_SetAttribute(SDL_GL_DOUBLEBUFFER,0) dans le code d'initialisation. Est-ce un cas particulier de ma carte d'identité ou de telles choses probablement sur toutes les cartes?

EDIT: j'ai découvert que la cause de cela est KWin. Il semble que comme datenwolf dit, la composition, sans synchronisation a été la cause. Quand j'ai éteint KWin la composition, le jeu fonctionne très bien sans AUCUNE code source patchs

OriginalL'auteur Sudarshan S | 2011-07-01

  1. 19

    Double mise en mémoire tampon et glFinish sont deux choses très différentes.

    glFinish bloque le programme, jusqu'à ce que toutes les opérations de dessin sont terminés.

    Double mise en mémoire tampon est utilisé pour masquer le processus de rendu de l'utilisateur. Sans le double buffering, chaque opération de dessin deviendraient visibles immédiatement, en supposant que l'affichage de la fréquence de rafraîchissement est infiniment élevé. Dans la pratique, vous obtiendrez une partie des artefacts, comme les parties de la scène visible dans un état, le reste n'est pas visible ou dans un autre état, l'image est peut-être incomplet, etc. Double mise en mémoire tampon permet d'éviter cela en premier rendu dans un tampon d'arrière-plan, et seulement après que le rendu a été fini échangeant ce retour avec le tampon, qui est envoyé vers le périphérique d'affichage.

    Aujourd'hui la composition de gestion de la fenêtre devient prédominante: Windows a Aero, MacOS X Quartz Extreme et sur Linux, au moins, de l'Unité et de la GNOME3 shell utilisez la composition, si disponible. Le point est: Compositing techniquement crée le doublebuffering: Windows dessiner à l'écran des tampons et des de ces le dernier écran est composé. Donc, si vous êtes en cours d'exécution sur une machine avec le compositing, puis double mise en mémoire tampon est une sorte de redondant si elle est effectuée dans votre programme, et tout ce qu'elle prenait était une sorte de mécanisme de synchronisation, de dire le compositeur lors de la prochaine image est prête. MacOS X a cela. X11 manque toujours d'un bon programme de synchronisation, voir ce post sur le maillist: http://lists.freedesktop.org/archives/xorg/2004-May/000607.html

    TL;DR: Double mise en mémoire tampon et glFinish sont des choses différentes, et vous avez besoin de double mise en mémoire tampon (en quelque sorte) afin de rendre les choses bien.

    Le post mentionné est de plus de 6 ans. Ne X11 manque toujours un schéma de synchronisation? Et ce que sur Windows?
    En plus de datenwolf de l'explication, vous devez noter que vous aurez en général, jamais vous voulez l'appeler glFlush ou glFinish, sauf peut-être dans quelques très très très rares cas particuliers. glFinish ne fait rien que (wgl|glx)SwapBuffers n'est pas déjà le (présumé que la vsync est activée), et glFlush seulement vide la file d'attente des commandes et signaux le serveur pour commencer le traitement, ce qui n'a rien dans le meilleur des cas (mais il est inutile d'appel et de changement de contexte), qui entraîne une dégradation des performances dans le pire des cas (en raison de la sous-optimisation de la planification des ressources GPU).
    Idéalement, vous aurez envie de jeter autant de commandes à l'GL comme vous pouvez, avec des dépendances de se propager aussi loin que vous le pouvez (si vous utilisez une texture, d'envoyer d'abord les commandes permettant de définir la texture de l'image, réglez la texture de l'état, etc, puis de l'envoyer certaines commandes qui ne sont autre chose, et ensuite seulement de dessiner quelque chose qui utilise cette texture). Cela garantit que: a) les commandes dans votre flux de commande sont moins susceptibles de bloquer en raison des dépendances et b) le conducteur peut programmer quelques autres commandes à utiliser le GPU (OpenCL ou un autre programme?) si les commandes dans votre file d'attente de décrochage.
    Avec cela, votre programme doit toujours maintenu en marche à la vitesse maximale sans aucun retard (ne dorment jamais ou tel!), et la synchronisation verticale va le bloquer lorsque c'est approprié et ne fait pas de mal. Ainsi, votre programme ne brûle pas de CPU à 100%, mais fonctionne à une vitesse optimale.
    S: Malheureusement non, pas de réel avantage a été faite, ce qui est un peu dommage. Il est vraiment nécessaire de bien, mais on doit admettre que le sujet est hautement non trivial. ATM cela va à l'aide de la XDamage extension à dire le compositeur de l'image a été fini. Mais alors, vous êtes toujours à gauche avec la tâche, de façon à vide jusqu'à la prochaine Synchro. Si vous venez de glXSwapBuffers vous allez introduire un retard de cadre parce que glXSwapBuffers permet également de bloquer votre programme.

    OriginalL'auteur datenwolf

  2. 2

    Je m'attends à ce qu'il a plus à voir avec ce que vous êtes rendu ou votre matériel que tout ce qui pourrait être généralisée à quelque chose de pas sur votre machine. Donc, non: ne pas essayer de le faire.

    Oh, et n'oubliez pas multisampling. De nombreuses implémentations seulement multi-échantillons de la mémoire tampon d'arrière; le tampon n'est pas multisampled. Faire un swap sera sous-échantillonner à partir de la multisampled tampon.

    OriginalL'auteur Nicol Bolas