Apple – Metalが他のアーキテクチャ上で動く可能性

一行もコード書いてないですが、とりあえずWWDC2014のMetal関連セッション3つは見ました。んで感じたことをひとつだけ。

MetalのMTLRenderCommandEncoderについて

MTLRenderCommandEncoderは、アプリが実際に描画命令を積み込むためのインターフェースとなるオブジェクトで、これを取得する際には、MTLFramebufferを指定する必要がある。つまり、ひとつのEncoderの中で、FramebufferのBindingの変更は出来ない。
また、Framebufferの作成の際には、ひとつ厳しい制限がある。RenderTargetはカラーに関しては4つ設定することが出来るが、カラー全体で、16Byte/fragmentを超えてはいけない。さらに、4byte/pix以下のフォーマットのRTは、4Byte/pixとして数えるというものがある。
これが意味するところは、ひとつのEncoderにおけるレンダリングは、必ずTileキャッシュに収まり、On-Chip Renderingになるようになっているということ。逆をいえば、それ以外のMRTレンダリングを認めていない。
さらに、FrameBufferの各アタッチメントとなる、MTLAttachmentDescriptorでは、loadAction/sotreActionが指定できるので、レンダリング全体における、MTLRenderCommandEncoderの切り替わりの境界でも、Off-Chipからの読み込みと書き出しを細かく制御することが出来る。また、MSAAのResolveのこの境界で行われる。
徹底して、On-Chipレンダリングを推進するAPIとなっている。

Metal以前の話

最近では、On-Chipレンダリングは、Shader Pixel Local Storageという名で、ES3.0のEXT拡張を用いることで同様の機能が実現されていた。下記のESのEXT拡張は、主にARMが主導したと思われるが、IMGの方もControibutorに名前を連ねているので、両者の合意の元で実現された拡張といえると思う。（だからEXT拡張）

EXT_shader_pixel_local_storage – Khronos
Challenges with high quality mobile graphics – SIGGRAPH 2013 ARM, Geomerics
Shader Pixel Local Storage – ARM

注釈：On-chip Deferredレンダリングについて

上記のARMのサンプルにもあるとおり、On-Chipレンダリングのひとつの有用な使い道として、Deferredレンダリングがある。PowerVRもMaliもTBDRを採用しているが、このTBDRアーキテクチャ上で、DeferredレンダリングをTileキャッシュ上で行うと、Off-chipへのアクセスを最小限に留めつつ、Deferredレンダリングを行うことが出来る。
具体的には、シェーディングに必要な全ての情報(G-Buffer)をTileキャッシュ上に構築し、最後にFullScreenQuadでシェーディングを行い、最終結果のRTのみ、Off-Chilpへの書き出すというもの。
通常のDeferredレンダリングは、G-Buffer構築時のメモリ帯域に対する負荷が大きいが、On-Chip Deferredの場合は、このメモリ帯域負荷が無い。加えて、G-Bufferの読み出しも、On-Chipアクセスとなるので、通常のテクスチャよりも高速なSamplingが期待できる。
中間で使用するG-BufferはOff-Chipから読み込みを行う必要もなければ、書き出す必要も無い。レンダリングの開始時にクリアすればよいだけである。したがって非常にメモリアクセス効率の良いDeferredレンダリングとなっている。

Metalが他のアーキテクチャ上で動く可能性

Metalは上記のような設計なので、一見すると現世代GPUなら、どれでもそれなりに効率よく動作するAPIに見えますが、根本にTBDRを前提とした設計があり、これに関する拡張性やコンフィギュレーションの違いを吸収する仕組みが見当たらなく、ドキュメントにもはっきりと制限事項を記述しているので、当分の間は、GPUアーキテクチャに幅を持たせる気は無いと思われます。
PowerVR以外では「Maliなら効率良く動くかも」といったところだと思います。万一動いたとしても、Shaderは事前コンパイルのみなので、再ビルドが必要になると思われます。
せめて、FrameBufferの制限に関して、もう少し将来性を感じさせる記述があるとうれしいのですが、当分の間は16Byte/fragmentの制限は変わりそうにありません。このサイズがもう少し大きくなると、いろいろと応用範囲が広がるのですが、現状ではDeferredシェーディングを行う際でも、厳しいPackingを強いられます。
中身を見る前は、Metalが、近い将来にOSXでも使用可能になり、Appleのエコシステムで推進していくのかとも思いましたが、とりあえず今のところは、IMGのGPUに適応したAPIと考えることにします。