DXR Pipeline vs Inline Ray Queries in DirectX

DirectX Raytracing (DXR) offers two primary approaches to hardware-accelerated ray tracing: full Raytracing Pipeline State Objects (RTPSOs) introduced in DXR 1.0, and Inline Ray Queries introduced in DXR 1.1. While full DXR pipelines rely on a dedicated, event-driven execution framework featuring distinct shader stages for ray generation, intersection, and shading, inline ray queries allow developers to initiate and traverse rays directly within existing traditional shader stages such as compute, pixel, or vertex shaders. Choosing between them depends on material complexity, divergence, integration constraints, and performance requirements.

Architecture and Execution Model

Full DXR pipelines operate on an inverted control model. The application defines a specialized Raytracing Pipeline State Object (RTPSO) and dispatches work via DispatchRays. The execution flow transitions across distinct, specialized shaders:

  • Ray Generation Shader: The entry point where rays are spawned.
  • Intersection and Any-Hit Shaders: Evaluate geometry intersections and handle alpha testing.
  • Closest-Hit Shader: Executes when the closest surface is resolved, evaluating material shading or spawning secondary rays.
  • Miss Shader: Executes when a ray fails to intersect any geometry, commonly sampling environment maps.

Inline ray queries use an imperative, direct-execution model. Instead of delegating control to a specialized pipeline, a standard shader stage (such as a compute or pixel shader) instantiates a RayQuery object in HLSL. Traversal is handled explicitly using a loop within the same shader, advancing the query step-by-step until the intersection result is returned.

Shading and Material Complexity

The most significant functional difference lies in how heterogeneous materials are handled.

Full DXR pipelines use Shader Binding Tables (SBTs) to associate specific geometry instances with unique hit shaders. When a ray hits an object, the hardware dynamically looks up and invokes the exact hit shader assigned to that material. This makes full pipelines suitable for complex, primary ray workloads or indirect diffuse reflections where rays can strike dozens of visually and mechanically distinct materials across the scene.

Inline ray queries lack a dynamic shader dispatch mechanism. When a ray query finishes traversal, execution remains inside the calling shader. Any material evaluation must be handled manually within that single shader via branch logic or material identification buffers. Consequently, ray queries are poorly suited for complex multi-material shading but excel when the hit result requires simple processing.

Performance and Workload Suitability

Full DXR pipelines yield superior efficiency in divergent, high-complexity scenarios. Modern graphics architectures feature dedicated hardware schedulers and sorting mechanisms (such as Shader Execution Reordering) capable of grouping divergent rays and matching hit shaders to maximize SIMD occupancy. However, full pipelines incur substantial overhead from context switching, shader table lookups, and large ray payloads.

Inline ray queries carry minimal dispatch overhead and bypass Shader Binding Table management entirely. Payload data stays entirely within local shader registers rather than being pushed to specialized ray payload memory. This makes inline ray queries significantly faster for:

  • Shadow and Ambient Occlusion Rays: Binary visibility checks that only require determining whether an obstruction exists.
  • Screen-Space Ray Tracing Fallbacks: Augmenting screen-space reflections with short-range hardware ray tracing.
  • Compute-Based Spatial Filtering: Incorporating ray-traced visibility checks directly into existing post-processing or compute passes.

Engine Integration and Implementation Overhead

Full DXR pipelines impose high implementation complexity. Engines must construct acceleration structures, compile complex RTPSOs, allocate and populate Shader Binding Tables, and restructure the rendering loop around DispatchRays.

Inline ray queries offer a lightweight integration path. Because they function as an HLSL language extension available within standard rasterization or compute passes, developers can introduce ray tracing into an existing forward or deferred rendering pipeline without altering pass structures or building dedicated ray tracing execution graphs.