转自:ARM社区
澎湃S1采用Mali-T860的4核图形处理器,对比上一代Mali-T760同等性能下功耗降低了40%。支持“AFBC + ASTC”图像压缩技术,处理动态图象时功耗减少15%。图像实时无损压缩与解压缩时,内存带宽占用减少50%。—雷军
那么ARM的Mali系列GPU中的AFBC和ASTC到底是什么,如何实现功耗下降和节省内存带宽呢?
接下来给大家简单科普一下:
打造高效和高性能的系统级芯片 (SoC) 正成为一项日益复杂的任务。对带宽密集型应用程序的需求日益增长,意味着系统组件需要在每一代应用程序中都提高效率,从而能应对这些应用程序引发的额外带宽消耗。而这体现在所有市场中:随着高端移动计算平台追求更出色的性能和更高的能效,面向主流市场的 SoC 仍然需要提供优质的功能集和性能密度,同时还要降低制造成本和缩短上市时间!
如果仔细观察用户与消费电子设备之间典型的交互,就会发现他们往往将重点放在文本、音频、照片、影像、动画和视频上,换言之就是多媒体体验。而重要的是,媒体密集型用例要求大量数据传输和更高级的用户体验,对系统带宽增长的要求也就更高。但是,带宽消耗越多,功耗也越高。
那么,是哪些具体的用例和功能要求正在推动带宽呈近乎指数级的增长呢?
·屏幕尺寸和分辨率在具有各种外形和性能的情况下已迅速增大。采用高清屏幕分辨率的移动设备的数量正在迅猛增长,平板电脑目前通常采用的是2.5K 屏幕。这一趋势没有任何减缓的迹象。
·媒体系统每秒显示的帧数必须要提高。同时,显示屏刷新率也要提供更加夺目的用户体验。实际上,60FPS 成为必备选择已有一段时间,一些高端用例现在已上升到 120FPS。
·计算每一场景所需的计算吞吐量已经增加。高端游戏和用例要求通过更加复杂的计算来呈现每一个最终像素。在每像素级别上提高运算吞吐量意味着需要传输和处理更多的数据。
总而言之,要提供的像素在增加,速度也要加快,同时每一帧上计算各个像素所需的工作量也在加重。所有这一切不仅要求更高的计算性能,还需要更多的带宽。除非 SoC 设计师在设计媒体系统时事先考虑到这一点,否则在提供高质量用户体验时将消耗更多的功率。
那么,我们该如何应对呢?典型的媒体系统由多个 IP 组件组成,其中的每一个组件在功能和特征上都略有不同。媒体处理流水线的各级由单独的块负责,它们(如 Sean 的博客中所述)都具有输入、中间数据和输出,所有这些都包括在总功耗预算内。
更进一步来看,典型的媒体流水线包含 GPU、视频处理器和显示处理器之间的多种交互,需要在这些组件之间传递一定量的数据。乐观地说,这意味着有大量的机会可以优化这些交互,提供能够通过高效协作节约带宽的组件。正因如此,ARM 开发了一系列带宽减少技术:使得在移动设备电能有限的情况下,最好地支持多媒体。
AFBC - 降低媒体系统中的带宽(ARM Frame Buffer Compression)
现在,我们来更仔细地看看 GPU、视频处理器和显示处理器之间的交互。其中一个带宽最密集的用例是视频后处理。在许多用例中,GPU 在将视频流用作 2D 或 3D 场景中的纹理时需要读取视频并应用特效。在这样的情形中,ARM 帧缓冲压缩 (AFBC) 这种具备精细随机访问能力的无损图像压缩协议和格式能够最大程度地减少 Soc 内 IP 块之间的数据传输量,将系统级别的总体带宽和功耗最多降低 50%。
在 SoC 中使用 AFBC 时,视频处理器只需以压缩格式写出视频流,GPU 则读取它们并且仅在片上内存中解压缩它们。完全相同的优化将应用到用于屏幕的输出缓冲。无论是 GPU 还是视频处理器生成最终的帧缓冲,它们都会被压缩,因此显示处理器将以 AFBC 格式读取它们并且仅在移到显示内存中时进行解压缩。Ola 发表的博文 Mali-V500 视频处理器:利用 AFBC 降低内存带宽,对 AFBC 进行了更为深入的介绍。
ASTC - 灵活、尺寸更小,质量更高(Adaptive Scalable Texture Compression)
那么 GPU 与高端游戏或用户界面等图形应用程序之间的交互怎样?这是对纹理资源要求的内存量进行优化的绝佳机会。自适应可扩展纹理压缩 (ASTC) 技术由 ARM 和 AMD 联合开发并赠予 Khronos,已作为 Open GL® 和 OpenGL® ES 图形 API 的官方扩展加以采用。在缩减内存带宽、降低能耗,同时又维持图像质量上,ASTC 跨出了一大步。
ASTC 规格包含两个配置:LDR 和 Full,这两者都在 Mali-T62X GPU 及以上版本中受到支持,详细的介绍可参见 Tom Olson 和 Stacy Smith 发表的博文。