[gdc15]《命运》的多线程渲染框架

http://advances.realtimerendering.com/destiny/gdc_2015/
gdc15（原名《Destiny’s Multi-threaded Renderer Architecture》），业界老兵娜姐（Natalya Tatarchuk）带来。
232页的ppt，真是给跪了。

sum
颇为欣赏的一个presentation，在《destiny》中把render architecture提升了一步，对比《halo:reach》更加的job化和data driven。
最后能在四个复杂平台（ps3,ps4,xbox360,xbox1）上高质量的发布，以及拥有良好的扩展性，其战斗力可见一斑。
也是行业里为数不多的，深入详细讲解渲染pipeline设计的好文章。

传统的渲染架构

这个应该说是大部分的游戏引擎的渲染框架，在bungie，其《halo：reach》就是这样做的。
在多线程架构上面，这个图示出来这样的：

这个主要的问题就是比较死板，对于灵活的情况缺乏适应性，包括：

• 跨平台，各个平台上面很不一样
• 沙河游戏的多种游戏情况，一会人多，一会特效多，一会场景物件多
  想要有一个架构，能适应各种情况下，就需要升个级了。

模块化的渲染架构

传统的流水线可以使用“固化”来形容，destiny的是以模块化的方式来形容。
典型就是乐高的组织方式。
实际中这种模块化的组织方式或者说视角，在近几年的cinematic, animation以及现在这个渲染pipeline设计中都出现了这样的情况。
处理的方式很像pc主板上的模块化方法，围绕“标准化”来进行。

渲染数据模块化

对于一个个render object来说，destiny定义了几个标准化接口和阶段包括
- extract
- prepare
- publish
- submit
等阶段（接口），在其中实现各自的功能。
以cloth为例

这个render object隶属于一个角色（game object），

- extract：这个阶段就是抽取最小的渲染需要的数据集输送给渲染模块，在主线程
- 会在extract阶段做visibility test
- 所谓的抽取，是一个copy的过程，可以使用ring buffer等来管理
- prepare等就是一些准备工作，可以自己定义一些事情，这里已经在渲染线程了，可以和下一帧的计算并行起来。
- 后面的publish和submit都是一些既定的接口，可以让数据模块和具体的和渲染pipeline的模块交互结合。

pipeline模块化
整体渲染模块分了这么几级：
- frame–整个一帧
- view–玩家视角，shadow视角等等
- stage–一个view中不同的渲染过程，比如玩家视角有gbuffer，lighting，postfx阶段
- featured renderer–具体的一个renderer，比如渲染decal，terrain等等
在featured renderer这个层面，就可以以job的方式做组织和多线程执行了。

render obj和render pipeline的结合
两个都是模块化的，结合的过程就是一个注册，然后接口调用的过程，非常的灵活方便。
然后在featured renderer这个级别去job化。
这个job，可以是cpu上的多线程，也可以在ps3上这种去spu做，比较小的力度，取舍以及跨平台都提供了良好的基础。

pipeline sum
其实要说这套有多么革命性，就完全谈不上，在我看来，的确是把概念理得更清晰了。
destiny能把如此复杂的游戏，在4平台上弄好，这个真心厉害。
反向推之，面对这样的平台差异性和游戏多样性，这样的设计才是合理的。
再说回来，游戏没那么复杂，以及平台跨度没那么大，使用简单的pipeline也是完全合理的，job系统概念很酷炫，但是对于问题定位等都设定了很高的门槛。
优化
作为业界老兵，可以说所有的优化套路都用到了。
- 非常清晰的运行视图，这个放在第一条，在我看来，是比所有优化方法都重要的呈现方式，程序员对于整体有足够清晰的概念是最重要的

- 先做visibility test在做数据抽取，这个和常规游戏在渲染线程，对于render object合集（统称scene graph）要更给力一些。
- 一些基本原则
- minimal data&cache friendly
- 渲染数据和逻辑数据分离
- data driven的数据和pipeline模块设计概念
- 宏观视图，防止cpu和gpu的idle（starvation）
- 静态数据（比如场景物件）和动态数据（比如角色）使用不同的处理方法