Il était une fois, quand > était plus rapide que < ... Attends, quoi ?

Question

Je suis en train de lire un tutoriel OpenGL impressionnant . C'est vraiment génial, croyez-moi. Le sujet que j'aborde actuellement est le Z-buffer. En plus d'expliquer ce dont il s'agit, l'auteur mentionne que nous pouvons effectuer des tests de profondeur personnalisés, tels que GL_LESS, GL_ALWAYS, etc. Il explique également que la signification réelle des valeurs de profondeur (ce qui est supérieur et ce qui ne l'est pas) peut également être personnalisée. Je comprends jusqu'à présent. Et puis l'auteur dit quelque chose d'incroyable :

La plage zNear peut être supérieure à la plage zFar ; si c'est le cas, les valeurs de l'espace de la fenêtre sont les suivantes valeurs de l'espace de la fenêtre seront inversées, en termes de ce qui constitue le plus proche ou le plus éloigné de l'observateur.

On a dit plus haut que la valeur Z de 0 dans l'espace fenêtre est la plus proche et la plus proche de la valeur Z dans l'espace fenêtre. 1 est la plus éloignée. Cependant, si les valeurs Z de notre espace de clip étaient annulées, la profondeur de 1 serait la plus proche de la vue et la profondeur de 0 serait la plus éloignée. profondeur de 1 serait la plus proche de la vue et celle de 0 serait la plus éloignée. la plus éloignée. Pourtant, si nous inversons la direction du test de profondeur (GL_LESS vers GL_GREATER, etc.), nous obtenons exactement le même résultat. Il ne s'agit donc que d'une convention. En effet, inverser le signe de Z et le test de profondeur était autrefois une optimisation vitale des performances pour de nombreux jeux.

Si je comprends bien, du point de vue des performances, inverser le signe de Z et le test de profondeur n'est rien d'autre que changer un < par rapport à un > comparaison. Donc, si je comprends bien et que l'auteur ne ment pas ou n'invente pas des choses, alors changer < a > utilisé pour être 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-ce que c'est vraiment le cas qu'une fois < était plus lent ( vitalement (comme le dit l'auteur) que > ?

Merci de clarifier cette question assez curieuse !

_{Avertissement : je suis pleinement conscient que la complexité des algorithmes est la source principale des optimisations. 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 juste extrêmement, douloureusement, peut-être prohibitivement curieux.}

Answer 1

Si je comprends bien, en termes de performances, inverser le signe de Z et du test de profondeur n'est rien d'autre que de changer une comparaison < en une comparaison >. Donc, si je comprends bien et que l'auteur ne ment pas ou n'invente pas des choses, le changement de < en > était une optimisation vitale pour de nombreux jeux.

Je ne l'ai pas particulièrement bien expliqué, car ce n'était pas important. J'ai juste pensé 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 essentiel. Je n'ai jamais dit qu'une comparaison < était plus rapide qu'une comparaison >. Rappelez-vous : nous parlons de tests de profondeur de matériel graphique, pas de votre CPU. Pas operator< .

Ce à quoi je faisais référence était une ancienne optimisation spécifique où une trame vous utilisiez GL_LESS avec une plage de [0, 0.5]. L'image suivante, vous effectuez le rendu avec GL_GREATER avec une plage de [1,0, 0,5]. Vous allez et venez, en inversant littéralement le signe de Z et le test de profondeur à chaque image.

On perd ainsi un bit de précision de la profondeur, mais il n'est pas nécessaire de vider le tampon de profondeur, ce qui était autrefois une opération plutôt lente. Comme l'effacement de la profondeur est non seulement gratuit de nos jours mais aussi plus rapide que cette technique, les gens ne le font plus.

Answer 2

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 une seule direction - c'était un problème assez courant à l'époque. L'assemblage/branchement de bas niveau n'a rien à voir avec cela - le Z-buffering est fait dans du matériel à fonction fixe, et est pipeliné - il n'y a pas de spéculation et donc pas de prédiction de branchement.

Answer 3

Cela a à voir avec les bits de drapeau dans les assemblages hautement réglés.

Le x86 possède des instructions jl et jg, mais la plupart des processeurs RISC ne possèdent que jl et jz (pas de jg).