KlayGE游戏引擎

上一篇讲了tone mapping的改进。作为引擎的一个长期议题，优化是不可缺少的。本篇就讲讲在4.10中引入的新优化。 CPU端 在profiler里看到的占据CPU耗用第一名的一直是驱动。原先一直没在意这个，前一阵自己看了一下，发现前几位的好几个都是在SceneManager里，而且都和渲染队列相关。具体情况是，在每一帧确定渲染队列的时候，会执行一遍这样的步骤： 扫描一遍场景里的所有SceneObject，根据它的Renderable的类型建立一个从Renderable到SceneObject列表的unordered_map，每个物体作为那个Renderable的instance 把unordered_map中的Renderable建立一个队列 渲染这个队列 销毁unordered_map 所以其实这里的unordered_map只是 ...

上一篇探讨了G-Buffer里如何紧凑并高质量地存储normal。长期以来，deferred一直被认为只能用于高端显卡，低端卡由于功能和带宽的限制，不适合使用deferred。虽然现今移动设备大行其道，但所有移动设备和桌面相比，都只能算低端。所以OpenGL ES上也一直都被forward渲染占领。一个引擎维护两套流水线是非常麻烦的事情，尤其对于KlayGE这样的开源轻量引擎。所以，如果能在低端设备上也能用同一条deferred流水线，能给维护和扩展提供巨大的方便。 经过一定的改进，deferred流水线已经可以在中上等级的OpenGL ES 2设备和D3D11 feature level 9.3设备上跑了。这样的硬件涵盖了NV GeforceFX 6000以上（2004年）、ATI Radeon X1000以上（2005年） ...

KlayGE 4.4中的Tile-based Deferred Rendering（TBDR）是个基于pixel shader的算法，每个batch最多32个光源。这个方法适合于不支持compute shader的设备。因为在compute shader里，可以利用group memory把更多光源打包到同一个batch里，进一步提高效率并减少带宽。 改进的算法 CS可以通过group memory在thread之间共享数据，只要利用得好这部分，就能极大提升性能。在TBDR中，group memory主要用在两部分。第一部分是tiling阶段，用的是常见的reduce方法。先让所有thread读满32x32个depth，reduce得到1x1，再写入目标纹理。 第二部分是shading阶段。每个group会对所有光源做一次求交测试，把有效的光源写入group memory。接着在同一个sh ...

KlayGE从4.0开始引入deferred rendering层（DR），并且这几个版本都在持续地改进，以提高性能和降低使用难度。在即将发布的4.4里，deferred rendering更是往前跨了一大步，实现了一个初步的Tile-based Deferred Rendering（TBDR）。和常见的TBDR不同之处在于，这里的方法只需要SM3。（其实SM2也没问题，只是如果光源较多，会遇到指令长度限制） Tile-based 在传统的deferred rendering中，每个光源需要和每个像素做一次相交测试，测试通过的才计算光照。这个相交测试一般通过light volume的方式进行优化。但最终仍然需要对每个light画1次。也就是说，每个像素需要对每个光源读取一次G-Buffer，计算一个光照，并做一次blend写入。这个带来的 ...