利用多内核处理器的并行编程能实现视频代码转换

以确定良好的匹配。

有两点需要注意。第一，如果有较强的运算能力，那么可以测试较多的候选位置，从而可能找到更好的匹配，并提高压缩率。可以用运算能力的增强来降低带宽要求，反之亦然。其次，相似性指标是非线性的。这意味着使用多分辨率等技巧来加快相似性匹配速度是不合适的。低分辨率时的最佳匹配不一定是高分辨率时的最佳匹配。

这里有两个基本点：数据位置和并行体系。首先，GPU是具有很高性能的处理器，但目前位于PCI Express卡上，这些卡有自己的存储器。因此为了压缩视频流，数据需要传送到视频卡上的存储器中，然后将压缩结果传回来。这一过程需要以流的形式完成，而这种流式处理与运算随时交叠，因此数据传送不会成为瓶颈。RapidMind平台正常情况下可自动管理数据，而且(能在内部硬件API支持的地方)提供深层分析功能来管理这种重叠式流处理。GPU存储器架构的其它意义还在于互相依赖的一系列步骤应尽可能保持在相同的存储器空间中。

最大程度的加速

通常在考虑一个应用是否能被加速时，人们首先会分析应用程序的各个单元，判断每个单元上需花多长时间，并利用阿姆达尔定律估计可能的加速程度。

举例来说，考虑到某个应用程序在单元A上要花10%的时间，在单元B上要花75%的时间，单元C上花5%的时间，单元D上花10%的时间。该应用程序的流程是A运行一次，然后B和C轮流多次反复运行(取决于彼此关系)，最后才是运行D。

同时假设单元A估计能加速1.5倍，B能加速20倍，C能加速2倍，D不能做任何加速。

这样理论上的最大时间缩短值是：

0.1/1.5+0.75/20+0.05/2+0.1/1=0.23

相当于加速1/0.23(正好超过4)倍。值得注意的是，虽然单元B(75%的运行时间)的加速系数达到了很大的20，但只有使所有加速步骤对总运行时间的影响比较接近的情况下才能取得最好的效果。

事实上，如果只是以B为目标，并设法使之无限加速，但总的性能仍将受限于其余单元。

使用GPU

进一步考虑使用GPU。大家可以看到B和C是反复进行的。如果只是在GPU上加速B，而让C留在主机上，那么需要不断地从主机那儿来回传送数据，从而严重影响性能。因此，即使单元C的加速幅度很小，但根据阿姆达尔定律，它对总的加速效果影响也很小。事实上，我们可能也想把C移动到GPU上以避免这些传送。

这正是视频编码所面临的境况。即使运动估计是视频压缩中最昂贵的成分，我们也不能忽略其它因素，尤其是单帧压缩和解压缩，因为运动估计的其它阶段还需要这些结果。在考虑这些因素后，阶段优化工作量就需要正比于它对总体性能的影响程度。

RapidMind平台

RapidMind平台能够用来快速实现和测试算法，并将算法应用于GPU或实际上多内核的CPU。如果有大量依附于数据的算法单元，Rapid实现就相当重要，因为所有单元必须移动到速器的存储空间，以避免出现上述数据搬移问题。然而，根据它们的总体影响，优化所有这些单元可能不具成本效益，或没有太大作用。优化工作容易使代码复杂化，并且更难维护。

RapidMind通过公共特性集向所有支持的硬件目标提供可移植性。仅使用这组公共特性也可能获得优异的性能。然而，RapidMind还提供了深层机制来访问特殊硬件特性，这种深层机制对优化可能有用，但也会影响可移植性。因此推荐的做法是软件项目首先只用公共特性实现所有必要的单元，然后(在实现完整功能后)对单元进行剖析以确定瓶颈及最有可能的改进之处，最后调整特殊单元，可能的话调整应保持在内核可移植功能集中。如果有必要进行特殊硬件的深层分析，使用RapidMind的提取功能可以隔离它的影响，原始的内核特性参考实现也可以用于实现可移植性。