我正在读an awesome OpenGL tutorial。这真的很棒，相信我。我目前的主题是Z-buffer。除了解释它的全部内容之外，作者还提到我们可以执行自定义深度测试，例如GL_LESS，GL_ALWAYS等。他还解释了深度值的实际含义（顶部是哪个，哪个不是）也可以定制。到目前为止我明白了。然后作者说了一些令人难以置信的事：
zNear的范围可以大于zFar的范围;如果是，则窗口空间值将根据与观看者最近或最远的内容来反转。
早些时候，据说窗口空间Z值为0，最接近1。但是，如果我们的剪辑空间Z值被否定，则1的深度将最接近视图，0的深度将最远。然而，如果我们翻转深度测试的方向（GL_LESS到GL_GREATER等），我们得到完全相同的结果。所以这真的只是一个惯例。事实上，翻转Z的标志和深度测试曾经是许多游戏的重要性能优化。
如果我理解正确，性能方面，翻转Z的符号和深度测试只不过是将<比较改为>比较。所以，如果我理解正确并且作者没有撒谎或者说不上，那么将<改为>曾经是许多游戏的重要优化。
是作者在做什么，我是否误解了某些东西，或者确实是这样的情况，一旦<比>慢（（如作者所说）那么慢？
谢谢你澄清这个非常奇怪的事情！
免责声明：我完全清楚算法复杂性是优化的主要来源。此外，我怀疑现在肯定没有任何区别，我不是要求它优化任何东西。我非常痛苦，也许是令人望而却步的好奇心。
如果我理解正确，性能方面，翻转Z的符号和深度测试只不过是改变<比较到>比较。所以，如果我理解正确并且作者没有撒谎或做出任何事情，那么改变<to>曾经是许多游戏的重要优化。
我没有特别好地解释，因为它并不重要。我觉得这是一个有趣的琐事。我不打算专门讨论这个算法。
但是，背景是关键。我从来没有说过<比较比比较快。请记住：我们谈论的是图形硬件深度测试，而不是CPU。不是operator<。
我所指的是一个特定的旧优化，其中一个帧你将使用GL_LESS，范围为[0,0.5]。下一帧，使用范围为[1.0,0.5]的GL_GREATER进行渲染。你来回走动，字面意思是“每一帧都在翻转Z的标志和深度测试”。
这会失去一点深度精度，但您不必清除深度缓冲区，这曾经是一个相当慢的操作。由于深度清除这些天不仅是免费的，而且实际上比这种技术更快，人们不再这样做了。
答案几乎可以肯定，无论使用芯片+驱动程序的哪个版本，Hierarchical Z只能在一个方向上工作 - 这在当天是一个相当普遍的问题。低级汇编/分支与它无关 - Z-buffering在固定功能硬件中完成，并且是流水线的 - 没有推测，因此没有分支预测。
像这样的优化会损害许多嵌入式图形解决方案的性能，因为它会降低帧缓冲区的效率。清除缓冲区对于驱动程序来说是一个明确的信号，它在分箱时不需要存储和恢复缓冲区。
小背景信息：平铺/分级光栅化器处理屏幕的数量非常小的平铺，适合片上存储器。这减少了对外部存储器的写入和读取，从而减少了内存总线上的流量当一个帧完成（调用swap，或者因为它们已满而刷新FIFO，帧缓冲绑定改变等）时，必须解析帧缓冲;这意味着每个垃圾箱都会依次处理。
驱动程序必须假定必须保留以前的内容。保存意味着必须将bin写出到外部存储器，然后在再次处理bin时从外部存储器恢复。清除操作告诉驱动程序垃圾箱的内容定义明确：颜色清晰。这是一种无法优化的情况。还有“丢弃”缓冲区内容的扩展。
它与高度调整的汇编中的标志位有关。
x86有jl和jg指令，但大多数RISC处理器只有jl和jz（没有jg）。