PowerVR,可用于计算的移动GPU架构

正如我在之前发表的博文和文章中讨论的那样,Imagination一直致力于效率的提升。PowerVR ‘Rogue’架构是我们第一款设计用于计算的架构。当然,在设计过程中,充分地考虑了效率和合理性,这个方法使我们能设计出真正符合市场需求的产品,同时,在我们设计PowerVR系列移动GPU的时候,效率和功耗是两个最关键的考量因素。

性能和功耗方面的平衡

对于硬件设计来说,最简单的方法就是把每一个可能的功能都付诸实现,就好像对于移动设计而言,如果不用去考虑成本方面的影响(比如硅片面积),或者是更重要的功耗因素,那么一切都会变得非常简单。因此,在功能列表--业界标准API和功耗间,找到正确的平衡点是非常关键的,对于性能来说也是一样的。如果设计一个GPU,只想着性能强大,而不去关注成本和功耗,那么就会导致这个产品无法符合基本的市场需求。

在GPU IP的设计流程中,我们会尽力达到这种最好的平衡,在需要做的地方投入精力,而去控制那些看起来将会无用的功能(处于面积和功耗方面的考虑,这些功能将会被取消)

1

因为我们的架构着眼于现有的工作站PC市场的GPU计算API,因此对于移动市场电池供电的系统来说,有些功能就不太符合要求。这个观点被反馈到计算API的设计工作中,结果是为移动系统产生优化后的配置文件。Khronos组织提供的OpenCL Embedded Profile (EP) API就是一个很好的例子。这些针对移动领域优化的API,会忽略掉一些功能,比如一些只会用于非常少的一部分应用场景(即使有的话)的功能,或者只会用于非移动领域应用场景的功能,比如科学和学术计算(之前讨论过的,移动计算必须是 实用性的 计算)。

这里举几个例子对此,以及对功耗进行说明:
第一个有疑问的功能:支持64位浮点(FP64)。常见的浮点表示法是单精度,32位宽(FP32),对于更为极端的应用场景才会需要更大的精度值,双精度64位格式。毫无疑问,从32位向64位算法单元切换,需要在硅片面积和功耗方面付出代价,对于一个移动领域的GPU设计而言,这是一个危险信号。我们真的需要64位吗?对于FP64,答案其实很简单。

在每个计算API,甚至是那些高端的、不计功耗的PC系统中,FP64都是一个可选项。因此,添加专用硬件在移动设计中支持FP64,很明显是一个错误的决策。如果对于桌面产品而言都是一个可选功能的话,那么为什么要把它加到功耗敏感的产品中去呢?

第二个有疑问的功能:支持精确的舍入模式。舍入模式控制着数表示法最后一位的精度。这有点象四舍五入,舍去小数部分,得到最接近的整数。以12.75为例,我们的数值表示不支持两位小数,那是把它舍入成12.7还是12.8呢?另外再问一个问题:我们真的需要焦虑到底是12.7还是12.8吗?很显然,这个问题跟使用场景有关 – 举个例子,如果是12.7或者12.8百万美元跟12.7或者12.8美分相比,差异会非常大。因此,这就是功耗影响和算法实用性的权衡。舍入并不像听起来那么简单。算法越复杂,在硅片面积上付出的代价就越大,也会带来更高的功耗。

另外,如果我们已经有了大量的有代表性的数字,小数最后一位的舍入模式真的还有关系吗?举个例子,如果一个色彩通道得到一个232或者233的颜色,我们真的能说清楚吗?把许多桌面计算应用程序与移动设备的实际使用场景联系在一起,我们的团队发现舍入模式对算法结果造成的影响很小,或者根本没有影响。一个更实际的现象是:图像/视频处理在通常情况下每个通道会引入一个8位的数据,该数据必须被进行处理,并产生另一个8位的输出图像,这个处理过程会使用32位的浮点运算,远远超出了输入和输出数据的精度要求,显然,这意味着,在这种情况下,再去追求舍入的精度是在浪费硅片面积,更糟的是,是在挥霍宝贵的功耗预算。虽然由于舍入模式导致的差异性很小,我们发现在操作中的数值精度总是带有变量错误。事实上,我们尝到了苦头,因为我们是在不同的系统中运行计算API一致性的测试,当在一个Intel x86系统中运行时,我们的GPU可以通过一致性测试,但是在一个ARM系统中运行时,同样的GPU却不能通过一致性测试,是不是很奇怪?

实际上这根本不奇怪,原因就在于x86系统和ARM系统在数值精度实现上存在微小的差异。因此,如果这两个业内领先的CPU架构不能返回同样的参考数据,我们为什么需要为最后一位的舍入精度而感到烦恼呢?在大部分情况下,依赖最后的精度颗粒会使算法不稳定,因为你需要得到每一个最后一位的精度来产生正确的结果。这种临界计算会导致不稳定,在图像或者动画中,这种不稳定往往体现为闪烁和抖动,这并不是你想要的结果。上面讲了这么多,显然,在舍入模式这个话题上,最求移动GPU的低功耗是更好的选择。

从设计观点角度来做进一步澄清,GPU有数以万计的计算引擎(ALU)。给这些单元增加任何功能都会使它们变得更加复杂,这也会导致额外的硅片面积和额外的功耗,会随着整个GPU的计算引擎的数目而成倍增加。增加FP64的支持、增加更先进的舍入模式、增加异常处理、增加多精度等等,你增加的每一点复杂度都会让你付出代价。ALU设计绝对是一个需要“保持干净和简单”(或者“精益求精”)的地方,这对硅片面积,更关键是对功耗而言,非常重要。

纵观计算API的整体功能列表,还有许多其他特性,可以以最小的硅片面积或者不占硅片面积去实现,这样也有可能带来功耗的增加。在移动计算API中,它们中的许多还是以可选项形式存在,但是出于易移植性和应用程序兼容性考虑,应该要支持这些可选的特性 – 特别是有一些实际上可以降低功耗的特性。下面的表中进行了说明:

可选特性

支持

注释

在线编译

对GPU功耗没有影响,没有硬件成本(软件实现)

图像支持

符合图形需求,没有成本

3D图像支持

符合图形需求,没有成本

BGRA通道顺序

符合图形需求,没有成本

与OpenGL ES图片共享

对性能至关重要,没有硬件成本,可以降低带宽和CPU负载,有助于降低功耗

本地存储器

对性能至关重要,可以降低带宽,有助于降低功耗

FP64

是和否

是,如果确实需要,可以进行模拟;否,没有增加专用的硬件,因为这样会导致面积和功耗显著增大,在移动市场没有实际的需求—为其它的细分市场保留可选项

改进的舍入模式支持

功耗和面积显著增大,在移动市场没有实际的需求

通过我们广泛的生态系统,以及早期的访问计划,Imagination的功能集选择被确认是正确的。即使是自称为桌面系统配置文件的第三方基准测试程序,我们注意到,所有实现的效果实际上并不依赖于桌面特性或者极端的精度,因为所有测试都是在多个嵌入式配置文件实现上进行执行和运行。内部测试也证明了这一点;我们已经为移动领域开发了一些实用的应用场景,专注于图像处理。我们也确认了备选的使用场景(检查我们强大的流线型功能集),比如流体力学计算、布和刚体物理计算、甚至是视频解码器。这些都被证明不需要使用桌面配置文件功能集,如下图所示:
2

请继续关注我的下一篇文章,我将要说明我们是怎么把PowerVR ‘Rogue’设计成一个最优的GPU计算架构的。

原文链接:
http://blog.imgtec.com/powervr/powervr-gpu-the-mobile-architecture-for-c...

--电子创新网--
粤ICP备12070055号