Add Vulkan/SPIR-V support for TraceRayInline() (#1737)

For the most part, this translation is straightforward because the `GL_EXT_ray_query` extension is well aligned with the DXR 1.1 `RayQuery` feature. Many function map one-to-one from one extension to the other.

A few notable details:

* The equivalent of the `RayQuery<Flags>` type is non-generic in GLSL, and the GLSL path previously didn't have support for trying to look up an intrinsic type name on an IR type declaration, so that required some tweaks to the emit logic.

* All the GLSL functions are free functions instead of member functions, but our IR doesn't recognize that distinction anyway

* The main `TraceRayInline()` call is the one that took the most tweaking, just because it takes a `RayDesc` structure for D3D/HLSL but takes individual vector sand scalars for VK/GLSL. The approach here is a standard one for how we manage this stuff in the stdlib (and I wanted to avoid adding even more `$` magic for intrinsics).

* For several other calls, the HLSL API had distinct `Candidate***()` and `Committed***()` calls that return information about a candidate hit vs. the one committed into the query. In contrast, the GLSL API uses a single call that takes an additional "must be compile-time constant" `bool` parameter to select between the two behaviors. This is even the case for one call that basically returns a value of a different `enum` type depending on the state of that `bool`. The D3D API model here seems almost strictly better and I have no idea why the GLSL extension was defined this way.

* Because both the `GL_EXT_ray_query` and `GL_EXT_ray_tracing` extensions declare the `accelerationStructureEXT` type, we can no longer infer what extension is supposed to be used based only on the presene of such a type. The logic right now is a bit slippery, because in theory a program that declares an acceleration structure but never traces into it could end up getting a compilation error now. We will have to see if that corner case comes up in practice. :(

The one big detail that is looming after doing this work is that both the HLSL and GLSL exposures of ray queries are extremely "slippery" about the actual identity of queries (e.g., when is one query a copy of another, vs. just being a new variable that references the existing query). Somehow queries get their identity from the original declaration, and as such our "default constructor" approach to them seems semanticay correct, but the whole thing is kind of slippery at a foundational level and I don't know how to fix it with the API as defined. Oh well; just something to keep an eye on.

Co-authored-by: Yong He <yonghe@outlook.com>

1 files changed, 42 insertions, 2 deletions

diff --git a/source/slang/slang-emit-glsl.cpp b/source/slang/slang-emit-glsl.cpp
index 7b784de8d..fb4417119 100644
--- a/source/slang/slang-emit-glsl.cpp
+++ b/source/slang/slang-emit-glsl.cpp
@@ -95,6 +95,7 @@ void GLSLSourceEmitter::_requireGLSLVersion(int version)
         CASE(430);
         CASE(440);
         CASE(450);
+        CASE(460);
 
 #undef CASE
     }
@@ -1801,14 +1802,46 @@ void GLSLSourceEmitter::emitSimpleTypeImpl(IRType* type)
         {
             case kIROp_RaytracingAccelerationStructureType:
             {
-                _requireRayTracing();
-
+                // Note: We have the problem here that we want to do `_requireRayTracing()`,
+                // but just based on the use of a ray-tracing acceleration structure we
+                // cannot know which extension the user means to use. The current options are:
+                //
+                //  * GL_NV_ray_tracing
+                //  * GL_EXT_ray_tracing
+                //  * GL_EXT_ray_query
+                //
+                // The first two options there are basically equivalent extensions with
+                // different GLSL syntax. We end up requiring the user to opt in to
+                // `GL_NV_ray_tracing` using target capabilities, and will always default
+                // to `GL_EXT_ray_tracing` otherwise.
+                //
                 if( getTargetCaps().implies(CapabilityAtom::GL_NV_ray_tracing) )
                 {
+                    // If the user has explicitly opted in to `GL_NV_ray_tracing`,
+                    // then we don't need to explicitly request the extentsion again.
+                    // We know that the acceleration structure type will translate
+                    // to the one from that extension:
+                    //
                     m_writer->emit("accelerationStructureNV");
                 }
                 else
                 {
+                    // If the user does *not* opt into a specific extension, then we
+                    // have the problem that either `GL_EXT_ray_tracing` or `GL_EXT_ray-query`
+                    // could provide the `accelerationSturctureEXT` type, but there
+                    // can be drivers that provide only one and not the other.
+                    //
+                    // Because we can't pick one upon just seeing the type, we need to
+                    // emit the type here but *not* call `_requireRayTracing()` or
+                    // anything like it, because we don't yet know the specific extension
+                    // we should ask for.
+                    //
+                    // TODO: We might eventually want to have this step set a flag that
+                    // will cause a compilation error if nothing else in the code requires
+                    // a specific concrete ray-tracing extension. Ideally all of these
+                    // details could be subusmed under the capability system sooner or
+                    // later.
+                    // 
                     m_writer->emit("accelerationStructureEXT");
                 }
                 break;
@@ -1827,6 +1860,13 @@ void GLSLSourceEmitter::emitSimpleTypeImpl(IRType* type)
         return;
     }
 
+    auto decorated = getResolvedInstForDecorations(type);
+    if(auto targetIntrinsicDecor = findBestTargetIntrinsicDecoration(decorated))
+    {
+        m_writer->emit(targetIntrinsicDecor->getDefinition());
+        return;
+    }
+
     SLANG_DIAGNOSE_UNEXPECTED(getSink(), SourceLoc(), "unhandled type");
 }