From 3d60cc0ca818556b78f38a59eb5521044b8a6b71 Mon Sep 17 00:00:00 2001 From: Tim Foley Date: Fri, 30 Nov 2018 17:52:52 -0800 Subject: 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` (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 myPushConstants; ShaderRecord 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). --- tests/vkray/closesthit.slang | 9 ++++++++- tests/vkray/closesthit.slang.glsl | 8 +++++++- 2 files changed, 15 insertions(+), 2 deletions(-) (limited to 'tests') 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 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; -- cgit v1.2.3