Apple自研GPU的独有特性
相比于安卓平台GPU御三家，Apple在移动GPU新特性开发上可谓步子很快，得益于Metal这个自有图形API，一些特性可以很快地实装上去。Apple提供的一些独有特性，也是基于深度利用Tile Memory的。
相比于Vulkan，Metal2可以在Render Pass中间插入Compute Shader，这是Vulkan目前还做不到的，之前我一直在想，Tile Based Deferred Shading中Lighting的部分，可以用Compute Shader来代替呀，毕竟Compute Shader的开销比画一个三角形要来的小吧，这个想法最终在Metal2上变成现实了。
ImageBlock
这个很好理解，可以自定义Tile中每个Pixel存储的结构体。程序的自由度更高了，可以在Tile Memory中实现队列啥的（搞Order Independent Transparency）。
而Vulkan是声明一些不同类型的Attachment（需要写回System Memory上的、只存在于Tile Memory上的，以及这个Pass用不到但是不能修改的）绑上去，然后由驱动决定到底是怎样的存储布局。
Raster Order Groups
用于控制并行读写Tile中同一个像素。如果不加以控制，如果多个片元同时Blend到一个像素上去，那么就会有Data Race，Metal的解决方案是进行同步，确保读写按照三角形绘制的顺序进行。
这样一来存在一个问题，如果有这样的Pixel Shader：
- 读Tile中的Geometry信息。
- 绘制灯光的包围盒，进行光照计算。
- Blend到Tile中Color属性上去。
这样第一步就会一直等，等到上一次Blend结束，而其实这是没有必要的。
Apple提供的方案是将ImageBlock中的元素放到不同的Raster Order Group中去，这样只读的那部分，就无须等待同步，可以直接计算，直到写的那一步才需要同步。我猜是Apple只为每个Tile中的像素提供了一级同步措施，而不可能对ImageBlock中的每个元素进行单独同步，这样开销太大，也难以实现。其实我想，如果用类似Compute Shader中的InterlockedAdd同步原语，写到Color Attachment中的时候这样用colorOutput0.InterlockedAdd(color)，是不是也可以实现类似的效果，而且还更简单点？
ImageBlock Sample Converage Control
得益于可以在Render Pass中插入Compute Shader以及可以自定义ImageBlock，Apple提供可以在Render Pass中控制自定义Converage的方法。这比Vulkan就强多了，Vulkan规定Render Pass中的Attachment必须要有同样的Sample Count。
If neither the VK_AMD_mixed_attachment_samples nor the VK_NV_framebuffer_mixed_samples extensions are enabled, and if pDepthStencilAttachment is not VK_ATTACHMENT_UNUSED and any attachments in pColorAttachments are not VK_ATTACHMENT_UNUSED, they must have the same sample count.
对此我只能说，这么大点事，各家都有扩展了，居然反复撕逼没有定下来，也是很尴尬。
参考资料：
- Understanding GPU Family 4
- Vulkan Specificaiton 1.1.98 Core