WIP: Implement VK_EXT_rasterization_order_attachment_access

[csmartdalton]

Implement VK_EXT_rasterization_order_attachment_access using the "programmable blending" feature available on Apple family GPUs.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[cdavis5e]

Did you make sure that input attachments are numbered correctly in the shader?

[csmartdalton]

Did you make sure that input attachments are numbered correctly in the shader?

Thank you for taking a look! I was just prototyping under the assumption that shaderConfig.options.mslOptions.use_framebuffer_fetch_subpasses knows how to do everything already. I'm not very familiar with MoltenVK, but willing to do the work to figure it out if this is a change that MoltenVK will be interested in taking once ironed out.

The input attachments are numbered correctly in my own use case (which uses 4), but I haven't otherwise tested it. Since this internally enables framebuffer-fetch supbasses across the board, would the existing test suite be enough to ensure the color attachments are numbered correctly?

[billhollings]

Thanks for taking the initiative and submitting this.

I've marked this as WIP, as it looks like there is work to do to get this working properly for general use cases.

I ran the rasterization_order_attachment_access tests in CTS, and the results are here:

Test run totals:
  Passed:        1/282 (0.4%)
  Failed:        97/282 (34.4%)
  Not supported: 184/282 (65.2%)
  Warnings:      0/282 (0.0%)
  Waived:        0/282 (0.0%)

Details are here: rasterization_order_attachment_access-results.txt.zip