Inline Ray Query vs Ray Tracing Pipeline in GLSL

Inline ray queries and full ray tracing pipeline dispatches represent two distinct paradigms for hardware-accelerated ray tracing in GLSL and Vulkan. Inline ray query (GL_EXT_ray_query) allows developers to cast rays synchronously from within existing programmable stages, such as compute or fragment shaders, using imperative traversal loops. In contrast, the full ray tracing pipeline (GL_EXT_ray_tracing) introduces an entirely separate execution model composed of specialized stages—ray generation, closest-hit, any-hit, intersection, and miss shaders—driven by a Shader Binding Table (SBT). This article outlines the architectural, performance, and implementation differences between these two execution strategies.

Execution Model and Pipeline Architecture

The full ray tracing pipeline requires dispatching work through a specialized command (such as vkCmdTraceRaysKHR). The execution flows through distinct stages: a ray generation shader initiates rays via traceRayEXT(), the hardware traversal engine intersects rays with acceleration structures, and control branches dynamically to any-hit, closest-hit, or miss shaders based on hit results.

Inline ray queries eliminate this dedicated pipeline structure. A ray query is executed as an intrinsic object directly within an existing shader stage (vertex, fragment, compute, or mesh). Using functions like rayQueryInitializeEXT() and rayQueryProceedEXT(), the shader acts as the driver of the ray traversal, stepping through intersections sequentially in a standard execution thread without invoking secondary shaders.

Control Flow and Shading Dispatch

In the full pipeline dispatch, material shading is handled polymorphically. When an intersection occurs, the hardware automatically resolves the Shader Binding Table to invoke the precise closest-hit shader associated with the intersected geometry. This enables clean separation of material logic, complex recursive ray casting, and scalable scene rendering involving thousands of distinct materials.

Ray queries provide no automatic shader dispatching. The calling shader retains total control throughout traversal. If an intersection is confirmed via rayQueryGetIntersectionTypeEXT(), the caller must manually handle the resulting shading logic, often via branch statements or data lookups based on instance and primitive IDs. Consequently, ray queries are typically restricted to binary tests (e.g., visibility or shadow testing) or simple materials to avoid massive shader branching.

Memory Overhead and Register Pressure

The full ray tracing pipeline relies on ray payloads and hit attributes to pass data across shader stages. The driver manages execution states, call stacks, and thread scheduling across multiple shader invocations, which can lead to spill-to-memory overhead if ray payloads or recursion depths are large.

Inline ray queries keep ray state local to the calling shader invocation. While this eliminates call-stack overhead and context switching, it stores the traversal state directly in the calling thread's register file or local scratch memory. This substantially increases register pressure in complex shaders, potentially reducing overall thread occupancy (wavefront/warp occupancy) on the GPU.

Divergence and Scheduling

Full ray tracing pipelines allow modern GPU architectures to reorder and re-pack threads dynamically to mitigate divergence caused by complex ray paths and varying material evaluations. When divergent rays hit different surfaces, modern hardware schedulers can group similar hits to maximize SIMD efficiency.

Ray queries do not benefit from this dynamic thread regrouping. Because traversal is executed in-line inside standard SIMD warps, rays that complete traversal early must idle while neighboring divergent rays in the same warp continue their traversal loops. This makes ray queries prone to SIMD underutilization when tracing divergent, incoherent paths, such as diffuse global illumination.

Typical Use Cases

• Inline Ray Query (GL_EXT_ray_query): Best suited for localized, coherent visibility queries integrated into existing rasterization or compute passes. Common implementations include screen-space shadow verification, ambient occlusion, directional light shadows, and physics or AI line-of-sight tests.
• Ray Tracing Pipeline (GL_EXT_ray_tracing): Best suited for complex path tracing, primary ray generation, recursive reflections, and scenes with extensive material diversity that benefit from modular hit shaders and specialized hardware thread scheduling.