Deferred Rendering的优势在于它允许片段着色器仅执行numLights * numPixels次。这是因为在正向渲染中，很多时候相同的像素被渲染两次。但是，如果在片段着色器之前和几何着色器之后执行深度剔除或z剔除，这将导致它与延迟渲染一样有效，并且不需要大的G缓冲区。我相信可以在较新版本的OpenGL中执行此操作，那么为什么没有人这样做呢？如果我的想法出错，请通知我。
注意：也许这不是一个合适的问题，但我不知道我可以在哪里发布这个。
答案 0 :(得分：1)
但是，如果在片段着色器之前和几何着色器之后执行深度剔除或z剔除，这将导致它像延迟渲染一样高效
不，它不会。
每个灯光仍会执行一次所有顶点处理阶段，因为标准前向渲染需要为每个灯光绘制每个模型。在延迟渲染中，您只绘制一次模型，因此可以节省顶点处理时间。
这很重要，因为许多现代硬件使用所谓的统一着色器架构＆＃34;。这意味着硬件能够动态分配着色器工作负载。如果渲染大量顶点，但使用短片段着色器，则可以为VS阶段分配更多着色器单位。如果使用简单的VS渲染4个顶点，但是复杂的FS，那么它可以为顶点阶段分配很少的硬件，并为片段着色器分配更多的硬件。
因此，在延迟渲染中，您需要花费更多可用的着色器处理器时间来完成有用的工作。通过前向渲染，您可以在有用的FS工作和重复且无用的VS工作之间拆分GPU的资源。
接下来，您可能会建议使用变换反馈来捕获渲染结果并重新渲染它们。但是现在你只是为另一个交换了一个瓶颈：你占用了更多的内存，你交换VS工作的内存带宽。
我只执行一次绘制调用，因此没有多余的geomitries，而是使用灯光阵列作为制服循环遍历片段着色器中的所有灯光。
这简单地将一种低效率换成了另一种，尽管这通常更快（但不那么灵活）。您不需要多次渲染每个网格，而是为那些不一定可见的碎片运行非常耗时的FS调用。
Early depth tests不保证任何事情。硬件不可能保证每次执行的FS调用都是可见的，因为GPU可能还没有光栅化遮挡对象。早期的深度测试不能确定事情的顺序。
保证所有FS调用都可见的唯一方法是执行深度预传。也就是说，您渲染场景中的所有内容，但没有片段着色器。因此，唯一得到更新的是深度。然后，使用实际着色器再次渲染场景。
但是，然后，您将整个场景渲染两次。并且着色器负载平衡可能要困难得多，因为整个对象都被剔除了。
您必须认识到的另一件事是延迟渲染并不能保证性能。它只是另一种渲染方法，具有自身的优点和缺点。您可以创建延迟渲染比前向渲染的任何变化都慢的情况。您还可以创建延迟呈现更快的环境。虽然随着灯光数量的增加，延迟渲染通常是最好的选择，但总有一些情况可以使另一种渲染技术在性能上更优越。