作者：郭胜，英特尔公司软件与服务事业部

1. 介绍

视频游戏在集成显卡上的性能日益成为游戏开发者关注的一个重要问题。这主要基于两方面的原因：一方面，最新的集成显卡在功能和性能上有了长足的进步。比如英特尔4系列集成显卡已经支持最高SM4.0渲染模式和DX10，在DirectX特性方面达到或超过大多数视频游戏的需求，测试表明这类集成显卡可保证市面上大多数视频游戏的可玩性【2】。另一方面，随着移动笔记本市场份额的迅速增长，作为移动PC的主要图形解决方案，低功耗、高性价比的集成显卡部署量剧增。目前，很多购买移动平台的玩家会关心他们爱玩的游戏是否能在这样的平台上运行。因此，优化游戏在集成显卡上的性能，使之能达到可玩的帧速率，对吸引潜在玩家，提高游戏普及度有重要意义。

然而，由于游戏渲染技术和软硬件组件的复杂性，分析和优化游戏性能并不是一件容易的事。英特尔图形性能分析器（又称英特尔? GPA）【1】能大幅简化游戏在英特尔集成显卡上的性能调优工作。GPA能采集从平台系统到每一帧的广泛的软硬件性能数据，并且提供各种DX状态覆盖和优化评估实验。如何使用GPA丰富而强大的功能进行性能分析是本文探讨的重点。本文介绍了从实践中总结出来的一套适用于英特尔集成显卡的游戏性能分析方法，阐述了如何分析性能数据和快速定位性能瓶颈。结合这些分析方法使用GPA的各项功能，有助于找到最有效的优化方案，激发游戏在基于英特尔集成显卡的系统的性能潜力。

2. GPA性能分析工具

英特尔的图形性能分析器（GPA）是一套帮助游戏开发人员分析、评估和改进运行于英特尔集成显卡上的游戏性能的工具套件。GPA适用于基于 DirectX的图形应用，当前的2.0版本支持DX9，后续版本将支持DX10。使用GPA分析图形应用性能时不需要增加或改动任何源代码。GPA主要包含两个性能分析工具：系统分析器和帧分析器。这两个工具可以使开发者分别从平台系统和单帧渲染的角度来观察游戏的性能表现和分析潜在的性能问题。GPA支持假设性的实验，使开发者不需要修改和重新编译游戏程序的源代码，就能评估某种优化可能带来的性能提升。这种功能很有用，在正式优化前评估优化效果有利于提高优化的效率，因为没有开发者愿意看到修改了不少源代码，并解决了由此带来的BUG，最后发现没有或只获得微小的性能提升。

除了强大的性能分析功能，有些游戏开发者还发现它的帧分析器是一个很好的游戏调试工具。例如系统分析器和帧分析器都有wireframe模式，可看重叠的相互遮挡的物体，以及虽没有遮挡但实际不可见的物体。帧分析器可动态改变DX状态，便于开发者不修改源代码和重新编译就能调试各种DX状态对画面的影响。

另外，虽然目前GPA只对英特尔4系列以后的集成显卡提供官方支持，但实际上它的帧分析器也能运行在非英特尔的显卡上。

接下来的章节中将主要介绍基于GPA的性能分析方法,而GPA各项功能的细节和操作方法请参考GPA软件的用户说明书和快速入门手册【3】。

3. 系统性能分析方法

分析游戏性能时，可以先寻找游戏在硬件上的瓶颈。从系统角度看，游戏渲染负载分布在CPU、GPU、总线和内存四个主要的硬件域中。以下方法可以判断这些域中是否存在瓶颈：

1. 系统分析器提供了一组与CPU利用率有关的计数器。当观察到某个CPU核的平均利用率越接近100%，则CPU端存在瓶颈的可能性越大。有时候，CPU的平均利用率不是很高，但系统分析器显示它的波动范围的上限经常达到100%，则CPU端也有可能存在瓶颈，而且说明CPU的负载很不稳定。

2. 判断GPU上是否存在瓶颈可使用系统分析器的“Null hardware”状态覆盖模式。这个模式能去掉所有显卡上的负载以及显卡对内存和总线的访问。如果系统分析器显示帧速率明显上升，GPU存在瓶颈的可能性很大，反之则不然。

3. 集成显卡的显存大部分都在系统内存中，因此内存总线可能存在瓶颈。系统分析器提供了一组内存总线相关的计数器。如果（System Memory Overall Bandwidth）计数器显示的平均带宽值接近平台可维持的最大内存带宽，则说明总线是瓶颈的可能性很大。如果当前使用带宽的最大值低于平台可维持的最大内存带宽，则总线是瓶颈的可能性较低。根据当前的DDR技术，平台可维持的最大内存带宽通常是带宽理论峰值的65％～70％。带宽理论峰值可通过下面公式计算。

公式中因子的值可通过CPUZ工具获得。例如4系列显卡的芯片组通常采用DDR3内存，频率为533MHz，当使用两个内存槽时，带宽理论峰值为17.1GB/s。实际可维持最大带宽约为11.9GB/s。

4. 分析游戏性能时，通常测试平台的内存配置都会比游戏要求的大很多，因此成为瓶颈的可能性较小。判断内存尺寸是否是瓶颈，可以通过操作系统的Perfmon工具比较内存使用量和总内存尺寸。

分析硬件瓶颈时，要注意以下一些特性：

• 系统中可能存在不只一个瓶颈。在渲染游戏画面时，不同的场景可能有不同的瓶颈。即使在一个场景中，绘制不同对象时也可能产生不同的瓶颈。例如，有的对象的瓶颈在纹理访问上，有的对象的瓶颈在像素着色上。另外某些因素可能导致硬件串行地处理负载。例如调用某些DX锁或显卡查询时，CPU和GPU互相等待交替执行。上述情况可以解释为何我们有时会发现管线中若干地方似乎都存在瓶颈。
• 我们并不是总能观察到明显的瓶颈，底层的硬件瓶颈更难发现，有时甚至是不可能的。原因是：并不是系统中所有硬件的负载都可以观察得到；另外，通过改变硬件的负载或处理能力来判断瓶颈时，这些改变往往会导致其他硬件的负载或处理能力也发生改变，比如修改管线前端的负载可能会影响管线后端的负载，而驱动、硬件等的优化机制（如EarlyZ等）也可能使对负载的调整并不象预期的那样。所以有可能使得原本不是瓶颈的硬件成为瓶颈，从而带来判断上的误差。

这些因素给瓶颈分析带来了复杂性。很多时候我们可以说某个地方是瓶颈的概率很大或很低，但并不是绝对的。各种可能性使判断瓶颈时需要多方面综合考察。

除了寻找硬件瓶颈，我们还可以通过观察渲染管线各个阶段的负载分布，从全局的角度分析性能问题的根源。

系统分析器提供的三个状态覆盖模式可以把游戏在图形渲染过程的负载分为四个主要阶段（如图1）。这几个状态覆盖模式是：

• “Null Hardware”。此状态覆盖模式能把显卡上的负载去掉，可以用于评估显卡负载对帧速率的影响程度，以及判断游戏性能是否受限于显卡。
• “Null Driver”。此模式把显卡驱动以及其后显卡硬件上的负载都去掉，可以用于评估游戏应用层代码的负载对帧速率的影响程度。另外，此模式的帧速率反映了不修改代码的情况下，游戏在任何显卡上（保持CPU和内存相同）的性能上限。
• “1X1 Scissor Rect”。从模式把显卡上的负载分为矩形裁剪前和裁剪后两大类。在IIG实现中，此模式几乎可以去除显卡Rasterization阶段后的所有负载，因此裁剪前主要是顶点相关的处理，裁剪后主要是像素（包括纹理）相关的处理。使用此模式可以评估象素处理（包括纹理）负载对帧速率的影响程度。

图1：游戏渲染的负载分布

通过系统分析器可以观察上述覆盖模式下的游戏帧速率和相应的帧时间，从而得到类似图n的一个负载分布图。需要注意的是，图中显示的每个阶段的时间并不是它们实际处理每帧画面的时间，而是实际处理时间中对整个帧时间有影响的那部分。由于这些阶段有时会并行执行，因此它们的实际处理时间可能会更长。

从负载分布图中可以得到很多信息：

• 观察“裁剪后”阶段的影响时间。如果大于零，则说明像素处理过程中存在瓶颈，反之则不存在。
• 观察“裁剪前”阶段的影响时间。如果很小或为零，说明顶点处理不是瓶颈。否则存在瓶颈。
• 观察驱动的影响时间。如果驱动时间占的比重较大，则说明渲染调用和数据拷贝的量可能较大且（或）效率较低。这种情况下需要进一步考察DirectX API调用的效率。
• 观察应用层的影响时间。首先可以评估游戏帧速率的上限，正常性能应该在100帧以上，否则要进一步考察应用层的效率。应用层主要包含游戏代码和DirectX层，可以通过VTune获得两部分负载的比例，从而推断是需要优化游戏代码，还是优化对DirectX API的调用方式。
• 比较目标帧时间在负载分布图中的位置，评估是否仅优化显卡上的负载（如简化着色器）就可能达到所需的性能，还是需要进一步优化应用层的代码。

系统分析器提供了一组DX相关的性能计数器（图2）。观察这些计数器的值有助于了解DX层的开销，以及分析DX调用行为对渲染管线后端的性能影响。

• DX绘制调用会产生一定开销。观察“DX Draw Calls per Frame”计数器的值，把它与此类型游戏的均值比较，可以了解DX绘制调用是否太多。
• 频繁的DX状态改变会产生很大的性能开销。通过“DX State Changes per Frame”和“DX Draw Calls per Frame”计数器，可以算出平均每个绘制调用的状态变化数，把它与此类型游戏的均值比较，可以了解DX状态改变是否太多。
• DX锁通常会使GPU等待CPU，因此越少越好。观察“DX Locks per Frame”每帧中锁调用的次数和“DX Lock Percent of Frame Time”占用帧时间的比例可以了解DX锁调用对性能的影响。

图2： DX计数器的采样值

4. 单帧性能分析方法

慢帧包含了主要的性能瓶颈，分析其中的绘制调用能帮助你发现问题的根源，告诉你渲染哪些对象非常耗时，哪个渲染步骤是需要优化的。单帧分析时可以使用以下方法。

4.1 寻找昂贵的绘制调用

就像分析程序的CPU性能时，我们总是关注热点函数一样，分析GPU上的性能，首先需要关注的是昂贵的绘制调用，它们消耗了很多GPU时间，往往是导致性能瓶颈的主要原因。使用帧分析器可以按照GPU Duration对所有绘制调用进行排序（图3），从而获得前几个最耗时的绘制调用。选择其中一个绘制调用，帧分析器能告诉你这个调用占用的GPU时间以及在整个帧时间中的比重。很多时候，单独分析某一个昂贵调用的意义并不大，因为虽然这个调用比其他调用更耗时，但在整个帧时间中的比重可能很小，因此单独优化对整体性能的影响并不明显。真正需要关注的是某一批同类的绘制调用，比如所有绘制场景中的地形或植被的调用。如果帧分析器显示它们在整个帧时间中的比重很大，那么优化这批绘制调用能带来显著的性能提升。昂贵的绘制调用往往存在于昂贵的绘制调用集中。在帧分析器中，在某个昂贵绘制调用的着色器上使用鼠标右键的弹出菜单（图3），可以选择使用这个着色器的所有绘制调用，从而把同类的绘制调用都找出来。当此昂贵调用没有自定义的着色器时，可通过相同方法，选择关联某个纹理的所有同类绘制调用。通过上述方法选择同类的绘制调用，还有一个作用，就是根据这些绘制调用的ID号，能判断使用相同资源和着色器的绘制调用是否连续。如果不连续，则说明调整绘制顺序可能提高性能。

图3： 按GPU时间排序并选择所有相同着色器的绘制调用

当选择了一个或一组绘制调用，首先可以通过渲染目标观察绘制了那些对象，要关注这些对象的可见性和像素的覆盖范围，如果对象不可见或者可见范围很小，则意味着有很大优化空间。然后，可以观察与这些绘制调用关联的各种数据，通过各种实验分析性能瓶颈和评估潜在的优化效果。

4.2 分析图元批处理尺寸

除了渲染对象的时间，绘制调用本身具有一定的额外开销。因此，为了提高效率，每个绘制调用批处理的图元个数不能太小。对于英特尔集成显卡来说，合适的图元批处理尺寸是200~1000。使用帧分析器可以按照Prim Count对所有绘制调用进行排序（图4），了解过小批处理尺寸的绘制调用所占的比例，以及它们渲染的对象，从而判断是否可以把它们进行合并提高效率。另一方面，对于过大批处理尺寸的绘制调用，观察它们在最终渲染目标上像素覆盖率，从而判断程序是否应用了细节分层（LOD）技术、或者适当的阻塞查询技术避免过度渲染开销。

图4： 按批处理尺寸排序，观察顶点和像素处理的开销

4.3 评估优化效果

优化程序无法避免修改代码，在此之前，如果能评估优化的效果，则能指明正确的方向，大大节约优化时间。因为修改代码会导致重新编译，还可能引入bug，没有程序员愿意看到修改代码后，性能提升很小或者没有变化。

当选择了待分析的绘制调用后，首先观察和比较Details Tab中的Vertex Shader Duration和Pixel Shader Duration（图4），判断绘制调用的瓶颈主要在顶点处理还是像素处理上（注意，GPA提供的Vertex Shader Duration和Pixel Shader Duration泛指大部分顶点和像素相关的处理，因此即使用固定管线渲染，这两个数据依然有效）。如果瓶颈在顶点处理上，则需要检查顶点计算（如着色器程序）的复杂度和顶点数量等，可选择的优化方案有简化顶点计算、顶点网格的LOD和阻塞查询等。如果瓶颈在像素处理上，则需要关注像素的个数、像素着色器的复杂度、纹理尺寸和过滤算法等。

图5： 使用帧分析器进行各种实验

当主要瓶颈在像素处理中时，可进行“2x2 Textures”实验（图5），评估减小纹理尺寸能带来的最大性能提升。“2x2 Textures”实验可以使程序只访问显卡纹理cache中的纹理，因此大大减少了从内存访问纹理的带宽和延迟。如果此实验显示绘制调用的时间减少很多，则纹理尺寸有可能是瓶颈。这时候需要进一步观察Texture Tab中的纹理列表，看这些绘制调用使用了那些纹理和访问这些纹理的次数，考虑是否能减少纹理数量，或者使用MIP级别更高的小纹理。（tips：观察纹理有时也能帮助我们判断所选绘制调用渲染的是何场景对象。）

图6： 改变纹理MIP级别的实验

使用“Clamp to MIP”实验（注意把帧分析器恢复到初始状态）可评估更低细节的纹理对性能和画面的影响（图6）。方法是：选择一个被频繁访问的大尺寸纹理，调整MIP级别使纹理尺寸减少，观察GPU时间和“Normal”方式下的渲染目标的改变，如果发现时间减少明显而画面变化很小，则可以采用减少纹理分辨率的优化方案。通常，如果瓶颈确实是纹理尺寸的话，“Clamp to MIP”实验和“2x2 Textures”实验一样，都能使性能大幅提高。但也有例外的情况，我们曾观察到这样的案例：做“2x2 Textures”实验时GPU时间减少很多，而用“Clamp to MIP”实验缩小纹理尺寸时GPU时间却增加很多。原因是，绘制调用中进行了Alpha测试（AlphaTest），而这两种实验不仅改变纹理的尺寸，还会改变纹理中的Alpha值，因此导致不同的AlphaTest负载。当我们在State Tab中关闭AlphaTest后（图7），发现时间减少的幅度和“2x2 Textures”实验差不多，从而发现问题的根源在AlphaTest上，而不是纹理尺寸上。当瓶颈在AlphaTest上时，可以通过调整Alpha参考值来提升性能。

图7： 改变DX状态的实验

纹理尺寸，纹理过滤算法也可能是瓶颈。如果你怀疑这方面的问题，则可以在StateTab中改变纹理采样器使用的过滤算法，评估简单算法能带来的优化效果。

当纹理相关的实验对性能影响不大时，可尝试“Simple Pixel Shader”实验（图5）。此实验用一个很简单的像素着色器替换程序原有的像素着色过程。此着色器使用单一颜色对像素直接着色，所以没有访问纹理的开销。无论绘制调用使用的是自定义的着色器还是固定渲染管线，“Simple Pixel Shader”都会替换它们。如果此实验明显减少GPU时间，并且可以排除纹理访问方面的瓶颈，则要重点关注着色程序的复杂度。此时在Shaders Tab中检查着色器代码，看是否使用了复杂的着色指令或算法。Shaders Tab中可以显示绘制调用使用的效果文件。通常效果文件中可能包含多个版本的着色器程序。如果你不是这部分代码的开发者，则可以通过对比当前DX状态和着色器程序中指定的DX状态，从而把绘制调用关联到具体的着色器代码上。

如果“Simple Pixel Shader”实验对性能的影响不是很大，可以在Overdraw模式下观察渲染目标和屏幕某一点的像素历史（图5），考察是否绘制调用重复渲染的像素过多。如果overdraw很多，可以考虑用Disable erg实验（图5），或编程时使用earlyZ优化。

上面主要介绍在一种状态改变的情况下或一种覆盖模式下进行实验，实际分析过程中，开发者可以按需灵活组合多种状态修改和覆盖模式进行深入的分析。

4.4 分析绘制场景对象的次序

场景对象的次序对性能的影响很大。比如按状态或资源排序，分组绘制场景对象能大大减少图形渲染管线切换的开销；从前向后渲染能减少像素过度着色等。在帧分析器中，依次选择绘制调用，观察渲染目标的改变，可以获得场景中各种对象的渲染顺序。分析渲染顺序时，要关注以下几个方面：

• 判断这种顺序是否有利于提高性能，例如，具有相同渲染状态（包括DX状态、着色器，纹理等）的绘制调用是否连续。
• 寻找其它昂贵的绘制调用集。有些同类的绘制调用放在一起时，在整个帧时间中的比重较大，但其中任何一个单独调用的GPU开销却不大，因此这类绘制调用集无法通过最昂贵的绘制调用发现，却可以在分析场景渲染顺序时找出来。
• 绘制次序是否显示程序采用了某种优化技术。比如实现早期Z裁剪（Early-Z Rejection）或阻塞查询的两趟绘制。由于某些技术只在特定条件下才有效果，否则反而对性能不利。因此如果程序中使用了这些技术，则需要通过帧分析器提供的各种信息判断这种技术是否真正有利于性能。比如，早期Z裁剪适合于像素多且着色复杂度高的对象，如果帧分析器显示绘制调用不满足这些条件，则可能会带来额外的性能开销。
• 考察是否有冗余的绘制调用，比如重复绘制场景对象或花大量时间绘制了最终不可见的对象。

4.5 观察渲染目标的变化

是选择了绘制调用，还是改变帧分析器中的状态，或进行了某种实验，渲染目标的变化都能提供很多信息。帧分析器提供了多种方式观察渲染目标，灵活组合使用这些功能可以全面观察场景。

• 如果要看绘制调用对画面的可见的改变，则选择Normal方式；
• 如果要看绘制调用覆盖画面的范围，则选择HightLight方式，此模式下不可见的绘制也会显示出来；
• 如果要看绘制调用渲染对象的网格，则选择wireframe或highlighted wireframe方式.
• 如果怀疑所选绘制调用渲染的对象被遮挡住了，则选择pop out使这些对象显现出来。
• 如果要对比相邻两个绘制调用对画面的改变，使用Scrub Mode

5. 总结

近年来，随着整合芯片技术的快速发展，集成显卡对视频游戏的支持正在不断增强。针对集成显卡优化游戏性能有助于提高游戏的潜在销量。本文分别从系统和单帧分析的角度介绍了基于英特尔图形性能分析器的分析方法。这些方法包括：观察性能计数器判断软硬件瓶颈；使用状态覆盖模式分析渲染负载分布；寻找每帧渲染中耗时的绘制调用；考察绘制调用的效率和顺序；利用各种实验评估最佳优化方向等。我们希望这些方法对开发者优化英特尔集成显卡上的游戏性能起到抛砖引玉的作用。也期待开发者在英特尔软件网络上分享使用GPA时发现的更多有效的性能分析方法和技巧。

参考资料

[1] http://software.intel.com/zh-cn/articles/intel-gpa/

[ 2 ] http://www.intel.com/support/graphics/sb/cs-012643.htm

[3] http://software.intel.com/en-us/articles/intel-graphics-performance-analyzers-quick-start-guide/

PDF下载
基于GPA的性能分析方法.pdf

作者简介

郭胜 英特尔开发者关系部门的应用工程师，主要负责为游戏独立软件开发商（ISV）提供英特尔技术咨询和性能优化服务。他拥有南京大学计算机硕士学位，擅长实时 3D 图形应用的软件设计、编程以及性能优化。

继 2004 年主频大战使处理器技术改进步伐开始变缓之后，第一款多核处理器在主流市场的投放，开启了个人计算的新纪元。通常人们会认为，随着处理内核的倍增，性能也将翻倍。但在数年之后的今天，我们都知道，对于某些我们钟爱的应用，事实并非如此。要发挥多核处理器的全部能力需要多线程应用，而相比传统的编码工作，开发合理线程化的软件是一项不同且更加有难度的任务。

如今，游戏开发工作已经落后于多线程软件的发展。鉴于典型的编码结构主要会涉及一个巨大的 while 循环，游戏成为了消耗主频大战中所涉及处理器纯速度的单线程程序的缩影。现在，既然我们都在向“更多内核”而不是“更多时钟”的方向发展，那么游戏开发人员就需要调整编程模式和思路来充分利用电脑硬件，甚至利用游戏社区。

正如所有现代编码员所知晓的那样，线程化并非一件易事。然而，尽管最初构建多线程游戏引擎需要做大量工作，但回报却是相当丰厚的，并且可一直延续到未来。（如欲了解详细信息，请参阅http://whatif.intel.com/ 上 Jeff Andrews 撰写的《设计并行游戏引擎》一文。）

作为多核处理器制造商，英特尔当然希望促进可充分发挥处理器全部性能的适当技巧的发展。有鉴于此，英特尔开发了名为 Smoke 的双用途框架和技术演示，重点介绍正确实施的多线程游戏的优势。它还向游戏开发人员展示了如何实现线程管理、资源共享和工作负载的平衡，以创建一个适用于当今和未来处理器的高度模块化、灵活的游戏引擎。

什么是 Smoke？

Smoke 是一个在纯游戏环境中最大限度提高处理器性能的模型框架。旨在充分利用所有可用的线程，Smoke 在标准的双核英特尔® 赛扬® 处理器和支持英特尔® 超线程（HT）技术的新英特尔® 酷睿™ i7 处理器上的运行效率均相同。曾在多个展会和技术活动上公开展示的Smoke 视频演示，使用了多项现代化的游戏开发技术，包括支持物理处理的 Havok，支持音频回放的 FMOD，支持图形渲染的 Ogre* 3D 和 DirectX* 9 等等。鉴于您可能希望获得内部开发的演示，此处代码所展示的为已经完成分区、可配置的Smoke 框架产品。英特尔开发 Smoke 主要是作为一项教学工具，用于展示创建可扩充至任意数量线程的框架的能力。
我们鼓励开发人员通过检验新的线程技巧，了解通常会抑制游戏潜在线程能力的不同游戏引擎系统间的交互情况，来深入探索这项技术。英特尔希望通过 Smoke 和其它工作，帮助证明可以高效地完成多线程游戏开发，而相应的时间投资也是值得的。

图 1：Smoke 框架
该框架围绕一个调度程序和一个变更控制管理器（CCM）设计而成，前者负责管理系统任务，后者负责最大限度减少线程游戏的传统缺陷：线程同步。数据结构在 Smoke 框架的多个任务和线程间共享数据，旨在通过易于开发的接口支持独立处理和系统模块性。

图 2：CCM 负责系统间的通信。
CCM 负责系统间的通信。CCM（参见图 2）可降低框架对于繁重线程同步操作的依赖性。例如，如果物理 API 系统更改的对象也在其它系统进行了注册，则无需将该更改直接发送给这些系统，它们会在当前帧结束时获知这一更改，从而可继续独立地处理当前帧。

图 3：SystemAI 和 SystemGraphic 正在订阅来自SystemPhysics 的位置变更。

图 4：可简化系统间通信的接口。

图 5：工作线程被从可用处理工作池分配给任务。.
当所有这些任务创建完成后，它们会被集中到一个所有可用工作线程能够访问的池中。合理设计的框架可支持每个内核一个工作线程，而这也正是设计的能力和可扩充性真正开始大显身手的领域。之后，根据每个特定线程的负载情况以及框架对于每项任务处理器密集程度的估计，池中的每项任务会分配给线程（参见图 5）。关于以下方面，Smoke 开发人员承认还存在问题：跨每个线程恰当地平衡任务负载要求对每项任务中的工作有些预先确定的了解。显然，在非常轻量级的框架中——如本例中的框架，我们是很难获得此类信息的。

图 6：每个工作线程均有一个 CCM 可以访问的更改队列。
在处理当前帧期间，不同的工作线程和任务会向 CCM 发布讯息（参见图 6），以显示所有已注册对象的最新状态信息。当帧完成后，CCM 会在下一个帧开始处理前，将这些讯息发送给已经订阅了最新对象的相应系统，由此最新数据可通过框架进行传播。通过重复这个过程，我们就可以获得完全线程化、独立处理的游戏引擎模型。

运行中的 Smoke 演示
为展示该框架的强大能力，英特尔制作了一个图形演示，通过它观看者可亲眼见证框架的性能优势。该场景描绘了一座农舍正在受到空降陨石的围攻，降落的陨石导致周围的树木燃起了熊熊烈火（参见图 7）。
 图 7：所有八个处理线程全部运行情况下的 Smoke 演示。

图 7 展示了在基于英特尔® 酷睿™ i7 处理器的系统上，按 74 fps 的帧率，以所有八个线程运行演示的情况。 您可以看到，性能框中的所有八个 CPU 的负载量基本持平，CPU 总使用率在高于 80% 的范围内。您还可以看到演示中各个系统的工作负载细分情况，包括程序火、树、人工智能、物理引擎等等。

图 8：采用四个处理线程运行的演示同一区域

图 9a：在仅有两个活动线程的情况下，演示的性能受到巨大影响。

图 9b：同样的工作可以由一个工作线程来完成，但性能会受到影响。
图 9a 和 9b 展示了同一场景分别采用两个工作线程和一个工作线程运行的情况；每往下一步，性能就会大幅降低。演示采用八个工作线程运行，要比采用一个工作线程速度快 6.7 倍多，这表明借助合理实施的多线程游戏引擎，开发人员可以真正提高具有任意数量处理内核的系统的性能。

Smoke 在当今的意义

尽管我们可以立即得出结论，这个多线程化的框架在构建时便考虑到了英特尔的全新多核图形架构，但在当今的游戏引擎中采用 Smoke 类的设计仍具有明显的优势。借助当前的英特尔® 酷睿™ i7 处理器，具有四个超线程内核的系统（由此可支持八个逻辑线程）将进入游戏领域。充分利用这一处理能力无疑是一项挑战，而与本文所述类似的设计可支持游戏开发人员使用远远超出当今游戏作品需求的处理动力。

英特尔的软件开发团队构建 Smoke，仅仅是为了证明高效线程化的游戏引擎对于任意数量的线程都是可能的。尽管我们不希望游戏开发人员直接采用我们的设计，并将这一框架完全复制到他们自己的游戏中，但英特尔还是在 http://Whatif.intel.com 上为所有游戏开发人员免费提供了代码，以帮助向市场传达凭借当今和未来的 CPU 硬件所能成就的无限可能。
虽说让软件充分利用电脑中的硬件不仅仅是个技术问题，但随着全球市场越来越看重高能效、绿色技术，这对于当前和未来的计算也变得日益重要。尽管我们明确希望看到各个处理领域效率的提高，但游戏也同等重要和有利：毕竟，如果一点娱乐都享受不到，所有工作又有什么用呢？

英特尔 Smoke 框架是一个出色的前瞻性范例，展示了软件开发人员如何利用英特尔硬件提供最佳的用户体验。

作者简介
Orion Granatir 是英特尔视觉计算软件部门的高级工程师，是 Smoke 项目的技术负责人。在 2007 年加入英特尔之前，Orion 曾在 Insomniac Games 公司担任高级程序员，从事了多款 PlayStation 3* 作品的开发工作。他的最新作品包括：《抵抗：灭绝人类（Resistance:Fall of Man）》*和《瑞奇与叮当未来：毁灭工具（Ratchet and Clank Future:Tools of Destruction）》*。

Ryan Shrout 早在上中学的时候就创建了面向硬件发烧友的网站，年纪轻轻便借助计算机开始了自己的职业生涯。经过八年多的发展，如今这家网站已经成为最大的技术编辑站点。作为 PC Perspective（pcper.com）的主编，Ryan 总是以批评的目光审视 CPU 和 GPU 设计，重点关注其底层技术和所能带来的实际优势。

 原文参看： http://software.intel.com/en-us/articles/performance-scaling-with-cores/

第一天, 星期一, 2008 年八月10日 (进场):

在展示区域安装设备		展台设备拆箱
在英特尔展台剧院搭建		在英特尔展台剧院安装设备
第二天, 星期二, 2008年八月11日 (展览日, 第一天):
洛杉矶会议中心外景		英特尔SIGGRAPH展台的演示
英特尔软件网路的博客区域		英特尔展台剧院区域的人群
英特尔展区工作人员Gina Bovara & Quentin Froemke的快乐时光		SIGGRAPH入口区域
第三天, 星期三,  2008年八月13日 (展览日, 第二天):
英特尔展台内的会议室		英特尔视觉计算社区经理Steve Pitzel在Artrage展区
英特尔工作人员John McHugh展示肌肉男的魅力		繁忙的展台
Autodesk展区:  英特尔工作人员Ben Kutcher (右)		英特尔工作人员Gina Bovara和4位新的英特尔软件网络成员
英特尔Take Five视频摄像Amy Barton和Jerry Makare		英特尔工作人员Staffer Joel DeGuzman在介绍英特尔软件网络
第四天, 星期四, 2008年八月14日 (展览日, 第三天):
英特尔工作人员Joel DeGuzman和Janet Holmes在英特尔软件网路及合作伙伴展示区域		位于展示区域的英特尔集群就绪服务器
展台内的讲座区域由Orion Granatir主讲		展台内讲座区域人头攒动
展示结束，拆卸工作开始		展台内展示区域拆卸工作

体验令你心跳加速的视觉计算技术! 
了解我们在SIGGRAPH 的主要活动细节 PDF (383kb).

同时浏览我们于八月4日发布的论文:
"Larrabee: 一个用于视觉计算的多核x86架构" (.PDF, 2.10 MB)

同时还有会议现场英特尔展台的照片!

我们最新的关于SIGGRAPH的博客: Gathering Feed Info, one moment...   我们最新的SIGGRAPH视频: 访问我们的中文 Take Five 视频主页 访问我们的英文 Take Five 视频主页   SIGGRAPH 相关链接: 添加我们 英特尔 @ SIGGRAPH Facebook 页面 SIGGRAPH 官方主页 视觉计算的就职机会		会议课程安排:   2008年8月11日 (星期一) 6:00PM 至 8:00PM (Hall B) "Papers Fast Forward; 60 Second Presentation" 演讲人 Larry Seiler   2008年8月12日 (星期二) 10:30AM 至 11:15AM (Hall B) "Larrabee: A Many-Core x86 Architecture for Visual Computing" 演讲人 Larry Seiler   2008年8月14日 (星期三) 8:30AM 至 12:15PM (403AB) "Beyond Programmable Shading:  Fundamentals" 是一个由Aaron Lefohn协调安排的包含Tom Forsyth介绍Larrabee架构的部分以及Aaron讲授的Larrabee编程介绍   1:45PM 至 5:30PM (403AB) "Beyond Programmable Shading:  In Action" 是一个由Aaron Lefohn协调安排的包含Matt Pharr 介绍Larrabee高级渲染技巧的话题   8月11-15日 (星期一到星期五) 请参观访问由英特尔赞助的 The Studio（工作室）    8月12-14日 (星期二到星期四) 在展览区域参观英特尔的展台(#513)

在此处了解有关英特尔® 集成显卡的更多信息： 英特尔® 集成显卡的常见误解 英特尔® 集成显卡快速参考指南 英特尔® 图形助推器（GMA） 3000 与 X3000 开发人员指南 英特尔® 3000 和 X3000 调试工具与技巧 所有图形技术： 在DirectX实现Ping Pong纹理算法 NEW! 高品质、高带宽视频的压缩  - 英特尔出版社书籍 最新节选！  加速视频编码例程的运行  视频粗差检测 （视频）英特尔® 集成性能基元（英特尔® IPP）与媒体应用   IPP 中新添光线追踪/渲染功能！  支持、工具与代码范例  基于英特尔® 显卡的游戏指南支持 显卡芯片组驱动程序

一个CG角色的存在仅限于显示设备上的这些像素点吗？ Half-Life2和Crysis仅因为是纹理贴图而正点吗？ 物理，人工智能甚至音效在您的游戏体验中扮演哪种角色？ - Pitz   视觉计算(Visual Compting) 多线程架构上的实时深海模拟 新！ 在主流显卡硬件上创建阴影锥（Shadow Volume） 借助分数布朗运动生成程序地形 新！  IPP中的光线追踪函数 英特尔信息技术峰会 上海站 视觉计算专场主题演讲  英特尔副总裁, 软件及解决方案事业部总经理 蕾妮詹姆斯 游戏上的图形应用 轻装上阵，畅玩游戏  主流显卡硬件上的实时阴影贴图 升级版！  对毛发较短生物的实时毛发渲染  升级版！ GDC大会 Intel/Havok 专题内容  谁代表我们参加了 GDC? 查看这里: 成功案例 GameCreators Multiverse NetDevil TD Vision 已经开发了游戏软件? 成为我们的软件合作伙伴吧。 了解为何加入英特尔软件合作伙伴计划能帮助您的游戏发挥到极致。

本白皮书主要介绍一些在主流图形硬件上实时生成阴影的技术。阴影可增加 3D 图像的逼真度。纹理精确度低会导致阴影贴图受到抗锯齿假象的影响，而阴影锥可以从物理角度创建准确的阴影，避免上述问题。然而，如果存在多个产生阴影的动态对象或大量移动光源，这种技巧就会严重影响性能。本文阐述了如何利用多线程方法采取 CPU 生成阴影锥，从而将图形硬件从这一任务瓶颈中解放出来。

	for (int i=0; i<frameHeight/blockHeight; i++)
	{
		for (int j=0; j<frameWidth/blockWidth; j++)
		{
			blockMatch(refFrame, stepBytesRF,
curFrame+stepBytesCF*i+j*blockWidth, stepBytesCF, matchBlock[i][j]);
		}
	}

            

#pragma omp parallel for
	for (int i=0; i<frameHeight/blockHeight; i++)
	{
		for (int j=0; j<frameWidth/blockWidth; j++)
		{
			blockMatch(refFrame, stepBytesRF,
curFrame+stepBytesCF*i+j*blockWidth, stepBytesCF, matchBlockOptimized[i][j]);
		}
	}

            

	for (int j=0; j<frameWidth-blockWidth; j++)
	{
		temSum = 0;
		pCur = curBlock;
		pRef = refFrame+i*stepBytesRF+j;
		ippiSAD4x4_8u32s(pCur, stepBytesCB, pRef,
stepBytesRF, &temSum, IPPVC_MC_APX_FF);
		if (temSum < lowSum)
		{
			lowSum = temSum;
			matchBlock[0] = j;
			matchBlock[1] = i;
		}
	}

            

英特尔® 高性能多媒体函数库（英特尔® IPP）

《英特尔® 高性能多媒体函数库：如何使用英特尔® IPP 优化软件应用程序》 
作者 Stewart Taylor。可通过英特尔出版社获取

以下文章来源于网络，供大家在参考。

英特尔® 集成显卡相关的文章 

CNET CHINA 中关村在线：
1G还是2G？内存升级前后效能对比测试

CNET CHINA 中关村在线：
引爆集显潜能 内存升级性能对比测试 

英特尔® 集成显卡 

 流行科学：
制作视频游戏的硬科学，作者：Jacob Ward、Doug Cantor 和 Bjorn Carey
 Tom 的硬件（Tom’s Hardware）
《英特尔® 集成显卡足以支持游戏么？》——作者：Bruce Gain 
Softpedia 
《英特尔® 集成显卡实现性能飞跃》——作者：Alexandru Pancescu
硬件地带（The Hardware Zone）
《Mobo回顾》——作者：Zachary Chan
Engadget.com 
《在英特尔的 Crestline 集成显卡上运行 DirectX 10》——作者：Paul Miller