Question

编辑：我仍在寻找有关使用OpenCL或计算着色器的一些帮助。我更喜欢继续使用OGL 3.3并且不必处理对OGL 4.3和OpenCL 1.2的错误驱动程序支持，但我无论如何都不会想到这种类型的阴影而不使用其中一个（用于匹配灯和砖）。是否可以在不使用GPGPU的情况下实现基于图块的剔除？

我在OpenGL 3.3中编写了一个延迟渲染。现在我没有对光通道进行任何剔除（我只为每个灯光渲染一个全屏四边形）。这（显然）有很多透支。（有时它是~100％）。因此，我一直在研究在光通过期间提高性能的方法。看起来（几乎）每个人的意见中最好的方法是使用屏幕空间图块来剔除场景。这是Frostbite 2中使用的方法。我在2010年SIGGRAPH期间阅读了Andrew Lauritzen的演示文稿（http://download-software.intel.com/sites/default/files/m/d/4/1/d/8/lauritzen_deferred_shading_siggraph_2010.pdf），我不确定我是否完全理解这个概念。（就此而言，为什么它比其他任何东西都好，如果它对我来说更好）

在演讲中，Laurtizen用轻量，四边形和瓷砖进行延迟着色以剔除场景。根据他的数据，基于区块的延迟渲染器是最快的（到目前为止）。我不明白为什么会这样。我猜这与事实有关，即每个瓷砖都将所有灯光一起分批。在演示文稿中，它说要读取G-Buffer一次然后计算光照，但这对我来说没有意义。在我看来，我会这样实现：

for each tile {
  for each light effecting the tile {
    render quad (the tile) and compute lighting
    blend with previous tiles (GL_ONE, GL_ONE)
  }
}

这仍然需要对G-Buffer进行大量采样。我认为这样做会产生与为每个灯光渲染四边形屏幕相同（如果不是更差）的性能。从它的措辞来看，似乎这就是正在发生的事情：

for each tile {
 render quad (the tile) and compute all lights
}

但我没有看到如何在不超过某些GPU上片段着色器的指令限制的情况下执行此操作。谁能帮我这个？看起来几乎每个基于tile的延迟渲染器都使用计算着色器或OpenCL（批处理灯光），为什么会这样，如果我没有使用它们会发生什么呢？

Answer 1

但我没有看到如何在不超过某些GPU上片段着色器的指令限制的情况下这样做。

这取决于你拥有多少盏灯。 “指令限制”非常高;在退化案例之外，通常不需要担心。即使100多盏灯影响了一块瓷砖，你的照明计算也不会超过指令限制的几率相当不错。

现代GL 3.3硬件可以在片段着色器中运行至少65536个动态指令，可能更多。对于100个灯，这仍然是每个灯的655个指令。即使您采用2000条指令计算相机空间位置，每个灯仍然会留下635条指令。即使您直接在GPU中使用Cook-Torrance，这可能仍然足够。

基于平铺的剔除概念问题的延迟渲染

1 个答案: