并行化游戏引擎的设计(Designing a Parallel Game Engine)中文版PDF

设计并行化游戏引擎的框架

作者： Jeff Andrews

http://software.intel.com/en-us/articles/designing-the-framework-of-a-parallel-game-engine/

翻译： Vincent

联系方式： QQ ： 14173579 MSN ： square@sina.com

整理导出 : Crazii MSN: lostxwind@hotmail.com

1.

1.

1.

1. 简介

并行化游戏引擎框架， 或者称为多线程引擎， 目的是在开发平台上利用所有的处理器来提 升

性能。 （引擎）通过并行化处理，各个功能模块可以利用所有可用的处理器。当然，说比做

要容易，毕竟在游戏引擎中很多东西是互相交叉的，这通常会引起线程错误。因此，需要 设

计一套系统来合适地处理数据同步问题，同时避免被同步锁所限制。此外，也需要一套方 法

来保证在并行方式下处理数据同步时使串行处理消耗尽可能小。 本文要求读者需要对现代 计

算机游戏发展以及游戏引擎线程编程有很好的理解和工作经验。

2.

2.

2.

2. 并行处理态

并行处理态的概念对于一个高效的具有多线程运行时态的引擎来说是非常重要的。 引擎如 果

个系统能更加独立地工作。

2.1

2.1

2.1

当各个系统同步运行时（即各系统的操作被限制在同一个时钟内） ，对于执行状态的管理将

会达到最优。这个时钟的频率可以等于帧速率，当然这并不是绝对的。这个时钟的频率甚 至

可以不是一个固定的值， 然而若使这个跨度等于处理一帧所需要的时间 —— 无论这一帧有 多

么长，我们就可以完全不考虑频率了。你对执行态的管理的实现将会决定这个时钟跨度。 图

示 1 描绘了不同系统在使用自由的时钟步进时的状态， 这种状态下这些系统并非在同一个 时

钟内完成执行。除此之外，图示 2 描绘了所有系统在同一个锁定的时钟下是如何执行的。

这时别的系统也需要更新这些数据。 这就需要越来越多的内存做备份， 这种方式显然不是 最

理想的。

2.1.2 锁定步进模式

这一模式要求所有的系统在同一个跨度内完成各自的处理。 这样既易于实现同时又不需要 将

数据附加在提示中， 因为系统的状态发生变化时可以在运行周期的结尾简单地通过访问别 的

系统来获取数据。

锁定步进模式可以通过在多个步骤中进行交叉执行来实现一个假的自由步进模式。譬如当

AI 在第一个时钟计算出它初始的 “ 宏观视角 ” 下的目标后，在下一个时钟内它可以在宏观

目标下关注更具体的目标，而不仅仅是重复上一个宏观目标。

图示 2. 锁定步进下的执行态

权限， 具有更高权限的系统的值是正确的。 当多个系统拥有相同权限时可以与时 间

机制结合使用。

在这两种机制下，那些被认为是旧的数据将会被覆盖或者从提示队列中抛弃掉。

因为数据是共享的， 那么在给数据赋相对值时可能因为这些数据是没有顺序的而变得难以 掌

握。为了消除这一障碍，当系统更新数据时使用绝对值来赋值以达到新旧交替。绝对值和 相

对值的结合使用是比较理想的，但是这也要根据情况而定。譬如，像位置，朝向这种公共 数

据， 应该用绝对值来标识， 这是因为在创建一个变换矩阵时需要考虑接收数据的顺序。 然

而，

一个创建粒子的系统，在完全拥有粒子信息的情况下，可以只做相对值的更新。

3.

3.

3.

3. 引擎

设计引擎时应关注结构的弹性，以使得在扩展功能时更加简便。基于此，引擎在各种受到 限

引擎由两部分组成，一部分是框架，另一部分是管理器。框架（章节 3.1 ）包含了游戏中会

重复出现的拥有多个实例的那些部分，同时也包含那些出现在主循环的东西。管理器（章 节

3.2 ）作为单件存在并且独立于游戏逻辑。

下面的图描述了组成引擎的各个部分：

� 通知另一个系统共享数据已经发生了变化。 （譬如位置，朝向）

� 请求一些自身并不包含的功能。 （譬如 AI 系统要求地形 / 物理系统执行一次射线碰

第一个通信问题通过实现前一章所述的状态管理器来解决。状态管理器将在章节 3.2.3 “ 状

态管理器 ” 进行更详细的讨论。

要解决第二个问题， 需要在系统中加入一个用来给不同系统提供服务的机制。 章节

“ 服

务管理器 ” 将会进行深入的解释。