Add support for DirectX Raytracing (DXR) (#451)

* Add support for DirectX Raytracing (DXR)

This is an initial pass to add support to Slang for the shader stages introduced by DirectX Raytracing (DXR).

* Add declarations for DXR intrinsic types and functions to the Slang standard library. The way our compilation works, these will then get propagated through the IR as intrinsics and get spit back out again as-is during HLSL code emission.

* Declare the DXR-related stages. This is the main work that affects the compiler's C++ implementation rather than being something we can add via the standard library today.

* Switch around the encoding of the `Profile` type so that the stage is in the low bits, allowing API users to pass an ordinary `SlangStage` to operations that expect a `SlangProfileID`.

  - This represents a direction I'd like to push in long term, where the user specifies stage and "feature level" separately rather than using composite profiles like `vs_6_0`. The introduction of these new stages seems like a good point to try and make a clean break here and not introduce, e.g., `rgs_6_1` for ray generatin shaders.

* Upgrade "effective profile" computation so that it advances the required version based on the specified stage (e.g., DXR stages seem to require at least shader model 6.1).

  - This is a bit of a kludge overall, but ideally we don't want a typical user to have to think about "feature level" stuff much at all. The ideal workflow is that they just hand us a source file and we work out entry points and their required feature levels in the compiler (and let the user query it when we are done). Until we implement that for real, stopgaps like this are required.

Overall these are relatively small changes for supporting some major new API behavior. Slang's design helps out here, by allowing a lot of things to be specified in the stdlib (including generic intrinsic functions), but some of this is also owed to the DXIL-influenced design of DXR - e.g., the use of global functions in place of `SV_*` semantics.

* fixup: typos

* Fixup: use `pixel` instead of `fragment` as primary stage name

This is to match HLSL conventions when generating output code, even if the Slang project officially favors the more correct term "fragment shader."

1 files changed, 109 insertions, 0 deletions

diff --git a/source/slang/hlsl.meta.slang b/source/slang/hlsl.meta.slang
index 15579e512..7356eccbe 100644
--- a/source/slang/hlsl.meta.slang
+++ b/source/slang/hlsl.meta.slang
@@ -1121,3 +1121,112 @@ for (int aa = 0; aa < kBaseBufferAccessLevelCount; ++aa)
     sb << "};\n";
 }
 }}}}
+
+
+// DirectX Raytracing (DXR) Support
+//
+// The following is based on the experimental DXR SDK v0.09.01.
+//
+// Numbering follows the sections in the "D3D12 Raytracing Functional Spec" v0.09 (2018-03-12)
+//
+
+// 10.1.1 - Ray Flags
+
+typedef uint RAY_FLAG;
+
+static const RAY_FLAG RAY_FLAG_NONE                             = 0x00;
+static const RAY_FLAG RAY_FLAG_FORCE_OPAQUE                     = 0x01;
+static const RAY_FLAG RAY_FLAG_FORCE_NON_OPAQUE                 = 0x02;
+static const RAY_FLAG RAY_FLAG_ACCEPT_FIRST_HIT_AND_END_SEARCH  = 0x04;
+static const RAY_FLAG RAY_FLAG_SKIP_CLOSEST_HIT_SHADER          = 0x08;
+static const RAY_FLAG RAY_FLAG_CULL_BACK_FACING_TRIANGLES       = 0x10;
+static const RAY_FLAG RAY_FLAG_CULL_FRONT_FACING_TRIANGLES      = 0x20;
+static const RAY_FLAG RAY_FLAG_CULL_OPAQUE                      = 0x40;
+static const RAY_FLAG RAY_FLAG_CULL_NON_OPAQUE                  = 0x80;
+
+// 10.1.2 - Ray Description Structure
+
+__builtin struct RayDesc
+{
+    float3 Origin;
+    float  TMin;
+    float3 Direction;
+    float  TMax;
+};
+
+// 10.1.3 - Ray Acceleration Structure
+
+__builtin __magic_type(UntypedBufferResourceType)
+struct RaytracingAccelerationStructure {};
+
+// 10.1.4 - Subobject Definitions
+
+// TODO: We may decide to support these, but their reliance on C++ implicit
+// constructor call syntax (`SomeType someVar(arg0, arg1);`) makes them
+// annoying for the current Slang parsing strategy, and using global variables
+// for this stuff comes across as a kludge rather than the best possible design.
+
+// 10.1.5 - Intersection Attributes Structure
+
+__builtin struct BuiltInTriangleIntersectionAttributes
+{
+    float2 barycentrics;
+};
+
+// 10.2 Shaders
+
+// Right now new shader stages need to be added directly to the compiler
+// implementation, rather than being something that can be declared in the stdlib.
+
+// 10.3 - Intrinsics
+
+// 10.3.1
+void CallShader<param_t>(uint ShaderIndex, inout param_t Parameter);
+
+// 10.3.2
+void TraceRay<payload_t>(
+    RaytracingAccelerationStructure AccelerationStructure,
+    uint                            RayFlags,
+    uint                            InstanceInclusionMask,
+    uint                            RayContributionToHitGroupIndex,
+    uint                            MultiplierForGeometryContributionToHitGroupIndex,
+    uint                            MissShaderIndex,
+    RayDesc                         Ray,
+    inout payload_t                 Payload);
+
+// 10.3.3
+bool ReportHit<attr_t>(float THit, uint HitKind, attr_t Attributes);
+
+// 10.3.4
+void IgnoreHit();
+
+// 10.3.5
+void AcceptHitAndEndSearch();
+
+// 10.4 - System Values and Special Semantics
+
+// TODO: Many of these functions need to be restricted so that
+// they can only be accessed from specific stages.
+
+// 10.4.1 - Ray Dispatch System Values
+uint2 DispatchRaysIndex();
+uint2 DispatchRaysDimensions();
+
+// 10.4.2 - Ray System Values
+float3 WorldRayOrigin();
+float3 WorldRayDirection();
+float RayTMin();
+float RayTCurrent();
+uint RayFlags();
+
+// 10.4.3 - Primitive/Object Space System Values
+uint InstanceIndex();
+uint InstanceID();
+uint PrimitiveIndex();
+float3 ObjectRayOrigin();
+float3 ObjectRayDirection();
+float3x4 ObjectToWorld();
+float3x4 WorldToObject();
+
+// 10.4.4 - Hit Specific System values
+uint HitKind();