Hardware Ray Tracing vs Software GLSL BVH Traversal

This article examines the core differences between native hardware ray tracing pipelines and software-based Bounding Volume Hierarchy (BVH) traversal implemented in GLSL. While both techniques calculate light transport by intersecting rays with 3D geometry, they diverge fundamentally in their execution model, memory utilization, hardware requirements, and overall performance. Understanding these distinctions clarifies why dedicated ray tracing architectures vastly outperform compute-based software traversal, and when a software approach remains viable.

Execution Model and Silicon Architecture

Hardware ray tracing relies on dedicated fixed-function units integrated directly into modern GPUs, such as NVIDIA RT Cores or AMD Ray Accelerators. When an application initiates a ray query via modern graphics APIs (such as Vulkan Ray Tracing or DirectX Raytracing), these dedicated units handle ray-box and ray-triangle intersection tests independently of the primary execution cores. This offloads compute units, allowing arithmetic logic units (ALUs) to continue running shading or compute tasks in parallel.

In contrast, software BVH traversal in GLSL relies entirely on general-purpose compute or fragment shaders. The GPU's standard ALUs must execute every instruction required for the traversal algorithm, including node parsing, coordinate transformations, and mathematical intersection tests. Because the work is executed on general-purpose stream processors, it competes directly with other rendering workloads for computational resources.

Divergence and Stack Management

Ray traversal is an inherently divergent workload; neighboring rays frequently hit completely different objects or traverse different depths of the scene hierarchy.

• Hardware Pipelines: Modern ray tracing hardware incorporates specialized scheduling logic to mitigate thread divergence. Traversal hardware can dynamically reorder and regroup coherent rays across warps or wavefronts, significantly improving execution efficiency and cache locality. Hardware pipelines also manage the traversal stack automatically in dedicated, low-latency memory.
• Software GLSL: Standard GLSL shaders have no native support for ray reordering or hardware traversal stacks. Developers must implement traversal using either a stackless algorithm (such as rope trees or packet tracing) or maintain a manual stack in local register memory or shared memory. Because GPUs execute in SIMD/SIMT lockstep, when rays within the same workgroup diverge down different paths of the BVH, execution stalls occur as threads wait for the longest path to finish.

BVH Construction and Memory Representation

The creation and storage of the acceleration structure differ significantly in complexity and optimization:

• Hardware Acceleration Structures: In hardware pipelines, the API partitions the BVH into a two-level hierarchy: Bottom-Level Acceleration Structures (BLAS) for geometry and Top-Level Acceleration Structures (TLAS) for scene instances. The driver and hardware build and optimize these structures internally using proprietary, hardware-tailored layouts that maximize cache line utilization.
• Software BVH in GLSL: In a software implementation, the developer must design the data structure, construct the BVH on the CPU (or via custom compute shaders), flatten it into a 1D format, and upload it via Shader Storage Buffer Objects (SSBOs) or texture buffers. Accessing these structures requires manual memory fetches in GLSL, introducing significant memory latency without the benefit of dedicated ray-tracing cache hierarchies.

Compatibility, Flexibility, and Use Cases

• Compatibility: Software BVH traversal in GLSL can run on virtually any platform that supports modern OpenGL, WebGL 2.0, or compute shaders, making it independent of dedicated hardware. Hardware pipelines strictly require modern, RT-capable GPUs and APIs that expose ray tracing extensions.
• Flexibility: Software traversal grants complete control over the traversal algorithm, custom intersection logic, and memory packing, which is useful for specialized mathematical primitives, custom volume rendering, or academic experimentation. However, for complex scenes with high polygon counts and real-time frame rate demands, hardware-accelerated ray tracing remains several orders of magnitude faster due to fixed-function silicon and dedicated memory paths.