Érase una vez, cuando > era más rápido que

Estoy leyendo un impresionante tutorial de OpenGL. Es realmente genial, confía en mí. El tema en el que estoy actualmente es Z-buffer. Además de explicar de qué se trata, el autor menciona que podemos realizar pruebas de profundidad personalizadas, como GL_LESS, GL_ALWAYS, etc. También explica que el significado real de los valores de profundidad (cuál es superior y cuál no) también puede ser personalizado Entiendo hasta ahora. Y luego el autor dice algo increíble:

El rango zNear puede ser mayor que el rango zFar; si es así, entonces los valores del espacio de la ventana se invertirán, en términos de lo que constituye lo más cercano o lo más lejano del espectador.

Anteriormente, se dijo que el valor Z del espacio de la ventana de 0 es el más cercano y 1 es el más lejano. Sin embargo, si nuestros valores Z del espacio de recorte fueran negados, la profundidad de 1 sería la más cercana a la vista y la profundidad de 0 sería la más lejana. Sin embargo, si cambiamos la dirección de la prueba de profundidad (GL_LESS a GL_GREATER, etc.), obtenemos exactamente el mismo resultado. Así que en realidad es solo una convención. De hecho, cambiar el signo de Z y la prueba de profundidad alguna vez fue una optimización de rendimiento vital para muchos juegos.

Si entiendo correctamente, en cuanto al rendimiento, cambiar el signo de Z y la prueba de profundidad no es más que cambiar un < comparación con un > comparación. Entonces, si entiendo correctamente y el autor no está mintiendo o inventando cosas, entonces cambiando < a > solía ser una optimización vital para muchos juegos.

¿El autor está inventando cosas, estoy malinterpretando algo, o es realmente el caso que una vez < era más lento (vitalmentecomo dice el autor) que >?

¡Gracias por aclarar este asunto tan curioso!

_{Descargo de responsabilidad: Soy plenamente consciente de que la complejidad del algoritmo es la fuente principal de optimizaciones. Además, sospecho que hoy en día definitivamente no haría ninguna diferencia y no estoy pidiendo esto para optimizar nada. Soy extremadamente, dolorosamente, tal vez prohibitivamente curioso.}

Si entiendo correctamente, en cuanto al rendimiento, cambiar el signo de Z y la prueba de profundidad no es más que cambiar una comparación < a una > comparación. Entonces, si entiendo correctamente y el autor no está mintiendo o inventando cosas, entonces cambiar < a > solía ser una optimización vital para muchos juegos.

No lo expliqué particularmente bien, porque no era importante. Simplemente sentí que era un poco interesante de trivia para agregar. No tenía la intención de repasar el algoritmo específicamente.

Sin embargo, el contexto es clave. Nunca dije que una comparación < fuera más rápida que una comparación >. Recuerde: estamos hablando de pruebas de profundidad de hardware de gráficos, no de su CPU. No operator<.

A lo que me refería era a una optimización antigua específica en la que un cuadro usaría GL_LESS con una gama de [0, 0.5]. Siguiente cuadro, renderizas con GL_GREATER con una gama de [1.0, 0.5]. Avanzas y retrocedes, literalmente “volteando el signo de Z y la prueba de profundidad” en cada cuadro.

Esto pierde un poco de precisión de profundidad, pero no tenía que borrar el búfer de profundidad, que alguna vez fue una operación bastante lenta. Dado que la limpieza profunda no solo es gratuita en estos días, sino que en realidad es más rápida que esta técnica, la gente ya no lo hace.

La respuesta es casi seguro que para cualquier encarnación de chip+controlador que se haya utilizado, la Z jerárquica solo funcionó en una dirección; este era un problema bastante común en el pasado. El ensamblaje/ramificación de bajo nivel no tiene nada que ver con esto: el búfer Z se realiza en hardware de función fija y se canaliza; no hay especulación y, por lo tanto, no hay predicción de ramificación.

Tiene que ver con los bits de bandera en un ensamblaje altamente afinado.

x86 tiene instrucciones jl y jg, pero la mayoría de los procesadores RISC solo tienen jl y jz (no jg).