英文:
Is discard bad for performance when doing depth testing without depth writing?
问题
I've read that using discard is bad for performance because the gpu can't assume the final depth value and early Z-testing is disabled. But if I disable depth writing and continue with depth testing against previous passes, is this still hold and using discard still disables early Z-testing?
英文:
I've read that using discard is bad for performance because the gpu can't assume the final depth value and early Z-testing is disabled. But if I disable depth writing and continue with depth testing against previous passes, is this still hold and using discard still disables early Z-testing?
答案1
得分: 1
discard是一个性能问题，因为与深度测试相关的情况现在由片段着色器的执行来控制，它可能会或可能不会discard特定的片段。因此，深度测试必须等到片段着色器执行完毕才能进行。
然而，如果你关闭深度写入...那是全局的（对于该绘制调用）。所有正在渲染的片段都将关闭深度写入。因此，这不会改变FS和深度测试之间的关系。因此，深度测试可以在FS执行之前发生。
现在，围绕渲染帧缓冲交互的任何状态更改都不便宜。它们会在更改后的第一个绘制调用时产生成本。但这个成本只发生一次：在状态更改之后。这不会影响使用该状态的绘制调用速度。将状态更改视为渲染过程中的减速带；一旦你越过这个减速带，道路就会变得平坦。
英文:
discard is a performance problem because what happens with regard to the depth test is now governed by the execution of the fragment shader which may or may not discard any particular fragment. Therefore, depth testing must wait until the fragment shader has executed.
However, if you turn off depth writes... that's global (for that draw call). All fragments being rendered will have depth writes off. So this doesn't change the relationship between the FS and the depth test. So the depth test can happen before the FS executes.
Now any state changes around rendering framebuffer interactions are not cheap. They will incur a cost at the first draw call after the change. But that cost is a cost that happens once: after the state change. It is not a cost with regard to the speed of the draw calls using that state. Think of the state change as a speed bump in your rendering process; once you're past the hump, the road is smooth.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论