Add better control over image formats for GLSL/SPIR-V targets (#939)

* Add better control over image formats for GLSL/SPIR-V targets

Currently Slang emits GLSL code assuming all R/W images need to have explicit formats, and thus we try to infer a format from the element type of the image.
E.g., given a `RWTexture2D<half4>` we might infer that a qualifier of `layout(rgba16f)` should be used.

This strategy has two notable shortcomings:

* Sometimes the user will want a format that doesn't match an existing HLSL type. E.g., if they want the equivalent of `layout(r11f_g11f_b10f)`, then what should they put in their `RWTexture2D<...>` to make the inference do what they need?

* Sometimes the user knows that they don't need to specify a format *at all*, because using the `GL_EXT_shader_image_load_formatted` extension, they can still perform non-atomic load/store on images with no format specified in the SPIR-V.

This change adds two features directed at these challenges.

First, we add an explicit `[format(...)]` attribute that can be used to specify an explicit image format, including ones that don't match any HLSL type.
An example of using this new attribute is:

```hlsl
[format("r11f_g11f_b10f")]
RWTexture2D<float3> myImage;
```

For simplicity in initial bring-up, the new formats all use the same naming as formats in GLSL (this should make it easy for a programmer who knows what they expect to get in the GLSL output). We can change the naming convention for formats at a later time, so long as we keep these existing names in as a compatibility feature.

Note that this is *not* given a `vk::` prefix since the attribute should signal the programmer's intent to provide an image with that format on *all* targets (although only some targets might act on that information).

Also note that the attribute takes a string (`[format("rgba8")`) instead of a bare identifier (`[format(rgba8)]`) because this is consistent with the existing convention for attributes in HLSL.

When `[format(...)]` is left off, the default compiler behavior will still be to infer a format, but this behavior can be overidden for a single image using an explicit format of `"unknown"`:

```hlsl
[format("unknown")]
RWTexture2D<float4> mysteryMachine;
```

The second new feature is that if a user knows they are coding for a GPU that supports the `"unknown"` format in all non-atomic cases, then they can opt into making that the default for images without an explicit `[format(...)]`, using the new `-default-image-format-unknown` command-line option for `slangc`.

The new test case included with this change confirms that we correctly see the explicit formats in the output GLSL and *no* formats for images without explicit `[format(...)]` when using the new command-line option. The test stresses images declared at global scope, in parameter blocks, and in entry-point parameter lists, to try and make sure that all the relevant IR passes in the compiler preserve the format information.

* fixup: missing file

1 files changed, 19 insertions, 0 deletions

diff --git a/source/slang/ir-clone.cpp b/source/slang/ir-clone.cpp
index df9cf2bf6..b648efec6 100644
--- a/source/slang/ir-clone.cpp
+++ b/source/slang/ir-clone.cpp
@@ -239,6 +239,25 @@ IRInst* cloneInst(
     return newInst;
 }
 
+void cloneDecoration(
+    IRDecoration*   oldDecoration,
+    IRInst*         newParent)
+{
+    SharedIRBuilder sharedBuilder;
+    sharedBuilder.module = newParent->getModule();
+
+    IRBuilder builder;
+    builder.sharedBuilder = &sharedBuilder;
+
+    if(auto first = newParent->getFirstDecorationOrChild())
+        builder.setInsertBefore(first);
+    else
+        builder.setInsertInto(newParent);
+
+    IRCloneEnv env;
+    cloneInst(&env, &builder, oldDecoration);
+}
+
 bool IRSimpleSpecializationKey::operator==(IRSimpleSpecializationKey const& other) const
 {
     auto valCount = vals.Count();