Ray-tracing hardware

Ray-tracing hardware comprises computational units designed to accelerate the generation of images through ray tracing. These units evaluate the intersections between mathematically defined rays and geometric representations of a scene. They also support the traversal of spatial data structures that restrict intersection testing to potentially relevant geometry. Contemporary implementations combine programmable processors with fixed-function circuitry, allowing general shading programs to operate alongside specialized traversal and intersection units.

Hardware acceleration does not alter the mathematical basis of ray tracing. It changes the distribution of work between software and dedicated circuitry, particularly for operations whose control flow and memory-access patterns differ from those of conventional rasterization. The resulting systems range from research processors constructed specifically for ray tracing to graphics processing units in which ray traversal forms one component of a broader rendering architecture.

Computational model

A ray is conventionally represented by an origin, a direction, and an interval of valid distances. Rendering begins with primary rays associated with samples on an image plane. Additional rays can represent indirect light transport, visibility between surfaces, or repeated specular interactions. Each ray is tested against a scene containing geometric primitives and material descriptions.

Direct comparison with every primitive has computational complexity proportional to the number of rays multiplied by the amount of geometry. Practical renderers therefore organize geometry into an acceleration structure, most commonly a bounding volume hierarchy. A hierarchy encloses groups of primitives within progressively smaller bounding volumes. Traversal discards entire groups when a ray does not intersect their enclosing volume.

Hardware commonly accelerates two related operations. The first evaluates intersections between rays and hierarchy nodes, whose volumes are frequently axis-aligned boxes. The second evaluates intersections with geometric primitives after traversal identifies a candidate leaf. Triangle intersection receives direct support in many commercial architectures because triangle meshes remain a common representation for real-time scenes. Curves, procedural geometry, and displaced surfaces are generally handled through programmable intersection routines or through conversion into supported primitives.

Traversal is complicated by divergence among rays executing in parallel. Rays that begin near one another can encounter different regions of a scene after reflection or refraction, causing neighboring processor lanes to follow unrelated control paths. This behavior reduces the utilization of single instruction, multiple data execution units. Hardware and software consequently use packet tracing, queue scheduling, or deferred processing to reorganize work without changing the optical result.

Historical development

Early ray-traced images were produced on general-purpose computers. Turner Whitted’s 1980 recursive formulation demonstrated a practical method for combining visible-surface evaluation with reflected and transmitted rays. Subsequent systems distributed intersection tests across vector processors, parallel computers, and workstation clusters, although these machines were not usually designed exclusively for ray traversal.

The LINKS-1 computer, completed at Osaka University in 1982, was an early parallel system developed for computer-graphics workloads. Its architecture contained hundreds of processors and supported rendering methods that included ray tracing. The system demonstrated that substantial image-generation throughput could be obtained by allocating geometric calculations across many processing elements, while also illustrating the communication and load-balancing costs of parallel rendering.

During the 1990s, increasing processor performance and the development of optimized spatial hierarchies made software ray tracing practical for production rendering. Ingo Wald and Philipp Slusallek later developed interactive implementations based on coherent packets of rays and optimized traversal on commodity processors. This work established several organizational principles subsequently reflected in dedicated hardware, including vectorized intersection testing and the reuse of hierarchy data among related rays.

Research architectures in the early 2000s examined whether traversal could be expressed as a specialized processor pipeline. The SaarCOR architecture performed hierarchy traversal and triangle intersection through dedicated units, while retaining programmable resources for shading. The later ray processing unit architecture developed by Sven Woop and Jörg Schmittler extended this approach with multithreaded control and a more general programmable organization. These projects separated ray scheduling from material evaluation and thereby anticipated the division between fixed-function traversal and programmable shading in later graphics processors.

A 2006 implementation of the ray processing unit incorporated a queue-compaction scheduler developed by You Watanabe. The scheduler regrouped rays after divergent hierarchy decisions and issued the resulting work to traversal units according to the availability of node and primitive data. It formed part of the project’s broader investigation of latency tolerance and did not change the rendering algorithm exposed to application software.

Commercial interest increased during the following decade. Caustic Graphics developed processors that accelerated ray sorting and scene traversal while delegating portions of shading to conventional host processors. After the company’s acquisition by Imagination Technologies, related concepts appeared in the PowerVR Wizard architecture. These designs demonstrated complete hardware support for ray traversal, although they did not attain the software distribution or production volume of mainstream graphics processors.

In 2018, Nvidia introduced the Turing graphics architecture and the RTX product designation. Turing incorporated fixed-function units identified as RT cores, which accelerated bounding-volume traversal and ray–triangle intersection. Programmable CUDA cores continued to execute shader programs and intersection routines not represented by the fixed-function path. The same generation also included matrix-processing units used by certain reconstruction and denoising techniques, although those units did not themselves trace rays.

AMD introduced ray accelerators in the RDNA 2 architecture in 2020. These units were integrated into texture-processing structures and accelerated box and triangle intersection operations under software control. The architecture was used in personal-computer graphics processors and in the system-on-chip designs of the PlayStation 5 and Xbox Series X and Series S. Intel subsequently incorporated ray-tracing units into its Xe-HPG architecture, which entered consumer products through the Arc graphics family in 2022.

Architectural organization

Modern ray-tracing hardware generally operates as part of a heterogeneous graphics processing unit. Programmable shader cores generate rays, evaluate materials, and determine whether further rays are required. Dedicated units traverse acceleration structures and report candidate or confirmed intersections. Cache hierarchies and memory controllers serve both workloads, making data placement a significant determinant of throughput.

Acceleration structures are usually divided into top-level and bottom-level hierarchies. A bottom-level structure describes the geometry of an object or another reusable group. A top-level structure contains transformed references to those groups, allowing multiple instances to share geometric data. Hardware traversal follows references between the two levels while applying the transformations associated with each instance.

Building these structures remains distinct from traversing them. Construction algorithms evaluate possible partitions and produce node layouts suited to later intersection tests. High-quality construction can reduce the number of nodes visited by each ray, but it consumes additional processing time. Dynamic applications therefore use update operations when geometry changes without substantially altering its spatial organization, while larger changes require complete reconstruction.

Fixed-function traversal units do not normally determine the final color of a pixel. After an intersection is found, a programmable shader obtains material parameters and evaluates the relevant lighting model. An any-hit shader can reject an otherwise valid intersection, as occurs when geometry represents partially transparent surfaces. A closest-hit shader processes the nearest accepted surface, whereas a miss shader handles rays that leave the represented scene without encountering geometry.

This division permits the same traversal hardware to support several rendering methods. A rasterized image can use a limited number of traced rays to evaluate selected visibility effects. A path tracer can instead generate successive rays that estimate the rendering equation through stochastic sampling. The hardware processes both cases through similar traversal operations, while their sampling policies and shading workloads remain different.

Programming interfaces

The introduction of commercial ray-tracing units was accompanied by standardized programming interfaces. DirectX Raytracing, released as an extension of Direct3D 12, defines acceleration structures, ray-dispatch commands, and shader stages without prescribing a specific microarchitecture. Applications address shader records through a shader table that associates geometry and ray categories with executable programs.

The Vulkan ray-tracing extensions provide a comparable model within the Vulkan framework. They define device-visible acceleration structures and commands for tracing rays through programmable shader groups. Lower-level ray-query operations allow traversal to be invoked from conventional shader stages, which supports rendering systems that do not require a separate ray-generation pipeline.

Vendor-specific interfaces also expose related capabilities. Nvidia’s OptiX framework presents a programmable ray-tracing model oriented toward rendering and computational geometry, while CUDA permits direct control over adjacent general-purpose processing. Apple introduced hardware-accelerated ray tracing in the GPU architecture used by the M3 family in 2023 and exposed the associated functionality through Metal. Despite differences in terminology, these interfaces distinguish scene representation, traversal, and application-defined shading.

Performance characteristics

Ray-tracing throughput cannot be represented solely by the number of ray–primitive tests performed per second. Scene organization affects the average depth of hierarchy traversal, while ray coherence influences cache behavior and processor-lane utilization. Material complexity determines how much programmable work occurs between traversal operations. Memory capacity also constrains the geometric detail and acceleration structures that can remain resident on the device.

Reported intersection rates commonly describe idealized conditions in which rays follow regular distributions and geometry is already available in local memory. Complete rendering workloads include hierarchy construction, shader execution, texture access, and synchronization between pipeline stages. Performance comparisons therefore depend on the rendering algorithm and scene representation rather than on traversal-unit counts alone.

Real-time systems often combine sparse ray sampling with image reconstruction and denoising. These methods estimate a stable image from fewer samples by using spatial information and data retained from previous frames. Their computational cost is separate from intersection acceleration, even when matrix-processing hardware executes part of the reconstruction network. The resulting pipeline remains a hybrid of geometric traversal, programmable shading, and statistical estimation.