发帖人 Peter Harris 于 2014 年 2 月 21 日 02:54:00 在 ARM Mali Graphics
在我上一篇博文中,我开始定义一台抽象机器,用于描述 Mali GPU和驱动程序软件对应用程序可见的行为。此机器的用意是为开发人员提供 OpenGLES API 下有趣行为的一个心智模型,而这反过来也可用于解释影响其应用程序性能的问题。我在本系列后面几篇博文中继续使用这一模型,探讨开发人员在开发图形应用程序时常常遇到的一些性能缺口。
这篇博文将继续开发这台抽象机器,探讨 Mali GPU系列基于区块的渲染模型。你应该已经阅读了关于管线化的第一篇博文;如果还没有,建议你先读一下。
在传统的主线驱动型桌面 GPU 架构中 — 通常称为直接模式架构 — 片段着色器按照顺序在每一绘制调用、每一原语上执行。每一原语渲染结束后再开始下一个,其利用类似于如下所示的算法:
1. foreach( primitive )
2. foreach( fragment )
3. render fragment
由于流中的任何三角形可能会覆盖屏幕的任何部分,由这些渲染器维护的数据工作集将会很大;通常至少包含全屏尺寸颜色缓冲、深度缓冲,还可能包含模板缓冲。现代设备的典型工作集是 32 位/像素 (bpp) 颜色,以及 32 bpp 封装的深度/模板。因此,1080p 显示屏拥有一个 16MB 工作集,而 4k2k 电视机则有一个 64MB 工作集。由于其大小原因,这些工作缓冲必须存储在芯片外的 DRAM 中。
每一次混合、深度测试和模板测试运算都需要从这一工作集中获取当前片段像素坐标的数据值。被着色的所有片段通常会接触到这一工作集,因此在高清显示中,置于这一内存上的带宽负载可能会特别高,每一片段也都有多个读-改-写运算,尽管缓存可能会稍稍缓减这一问题。这一对高带宽存取的需求反过来推动了对具备许多针脚的宽内存接口和专用高频率内存的需求,这两者都会造成能耗特别密集的外部内存访问。
Mali 方式Mali GPU 系列采用非常不同的方式,通常称为基于区块的的渲染,其设计宗旨是竭力减少渲染期间所需的功耗巨大的外部内存访问。如本系列第一篇博文中所述,Mali 对每一渲染目标使用独特的两步骤渲染算法。它首先执行全部的几何处理,然后执行所有的片段处理。在几何处理阶段中,Mali GPU 将屏幕分割为微小的 16x16 像素区块,并对每个区块中存在的渲染原语构建一份清单。GPU 片段着色步骤开始时,每一着色器核心一次处理一个 16x16 像素区块,将它渲染完后再开始下一区块。对于基于区块的架构,其算法相当于:1. foreach( tile ) 2. foreach( primitive in tile )