Metal2新特性：光栅顺序组（ROG,Raster Order Groups）

背景主题文章：【Metal引擎剖析（二）：传统延迟渲染和TBDR】

1. Raster Order Groups的作用

ROG是干什么的呢？官方解释：准确的控制并行的fragment shader线程访问同一个像素的顺序。

通俗点说，就是我们在渲染场景物体的时候，有些前后重叠遮挡的物体身上的fragment shader可能会同时访问同一个坐标的那个像素数据，造成竞争，导致结果错误。而ROG就是用来同步这个像素的访问次序，防止竞争的发生。

这样解释可能还是不够直观，这里来看官方给出的一个例子。

假设有下面这种情况，镜头场景中有两个重叠的三角形，开发者代码中绘制的时候对于这种透明物体会按照从后往前的顺序绘制，也就是先调用后面蓝色三角形的draw call，然后再调用前面绿色三角形的draw call，Metal也会按照我们代码的顺序去执行draw call指令，这样看似乎这两次draw call是依次串行执行，但实际上并不是这样，GPU上的运算过程是高度并行的，虽然CPU发出的指令是先绘制蓝三角形，但在GPU上Metal并不能保证蓝三角形的fragment shader会比绿三角形的先执行，Metal只能保证在blend混合的时候是按照draw call的顺序执行的，如下图所示：

那么问题来了，blend虽然保证串行不重叠了，但是blend之前的读写操作并无法保证串行，蓝三角形fragment shader将blend后的结果写入像素的同时，可能绿三角的fragment shader正在读取该像素的颜色，造成了竞争，如下图所示：

ROG就是解决上面这种数据读写冲突问题的。

2. Raster Order Groups解决读写冲突

ROG解决读写冲突的方式为线程同步，即同步同一个像素或者采样点（如果是per-sample着色模式）对应的thread线程。实现上，开发者只要用ROG attribute属性标记数据内存，这样多个线程访问同一个像素数据的时候就会等待当前线程写入数据结束再访问。下图展示了ROG同步两个线程，使得线程2等待线程1写入数据结束后才开始继续读取数据：

Raster Order Groups就仅仅是用来同步线程解决读写冲突的吗？不仅仅如此，Raster Order Groups在Metal2 A11上进行了扩展，作为新特性用于实现更多强大的功能，用途更广。

3. Metal2 A11新特性：Multiple Raster Order Groups

Metal2 A11开始对Raster Order Groups进行了扩展，除了可以实现同步单通道imageblock和threadgroup memory数据，还开始支持多个ROG的定义使用，开发者可以更加细粒度的控制线程的同步，进一步减少线程的等待时间。

Multiple Raster Order Groups优化渲染的典型例子就是另一篇TBDR中提到的：单Pass延迟渲染。

文中说到传统的双Pass延迟渲染，第一个Pass渲出G-buffer保存到system memory，然后第二个Pass读取system memory中的G-buffer进行延迟光照计算。然后A11的tile memory的存在得以实现Tile based shading，使得G-buffer被分成tile-sized大小从而继续保存在GPU imageblock内存中，直接继续进行延迟光照计算，在一个Pass中完成了延迟渲染，降低了数据带宽。

那么这里Raster Order Groups是如何对我们的单Pass延迟渲染进行性能优化的呢？

我们知道延迟渲染主要解决多光源场景渲染的效率问题，一般的GPU在进行多线程、多光源延迟光照计算时的过程是像下面这样的：

这种情况第二个光源想要读取G-buffer对当前像素进行光照计算时，必须等待第一个光源计算并写入结束才能开始读取G-buffer（光照计算结果和G-buffer放在一起）。

现在我们可以通过定义多个Raster Order Groups来优化这个问题。开发者只要将G-buffer中的贴图资源和光照计算结果分开放到不同的Raster Order Groups即可，例如将Lighting光照计算结果放到第一组，将G-buffer的albedo，normal，depth等放到第二组，这样A11就可以将这两组分开，第二个光源就随时可以读取第二组的G-buffer数据进行光照计算，只在写入第一组的Lighting光照计算结果时进行同步等待即可。优化后流程如下：

官方的TBDR延迟渲染Demo中单Pass的实现中已经实现了利用Multiple Raster Order Groups进行性能优化：