消耗像素 - 在 ARM Mali GPU 上着色的新优化

look_w

不可见像素成本高昂
着色像素很贵，因此需要确保不浪费时间和精力对不会实际显示在屏幕上的像素进行着色。 为此，ARM® 将首创一种新颖的优化。
但在我们讨论解决方案之前，首先要清楚，为何会有不可见像素？ 要探索像素何时存在和不存在，您可能还要阅读
的 。

这里的关键问题是 - 附近的对象将被更多的远处对象覆盖，将其隐藏。 如果前景有一座山挡住（隐藏），则在地平线上没有点详细绘制翡翠城。 如果在发现被过度绘制前已经花了时间和精力在渲染翡翠像素上，则这在性能、时间、电池使用寿命及 karma 上都可能是一种浪费。
减少负载
有多种现成方法可降低过度绘制像素的成本。 第一种方法是应用使用其场景知识来避免将几何发送至图形驱动程序。 这非常适合封闭的在房间内的游戏，但在游戏引擎中需要附加逻辑。 对于常见场景类，确定哪些对象遮蔽了其他对象确实也很困难。
即使您确实消除了一些更远处的几何，仍可能会出现隐藏您绘制的几何的情况。 也许在同一个房间内还有一个和您一样的对手玩家 - 您可以看到他们的头盔，但其他的部分都在箱子后面。 您不想对整个人物的像素进行着色，而对他的帽子顶部着色就够了。
使用一个简单的连同“早期”深度测试，可在我们开始对像素着色前确定较远处的对象的像素被较近处的像素隐藏。
通过以递增的距离顺序对对象进行排序，并先绘制最近的对象，可帮助进行此过程，并消除过度绘制图像中的大部分隐藏像素。 当然反过来不可行，因为流水线并非通灵，无法知道后面会绘制什么...而是保持那种想法。
但从前到后的排序有一些其他的问题。
对于半透明对象，从前到后是错误的绘制顺序，因为它们需要与其后面的对象混合在一起。 而且仅先对这些对象进行排序需要时间。 更糟的是，现代图形  ( 和 ) 的结构并不真的包括“场景中的对象”概念，因此您必须自行跟踪这一点并以可接受的顺序进行绘制。
避免这一工作的另一种方式是尽量延迟着色，首先仅快速计算深度并存储有关每个像素上哪个对象在前面的数据，并且仅在计算完所有像素后，运行完全照明计算。
效果非常好。 至少在您遇到违反规则的事情之前一直很好。 也许这是写下其自己深度的像素。 也许是半透明对象。 一旦发生这种情况，就必须回到更“强力”的操作模式以便跟踪其他数据。 故障切换并不轻松，因为一旦检测到任何特殊情况，性能就会显著下降，随着游戏引擎努力变得越来越具真实感，这种现象就越普遍。
因此技术介绍文章结尾不可避免地出现反问句，我们能够做些什么？
Forward Pixel Kill

在支持 FPK 的 GPU 中，对像素进行着色的线程并非一旦启动即势必要完成。 如果发现稍后的线程将向相同像素位置写入不透明数据，已在进行的计算可随时终止。 由于每个线程需花一段时间完成，我们有一个时间期可用于消耗流水线中已有的像素。 实际上，我们利用流水线的深度来模拟我早期提到的“通灵”预见未来的效果。

这对基于区块的渲染器（如 ARM Mali GPU）尤其奏效。 即使是最适中的消耗区，这也可能产生与从前到后绘制顺序一样好的结果，但无需对场景进行排序（具有硅面积、电源和内存带宽的后续开销）。 因此无需修改应用程序以添加排序算法。 此外，由于绘制以相同自然顺序继续，半透明内容工作正常，无需会降低性能的昂贵解决方法。
并且最好的一点是操作机制之间的过渡是柔和的 - 更像是稳定的速度调整而不是换档。 不一致的帧率（有时称为 "jank"）对用户来说极其恼人，因此显著降低场景渲染时间中的不确定性的任何技术对用户和开发人员等人来讲都是受欢迎的。
Sean Ellis 是 ARM 媒体处理分部的一名技术人员。 他从 1988 年就开始从事 3D 图形工作，包括处理 ARM 最初的机器 Archimedes。 他在制定 Java 移动 3D 图形标准（M3G 和 M3G2）这一规范的过程中发挥了关键作用，目前正致力于定义下一代 ARM GPU 的架构。 他也参与专利工作，帮助保护 ARM 在多媒体领域的创新成果。