Add support for Vulkan raytraicng "shader record" (#735)

The syntax for this is a placeholder for now, since we will probably want to migrate to whatever gets decided on for dxc. To declare that some data should be part of the "shader record" use `layout(shaderRecordNV)` to mirror the GLSL raytracing extension:

```hlsl
layout(shaderRecordNV)
cbuffer MyShaderRecord
{
    float4 someColor;
    uint   someValue;
}
```

The intention (not enforced) is that an application would map `MyShaderRecord` to "root constants" in the "local root signature" when compiling for DXR, while the output code in GLSL will always map to the shader record in Vulkan raytracing:

```glsl
layout(shaderRecordNV)
buffer MyShaderRecord
{
    float4 someColor;
    uint   someValue;
};
```

This change does *not* support declaring a global value of `struct` type with `layout(shaderRecordNV)` (or a `ParameterBlock` with the modifiers, although that would be a nice-to-have feature) and it does *not* support having the contents of the shader record be mutable (even if GLSL/Vulkan allows it). Those can/should be added in future changes.

In terms of implementation, this closely mirrors the way that `layout(push_constant)` buffers were being handled, where the data inside the `ConstantBuffer<X>` (the value of type `X`) gets laid out using ordinary rules (and consuming ordinary `UNIFORM` storage, while the buffer itself is given a different layout resource to reflect that fact that it does not consume a VK `binding` any more, but a different conceptual resource.

Note: an alternative design here (that might actually be preferrable) would be to have both push-constant and shader-record buffers be handled as alternative aliases for `ConstantBuffer` (or maybe `ParameterBlock`) so that you have, e.g.:

```hlsl
PushConstantBuffer<X> myPushConstants;
ShaderRecord<Y> myShaderRecord;
```

This alternative design avoids API-specific decorations on the declarations, and reflects the intent of the programmer very directly, even when they are compiling for a target like D3D that doesn't reflect these choices at the IL level (it could still be exposed through the Slang reflection API).

2 files changed, 15 insertions, 2 deletions

diff --git a/tests/vkray/closesthit.slang b/tests/vkray/closesthit.slang
index 12f2dcd4a..419c22a46 100644
--- a/tests/vkray/closesthit.slang
+++ b/tests/vkray/closesthit.slang
@@ -8,6 +8,12 @@ struct ReflectionRay
 
 StructuredBuffer<float4> colors;
 
+layout(shaderRecordNV)
+cbuffer ShaderRecord
+{
+	uint shaderRecordID;
+}
+
 void main(
 	BuiltInTriangleIntersectionAttributes 	attributes,
 	in out ReflectionRay 					ioPayload)
@@ -15,7 +21,8 @@ void main(
 	uint materialID = InstanceIndex()
 		+ InstanceID()
 		+ PrimitiveIndex()
-		+ HitKind();
+		+ HitKind()
+		+ shaderRecordID;
 
 	float4 color = colors[materialID];
 
diff --git a/tests/vkray/closesthit.slang.glsl b/tests/vkray/closesthit.slang.glsl
index ef969ee1c..a056b7809 100644
--- a/tests/vkray/closesthit.slang.glsl
+++ b/tests/vkray/closesthit.slang.glsl
@@ -2,6 +2,12 @@
 #version 460
 #extension GL_NV_ray_tracing : require
 
+layout(shaderRecordNV)
+buffer ShaderRecord_0
+{
+    uint shaderRecordID_0;
+};
+
 layout(std430, binding = 0) buffer _S1
 {
     vec4 colors_0[];
@@ -34,7 +40,7 @@ void main()
     uint _S9 = _S7 + _S8;
     uint _S10 = gl_HitKindNV;
 
-    vec4 color_1 = colors_0[_S9 + _S10];
+    vec4 color_1 = colors_0[_S9 + _S10 + shaderRecordID_0];
 
     float _S11 = gl_HitTNV;
     float _S12 = gl_RayTminNV;