曾几何时,当>比<更快......等等,什么?

时间:2011-09-07 18:39:30

标签: c optimization opengl cpu gpu

我正在阅读an awesome OpenGL tutorial。这真的很棒,相信我。我目前的主题是Z-buffer。除了解释它的全部内容之外,作者还提到我们可以执行自定义深度测试,例如GL_LESS,GL_ALWAYS等。他还解释了深度值的实际含义(顶部是哪个,哪个不是)也可以定制。到目前为止我明白了。然后作者说出了令人难以置信的事情:

  

范围zNear可以大于zFar的范围;如果是,那么   就构成的内容而言,窗口空间值将被颠倒   离观众最近或最远的地方。

     

早些时候,据说窗口空间Z值为0是最接近的   1是最远的。但是,如果我们的剪辑空间Z值被否定,那么   深度为1将最接近视图,深度为0   最远。然而,如果我们翻转深度测试的方向(GL_LESS到   GL_GREATER等),我们得到完全相同的结果。所以它真的只是一个   惯例。 确实,翻转Z的标志和深度测试曾经一次   许多游戏的重要性能优化。

如果我理解正确,性能方面,翻转Z的符号和深度测试只不过是将<比较更改为>比较。因此,如果我理解正确并且作者没有说谎或正在做事,那么将<更改为>曾经是 重要优化 对于许多游戏。

作者是否正在制作,我是否误解了某些内容,或者一旦<比{{1>}更慢( ,如作者所说的那样)而不是{{1} }?

感谢您澄清这个非常奇怪的事情!

免责声明:我完全清楚算法复杂性是优化的主要来源。此外,我怀疑现在肯定没有任何区别,我不是要求它优化任何东西。我非常痛苦,也许非常好奇。

4 个答案:

答案 0 :(得分:340)

  

如果我理解正确,性能方面,翻转Z的符号和深度测试只不过是改变&lt;比较&gt;比较。所以,如果我理解正确并且作者不撒谎或不做事,那么改变&lt;到&gt;曾经是许多游戏的重要优化。

我没有特别好地解释,因为它并不重要。我觉得这是一个有趣的琐事。我并没打算专门讨论这个算法。

然而,背景是关键。我从来没有说过&lt;比较比&gt;更快。比较。请记住:我们谈论的是图形硬件深度测试,而不是CPU。不是operator<

我所指的是一个特定的旧优化,其中一个帧将使用GL_LESS,范围为[0,0.5]。在下一帧中,使用GL_GREATER进行渲染,范围为[1.0,0.5]。你来回走动,字面意思是&#34;翻转Z的标志和深度测试&#34;每一帧。

这会失去一点深度精度,但你不必清除深度缓冲区,这曾经是一个相当慢的操作。由于深度清除现在不仅是免费的,而且实际上比这种技术更快,人们不再这样做了。

答案 1 :(得分:3)

答案几乎可以肯定,无论使用芯片+驱动程序的哪个版本,Hierarchical Z只能在一个方向上工作 - 这在当天是一个相当普遍的问题。低级汇编/分支与它无关 - Z-buffering在固定功能硬件中完成,并且是流水线的 - 没有推测,因此没有分支预测。

答案 2 :(得分:0)

这样的优化会损害许多嵌入式图形解决方案的性能,因为它会降低帧缓冲区的效率。清除缓冲区对于驱动程序来说是一个明确的信号,它在分箱时不需要存储和恢复缓冲区。

小背景信息:平铺/分级光栅化器处理屏幕的数量非常小的平铺,适合片上存储器。这减少了对外部存储器的写入和读取,从而减少了内存总线上的流量当一个帧完成(调用swap,或者因为它们已满而刷新FIFO,帧缓冲绑定改变等)时,必须解析帧缓冲;这意味着每个垃圾箱都会依次处理。

驱动程序必须假定必须保留以前的内容。保存意味着必须将bin写出到外部存储器,然后在再次处理bin时从外部存储器恢复。清除操作告诉驱动程序垃圾箱的内容定义明确:颜色清晰。这是一种无法优化的情况。还有&#34; discard&#34;缓冲区内容。

答案 3 :(得分:-8)

它与高度调整的汇编中的标志位有关。

x86有jl和jg指令,但大多数RISC处理器只有jl和jz(没有jg)。