Marking for "Needs Discussion" for the meeting after the next one, since we are behind the deadline for the current one.

+1 for the overall idea, but I have a concern that it adds another piece of renderpass <-> pipeline compatibility to check. Previously the attachment sample-count and formats had to match exactly so we could optimize the check to be a single pointer compare.

With this pipelines that are read-only for depth/stencil can be used for render passes with both read-only or writeable depth-stencil attachments. So we can't precompute the validation and have to check at setPipeline time. This is probably fine, but maybe we can consider having a depthReadOnly and stencilReadOnly on the GPUDepthStencilStateDescriptor?

For our implementation, there isn't any significant increase in the cost. At pipeline binding, we are currently checking the attachment formats, sample count, blend color, and stencil reference, plus the compatibility of the bindings. One extra flag is not changing the picture here. Moreover, we will combine blend color, stencil ref, and these new read-only flags into just a required bitmask, so adding flags there will be essentially free.

This is probably fine, but maybe we can consider having a depthReadOnly and stencilReadOnly on the GPUDepthStencilStateDescriptor?

I think that would be redundant. We can already see if the depth write mask is set there, and if the stencil operations are mutating.

One extra flag is not changing the picture here. Moreover, we will combine blend color, stencil ref, and these new read-only flags into just a required bitmask, so adding flags there will be essentially free.

This is cheap enough, I'll retract my comment.

LGTM

Does this need to be tracked separately from #514 on the project board?

Creating these kinds of read-only feedback loops (or, non-feedback loops, as it were) are well-defined and valid in Metal.

@kainino0x no, I added "Fixes #514" to the description.
Also, looks like we are all ready to merge this