SPIRV-Cross/reference/opt/shaders-msl
Chip Davis 2eff420d9a Support the SPV_EXT_fragment_shader_interlock extension.
This was straightforward to implement in GLSL. The
`ShadingRateInterlockOrderedEXT` and `ShadingRateInterlockUnorderedEXT`
modes aren't implemented yet, because we don't support
`SPV_NV_shading_rate` or `SPV_EXT_fragment_invocation_density` yet.

HLSL and MSL were more interesting. They don't support this directly,
but they do support marking resources as "rasterizer ordered," which
does roughly the same thing. So this implementation scans all accesses
inside the critical section and marks all storage resources found
therein as rasterizer ordered. They also don't support the fine-grained
controls on pixel- vs. sample-level interlock and disabling ordering
guarantees that GLSL and SPIR-V do, but that's OK. "Unordered" here
merely means the order is undefined; that it just so happens to be the
same as rasterizer order is immaterial. As for pixel- vs. sample-level
interlock, Vulkan explicitly states:

> With sample shading enabled, [the `PixelInterlockOrderedEXT` and
> `PixelInterlockUnorderedEXT`] execution modes are treated like
> `SampleInterlockOrderedEXT` or `SampleInterlockUnorderedEXT`
> respectively.

and:

> If [the `SampleInterlockOrderedEXT` or `SampleInterlockUnorderedEXT`]
> execution modes are used in single-sample mode they are treated like
> `PixelInterlockOrderedEXT` or `PixelInterlockUnorderedEXT`
> respectively.

So this will DTRT for MoltenVK and gfx-rs, at least.

MSL additionally supports multiple raster order groups; resources that
are not accessed together can be placed in different ROGs to allow them
to be synchronized separately. A more sophisticated analysis might be
able to place resources optimally, but that's outside the scope of this
change. For now, we assign all resources to group 0, which should do for
our purposes.

`glslang` doesn't support the `RasterizerOrdered` UAVs this
implementation produces for HLSL, so the test case needs `fxc.exe`.

It also insists on GLSL 4.50 for `GL_ARB_fragment_shader_interlock`,
even though the spec says it needs either 4.20 or
`GL_ARB_shader_image_load_store`; and it doesn't support the
`GL_NV_fragment_shader_interlock` extension at all. So I haven't been
able to test those code paths.

Fixes #1002.
2019-09-02 12:31:10 -05:00
..
amd MSL: Support the SPV_AMD_shader_trinary_minmax extension. 2019-07-13 16:43:57 -05:00
asm Update tests to account for all non-entry-point functions being inlined 2019-08-30 09:39:06 +12:00
comp MSL: Add support for sampler Y'CbCr conversion. 2019-09-01 18:35:53 -05:00
desktop-only MSL: Add {Base,}{Vertex,Instance}Index to bitcast_from_builtin_load. 2019-08-29 13:56:37 +02:00
flatten Tests run clean. 2019-07-22 10:23:39 +02:00
frag Support the SPV_EXT_fragment_shader_interlock extension. 2019-09-02 12:31:10 -05:00
intel MSL: Support the SPV_INTEL_shader_integer_functions2 extension. 2019-07-15 09:42:36 -05:00
legacy/vert CompilerMSL support matrices & arrays in stage-in & stage-out. 2018-06-12 11:41:35 -04:00
tesc Fix tests for device->constant address space change in MSL tessellation control shader generation. 2019-04-10 18:37:04 +01:00
tese MSL: Rewrite how resource indices are fallback-assigned. 2019-06-21 12:54:08 +02:00
vert Merge pull request #1141 from troughton/inline-everything 2019-08-30 11:05:04 +02:00
vulkan MSL: Add {Base,}{Vertex,Instance}Index to bitcast_from_builtin_load. 2019-08-29 13:56:37 +02:00