设计并行化游戏引擎框架.docVIP

GameRes游戏开发资源网 设计并行化游戏引擎的框架 作者：Jeff Andrews 翻译：Vincent 联系方式： QQMSN：square@ 设计一个功能可分解的、数据可分解的系统可以提供大规模的并行化执行，同时保证发挥多核处理器的性能。 随着多核心处理器的降临，对可并行计算游戏引擎的需求已经变得越来越重要了。尽管仅仅依靠GPU和单线程游戏引擎依然是可行的，但是在一个系统上使用多核处理器所具有的优势会给用户带来更深刻的体验。譬如，使用多核CPU一个游戏可以增加更多的物理刚体对象来提升效果，或者开发出更加智慧的类人化的AI。 并行化游戏引擎框架，或者称为多线程引擎，目的是在开发平台上利用所有的处理器来提升性能。（引擎）通过并行化处理，各个功能模块可以利用所有可用的处理器。当然，说比做要容易，毕竟在游戏引擎中很多东西是互相交叉的，这通常会引起线程错误。因此，需要设计一套系统来合适地处理数据同步问题，同时避免被同步锁所限制。此外，也需要一套方法来保证在并行方式下处理数据同步时使串行处理消耗尽可能小。本文要求读者需要对现代计算机游戏发展以及游戏引擎线程编程有很好的理解和工作经验。 2.并行处理态 并行处理态的概念对于一个高效的具有多线程运行时态的引擎来说是非常重要的。引擎如果要实现真正意义上的并行处理——即尽可能少的同步损耗，则需要引擎内部各个系统在运行时坐到尽量少的交互。尽管数据需要共享，但是现在每个系统都应该有自己的一份数据拷贝，而不是通过一个公共的方式来访问数据。这样各个系统之间将不再有数据依赖关系。任何一个共享数据的变化都会被送到一个状态管理器那里，并且被加入一个变化队列，不妨称作消息提示队列。一旦各个系统完成处理任务，他们将会被提示改变自己的状态，同时更新各自内部的数据结构（作为消息队列的一部分）。使用这一机制将会大大减少同步损耗，使得各个系统能更加独立地工作。 2.1执行模式 当各个系统同步运行时（即各系统的操作被限制在同一个时钟内），对于执行状态的管理将会达到最优。这个时钟的频率可以等于帧速率，当然这并不是绝对的。这个时钟的频率甚至可以不是一个固定的值，然而若使这个跨度等于处理一帧所需要的时间——无论这一帧有多么长，我们就可以完全不考虑频率了。你对执行态的管理的实现将会决定这个时钟跨度。图示1描绘了不同系统在使用自由的时钟步进时的状态，这种状态下这些系统并非在同一个时钟内完成执行。除此之外，图示2描绘了所有系统在同一个锁定的时钟下是如何执行的。 图示1. 自由步进模式下的执行态 2.1.1 自由步进模式 在这一模式下系统的运行时间取决于任务所需要的时间。这里的自由并非指系统在完成任务之前是不自由的，而是指系统可以自由选择需要使用的时钟数。 在这个方式下，一个普通的对于状态变化的提示对于状态管理器来说是不够的，相关的数据也需要被包含在该提示中。这是因为当一个系统修改了共享数据时它仍有可能还在执行，而这时别的系统也需要更新这些数据。这就需要越来越多的内存做备份，这种方式显然不是最理想的。 2.1.2 锁定步进模式 这一模式要求所有的系统在同一个跨度内完成各自的处理。这样既易于实现同时又不需要将数据附加在提示中，因为系统的状态发生变化时可以在运行周期的结尾简单地通过访问别的系统来获取数据。 锁定步进模式可以通过在多个步骤中进行交叉执行来实现一个假的自由步进模式。譬如当AI在第一个时钟计算出它初始的“宏观视角”下的目标后，在下一个时钟内它可以在宏观目标下关注更具体的目标，而不仅仅是重复上一个宏观目标。 图示2. 锁定步进下的执行态 2.2 数据同步 基于多个系统可以对同一个共享数据做出改变，那么就需要确定在这些变化中到底那个值才是正确且可以使用的。有两种机制来解决这个问题： 时间，最后一个做出变化的系统的值是正确的。 权限，具有更高权限的系统的值是正确的。当多个系统拥有相同权限时可以与时间机制结合使用。 在这两种机制下，那些被认为是旧的数据将会被覆盖或者从提示队列中抛弃掉。 因为数据是共享的，那么在给数据赋相对值时可能因为这些数据是没有顺序的而变得难以掌握。为了消除这一障碍，当系统更新数据时使用绝对值来赋值以达到新旧交替。绝对值和相对值的结合使用是比较理想的，但是这也要根据情况而定。譬如，像位置，朝向这种公共数据，应该用绝对值来标识，这是因为在创建一个变换矩阵时需要考虑接收数据的顺序。然而，一个创建粒子的系统，在完全拥有粒子信息的情况下，可以只做相对值的更新。 引擎 设计引擎时应关注结构的弹性，以使得在扩展功能时更加简便。基于此，引擎在各种受到限制（譬如内存）的平台上应用时可以很好地做出调整。 引擎由两部分组成，一部分是框架，另一部分是管理器。框架（章节3.1）包含了游戏中会重复出现的拥有多个实例