Add VkPhysicalDevicePortabilitySubsetFeaturesKHR:: shaderEarlyFragmentTestMultisampleDepth capability

[billhollings]

Some CTS tests fail when using early fragment tests on a multisample depth texture.

This might be fixable with effort within the implementations.

In the meantime, these use cases can be disabled in CTS and reported as Not Supported, by adding a VkPhysicalDevicePortabilitySubsetFeaturesKHR:: shaderEarlyFragmentTestMultisampleDepth capability.

This affects 2 CTS tests:

dEQP-VK.fragment_operations.early_fragment.sample_count_early_fragment_tests_depth_samples_2
dEQP-VK.fragment_operations.early_fragment.sample_count_early_fragment_tests_depth_samples_4
  Fail (Sample count value outside expected range.)

[cdavis5e]

So these failures are caused by an interaction between the fixed pipeline sample mask and early fragment tests. Normally, a pipeline sample mask would be applied before early fragment tests; but on MoltenVK, it's applied after, because there's no sampleMask property in the public API, so MoltenVK sets it in the fragment shader. End result: the occlusion query the test is using reports too many samples.

To fix this properly would require us to be able to set the sampleMask on the MTLRenderPipelineDescriptor.

[billhollings]

To fix this properly would require us to be able to set the sampleMask on the MTLRenderPipelineDescriptor.

This sounds like missing Metal functionality, and not a Metal implementation bug, and won't qualify as an exemption.

Since it's not fixable in SPIRV-Cross, as the early frag test happens before the shader, does this mean that this shaderEarlyFragmentTestMultisampleDepth (or similar name) flag is indeed needed?

[billhollings]

These CTS tests are now Quality Warnings, and not Fails.