MoltenVK Vulkan 1.0: R32G32 multisample failures

Failing CTS tests:

dEQP-VK.renderpass.suballocation.multisample.r32g32_uint.samples_2
dEQP-VK.renderpass.suballocation.multisample.r32g32_uint.samples_4
dEQP-VK.renderpass.suballocation.multisample.r32g32_sint.samples_2
dEQP-VK.renderpass.suballocation.multisample.r32g32_sint.samples_4

Investigation results: Potential Metal driver issue

Reasoning:
Running the tests as they are with no modifications, we can see that the result image has same values for the 8x8 tiles of the 32x32 texture. Expected result has incremental values across the x and y axes instead of blocks of 8x8 with same values. The testing done to try to understand the issue leads me to believe Metal is bundling tiles and executing fragment stage once per tile instead of per fragment. Applying the following patch makes the test pass. The change doesn't really change how fragments will be shaded, but it does add some complexity (which I believe forces Metal to correctly behave). I'm inclined to believe they are applying an optimization prematurely, which leads to incorrect behavior.

The only thing that slightly confuses me is why this issue only happens for the R32G32 format and not with all the other formats. I also I don't think we have any type of variable shading enabled for this case in particular compared to the other texture formats that could affect output.

If there's something I missed, please do let me know!

Proposed solution: Report to Apple and request Vulkan waiver

cc/ @billhollings

Start by running the four listed dEQP-VK renderpass multisample tests and compare the R32G32 results with the expected incremental values. Review the linked required_changes.txt patch and the investigation notes, then determine whether the remaining work is reporting the suspected Metal driver issue to Apple and requesting a Vulkan waiver.