编辑:我仍在寻找有关使用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(批处理灯光),为什么会这样,如果我没有使用它们会发生什么呢?
答案 0 :(得分:3)
但我没有看到如何在不超过某些GPU上片段着色器的指令限制的情况下这样做。
这取决于你拥有多少盏灯。 “指令限制”非常高;在退化案例之外,通常不需要担心。即使100多盏灯影响了一块瓷砖,你的照明计算也不会超过指令限制的几率相当不错。
现代GL 3.3硬件可以在片段着色器中运行至少65536个动态指令,可能更多。对于100个灯,这仍然是每个灯的655个指令。即使您采用2000条指令计算相机空间位置,每个灯仍然会留下635条指令。即使您直接在GPU中使用Cook-Torrance,这可能仍然足够。