使用基于平铺的剔除概念问题延期渲染

编辑：我仍在寻找一些关于使用OpenCL或计算着色器的帮助。我宁愿继续使用OGL 3.3，而不必处理OGL 4.3和OpenCL 1.2的不良驱动程序支持，但我不能想到无需使用这两种颜色之一来进行这种类型的着色（以匹配灯光和砖）。是否可以在不使用GPGPU的情况下实施基于图块的选择？使用基于平铺的剔除概念问题延期渲染

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

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

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的片段着色器。谁能帮我这个？它也似乎几乎每个基于瓦片的延迟渲染器使用计算着色器或OpenCL（为灯光进行批处理），这是为什么，如果我没有使用这些会发生什么？

来源

2013-04-14 Spaceman1701

但我不明白如何在不超过某些GPU上片段着色器的指令限制的情况下执行此操作。

这取决于你有多少灯。 “指令限制”非常高;一般情况下，你不需要担心退化情况以外的事情。即使100多盏灯影响到一个贴片，赔率相当好，您的照明计算不会超过指令限制。

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

来源

2013-04-14 00:44:36

有趣。在某一点上，我确实计算了每个着色器（7）以及某些图形卡（特别是中型和低端笔记本电脑GPU，如GT 540）上的多个光源，看起来我似乎超出了指令限制。我通过大量的试验得出了这个结论，我在之前的一篇文章中提到过这个问题。我错了吗？ – Spaceman1701

事实上，我用NVidia 8600GT也遇到了同样的问题。我用20个左右的灯光达到了极限。你在说什么类型的硬件@NicolBolas？ –

希望本周末有一些时间来实施它。我会看看会发生什么。 – Spaceman1701

使用基于平铺的剔除概念问题延期渲染

回答

相关问题