Metal tiling API vs Vulkan subpasses

Hello,

During the last call Myles expressed a concern over following the Vulkan
model of subpasses. The concern, as I understand, is twofold:

  1. Subpasses may not map well to Metal tiling API.
  2. Subpasses may not map well to possible future DX12 tiling API, if it
is ever provided.

It's hard to reason about (2) given no information about the shape of the
future API, timeline, or even the very fact that it's ever going to happen.
I don't think we should be blocking the support for subpasses because of
that reason, given the major performance improvement they provide on mobile
Vulkan.

As for (1), note that subpasses do map well to Metal-1 framebuffer reads,
so this is only about Metal-2 specific features. I looked over the docs (
https://developer.apple.com/documentation/metal/about_gpu_family_4/about_imageblocks)
and didn't find any fundamental conflict with Vulkan subpasses. Image
blocks are certainly more powerful (e.g. by having compute shader access to
the tile data), but I don't see how we'd emulate that on other APIs, so it
appears reasonable to go with Vulkan subpasses as a baseline.

Roughly, when we create a render pass, the Metal backend can figure out
what image blocks to allocate, and what passes should be writing/reading
from those image blocks (instead of attachment textures). That would allow
us to have 1 metal render pass per sub-pass, respecting the subpass
dependency barriers of Vulkan if we get them.

When a graphics/render pipeline object is created, and we provide the
sub-pass index for it, our shader translator can issue the corresponding
image block read/write instructions in the produced MSL shaders.

Please correct me if I got confused about how things work, but TL;DR: it
does appear to me that translating Vulkan subpasses to Metal-2 would work
well.

Thank you,
Dzmitry