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:

  1. 读Tile中的Geometry信息。
  2. 绘制灯光的包围盒,进行光照计算。
  3. 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.

对此我只能说,这么大点事,各家都有扩展了,居然反复撕逼没有定下来,也是很尴尬。

参考资料:

  1. Understanding GPU Family 4
  2. Vulkan Specificaiton 1.1.98 Core