Mali GPU: 抽象机器，第一部分 – 帧管线化-2

look_w

管线节流
观察力敏锐的读者可能已注意到，上图中片段部分的工作是三个运算中最慢的，被 CPU 和几何处理阶段甩得越来越远。这种情形并不少见；大多数内容中要着色的片段远多于顶点，因此片段着色通常是占主导地位的处理运算。
在现实中，最好要尽可能缩短从 CPU 工作结束到帧被渲染之间的延时 – 对最终用户而言，最让人烦躁的莫过于在操作触控屏设备时，其触控事件输入和屏幕中数据显示之间出现数百毫秒的不同步 – 所以，我们不希望等待片段处理阶段的工作储备变得过大。简而言之，我们需要某种机制来定期减慢 CPU 线程，当管线足够满、能够维持良好性能时停止把工作放入队列。

这种节流机制通常由主机窗口系统提供，而不是图形驱动程序本身。例如，在 Android 上，我们只有在知道缓冲方向时才能处理任何绘制运算，因为用户可能会旋转其设备，造成帧大小出现变化。SurfaceFlinger— Android 窗口表面管理器 – 可以通过一个简单方式控制管线深度：当管线中排队等待渲染的缓冲数量超过 N 个时，拒绝将缓冲返回到应用程序的图形堆栈。

如果出现这种情形，你就会看到：一旦每一帧达到“N”时 CPU 就会进入闲置状态，在内部阻止 EGL 或 OpenGL
ES API 函数，直到显示屏消耗完一个待处理缓存，为新的渲染运算空出一个位置。
   

如果图形堆栈的运行快于显示刷新率，同样的方案也可限制管线缓冲；在这一情形下，内容受到VSYNC限制”并等待垂直空白（VSYNC同步）信号，该信号告诉显示控制器它可以切换到下一缓冲。如果 GPU 产生帧的速度快于显示屏显示帧的速度，那么
SurfaceFlinger 将积累一定数量已经完成渲染但依然需要显示在屏幕上的缓冲；即使这些缓冲不再是 Mali 管线的一个部分，它们依然算在应用程序进程的 N 帧限制内。
正如上面的管线示意图所示，如果内容受到VSYNC同步限制，那么会经常出现 CPU 和 GPU 都完全闲置的时段。平台动态电压和频率调节 (DVFS) 通常会在此类情形中尝试降低当前的工作频率，以降低电压和功耗，但由于 DVFS 频率选择通常相对粗糙，所以可能会出现一定数量的闲置时间。