Add VkPhysicalDevicePortabilitySubsetFeaturesKHR:: shaderGraphicsFuzzConformance capability

[billhollings]

Some CTS tests fail on shader form/syntax variations derived by the GraphicsFuzz testing framework.

This is most likely 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:: shaderGraphicsFuzzConformance capability.

This affects 6 CTS tests:

dEQP-VK.graphicsfuzz.always-discarding-function
dEQP-VK.graphicsfuzz.cov-apfloat-undefined-matrix-mul
dEQP-VK.graphicsfuzz.cov-bitfieldreverse-loop-limit-underflow
dEQP-VK.graphicsfuzz.cov-instruction-simplify-mod-acos-undefined
dEQP-VK.graphicsfuzz.cov-instruction-simplify-mod-sqrt-undefined
dEQP-VK.graphicsfuzz.spv-copy-object
  Fail (Fail)

Fixed: dEQP-VK.graphicsfuzz.stable-binarysearch-tree-false-if-discard-loop

[kvark]

I don't think having "GraphicsFuzz" in the flag name is a good thing. This fuzzer examines capabilities guaranteed by SPIR-V, and if Vulkan Portability can't fulfill those capabilities, the flag needs to reflect the semantics instead of referring to one of the clients.

[cdavis5e]

This appears to be multiple separate issues:

• The first failure is caused by SPIRV-Cross failing to flush phi variables when the condition block of a merge-to-direct loop is one of the phi parents. (A phi value is one that depends on which basic block (the unit of the control-flow graph) branched to the basic block that contains the phi value. In SPIRV-Cross terminology, a "merge-to-direct loop" is one where the loop header block, with the OpLoopMerge instruction, doesn't also have the loop condition check in it--instead, it has a direct branch to the block with the condition.) This caused the shader to depend on an uninitialized value, which is undefined behavior.
• The second failure involves subtracting 1 from 0x80000000 (the most negative signed 32-bit integer) produced by a BitfieldReverse on constant 1, which should cause it to wrap around and become 0x7FFFFFFF; a variable which was set to 1 is then compared to it, and this comparison is now supposed to succeed. Instead, the MSL compiler assumes the comparison cannot ever succeed--likely because wrapping is undefined behavior--so it strips out the comparison and its entire true branch, which causes the test to fail.
• The third failure... somehow, discard_fragment() is getting called, even though the branch shouldn't be taken. A GPU capture sheds no light on this; it indicates that in fact, the branch is not taken and the fragment should not be discarded, but it is discarded (i.e. the color attachment remains unchanged). Something is very wrong here.

I've also found two new failing tests:

• dEQP-VK.graphicsfuzz.spv-copy-object: this produces a shader that fails MSL compilation.
• dEQP-VK.graphicsfuzz.struct-controlled-loop: another shader that fails MSL compilation.

The dEQP-VK.graphicsfuzz.stable-binarysearch-tree-false-if-discard-loop failure has also returned; the shader fails to compile.

[billhollings]

dEQP-VK.graphicsfuzz.spv-copy-object fixed in SPIRV-Cross PR.