Il était une fois, quand> était plus rapide que <... Attendez, quoi?
Je lis un excellent tutoriel OpenGL . C'est vraiment génial, crois-moi. Le sujet auquel je suis actuellement est le tampon Z. En plus d’expliquer le sujet, l’auteur dit que nous pouvons effectuer des tests de profondeur personnalisés, tels que GL_LESS, GL_ALWAYS, etc. personnalisé. Je comprends jusqu'ici. Et puis l'auteur dit quelque chose d'incroyable:
La plage zNear peut être supérieure à la plage zFar; si c'est le cas, alors le les valeurs d'espace de fenêtre seront inversées, en termes de ce qui constitue le plus proche ou le plus éloigné du spectateur.
Un peu plus tôt, il a été dit que la valeur Z de l'espace fenêtre de 0 est la plus proche et que 1 est le plus éloigné. Cependant, si nos valeurs Z de l'espace de clip ont été annulées, le la profondeur de 1 serait la plus proche de la vue et la profondeur de 0 serait de le plus éloigné. Cependant, si nous inversons la direction du test de profondeur (GL_LESS à GL_GREATER, etc.), nous obtenons exactement le même résultat. Donc, c'est vraiment juste un convention. En effet, inverser le signe de Z et le test de profondeur constituait jadis une optimisation des performances vitale pour de nombreux jeux.
Si je comprends bien, en termes de performances, retourner le signe de Z et le test de profondeur n’est rien d’autre que changer une comparaison < en une comparaison >. Donc, si je comprends bien et que l'auteur ne ment pas ou n'invente pas, changer < en > était une optimisation vitale pour de nombreux jeux.
Est-ce que l'auteur invente des choses, est-ce que je comprends mal quelque chose ou est-il bien vrai qu'une fois < était plus lent (vitalement, comme dit l'auteur) que >?
Merci d'avoir clarifié cette question assez curieuse!
Clause de non-responsabilité: Je suis pleinement conscient du fait que la complexité des algorithmes est la principale source d'optimisation. De plus, je soupçonne qu’aujourd’hui cela ne ferait aucune différence et je ne demande pas cela pour optimiser quoi que ce soit. Je suis extrêmement, douloureusement, peut-être même curieux.
Si je comprends bien, en termes de performances, renverser le signe de Z et le test de profondeur n’est rien de moins que de changer une comparaison <en comparaison>. Donc, si je comprends bien et que l'auteur ne ment pas ou n'invente pas, changer <to> était une optimisation vitale pour de nombreux jeux.
Je ne l'ai pas très bien expliqué, parce que ce n'était pas important. Je pensais juste que c’était un petit détail intéressant à ajouter. Je n'avais pas l'intention de passer en revue l'algorithme spécifiquement.
Cependant, le contexte est la clé. Je n'ai jamais dit qu'une comparaison <était plus rapide qu'une comparaison>. Rappelez-vous: nous parlons de tests de profondeur du matériel graphique, pas de votre processeur. Pas operator<.
Je faisais référence à une ancienne optimisation spécifique dans laquelle vous utiliseriez une image GL_LESS avec une plage de [0, 0,5]. Image suivante, vous rendez avec GL_GREATER avec une plage de [1.0, 0.5]. Vous faites un va-et-vient littéralement en "retournant le signe de Z et le test de profondeur" à chaque image.
Cela perd un peu de précision de profondeur, mais vous n'avez pas eu à effacer le tampon de profondeur, ce qui était une fois une opération plutôt lente. Comme le nettoyage en profondeur est non seulement gratuit ces jours-ci, mais en réalité plus rapide que cette technique, les gens ne le font plus.
La réponse est presque certainement que, quelle que soit l’incarnation de la puce + pilote utilisée, le Z hiérarchique ne fonctionnait que dans un sens - c’était un problème assez courant à l’époque. L'assemblage/la création de branches à bas niveau n'a rien à voir avec cela - la mise en tampon Z est effectuée dans un matériel à fonction fixe, et est mise en pipeline - il n'y a pas de spéculation et par conséquent, aucune prédiction de branche.
Une telle optimisation nuira aux performances de nombreuses solutions graphiques intégrées car elle rendra la résolution du framebuffer moins efficace. Effacer une mémoire tampon indique clairement au pilote qu'il n'a pas besoin de stocker et de restaurer la mémoire tampon lors de la division.
Peu d'informations d'arrière-plan: un rastériseur mosaïque/binning traite l'écran en nombre de très petites mosaïques qui entrent dans la mémoire intégrée. Cela réduit les écritures et les lectures dans la mémoire externe, ce qui réduit le trafic sur le bus de mémoire. Lorsqu'une image est terminée (le swap est appelé ou les FIFO sont vidées car elles sont pleines, les liaisons du tampon de mémoire changent, etc.), le tampon de mémoire doit être résolu; cela signifie que chaque bac est traité à son tour.
Le pilote doit supposer que le contenu précédent doit être préservé. La préservation signifie que le bac doit être écrit dans la mémoire externe, puis restauré à partir de la mémoire externe lorsque le bac est à nouveau traité. L'opération d'effacement indique au pilote que le contenu de la corbeille est bien défini: la couleur claire. C'est une situation triviale à optimiser. Il existe également des extensions permettant de "supprimer" le contenu du tampon.