RT Core (Hardware accelerated ray tracing)

RT Core is a specialized unit in NVIDIA GPUs that performs hardware based calculation of ray intersections with scene geometry. Instead of millions of software instructions, the core accomplishes this task in a single pass, radically offloading streaming multiprocessors and making realistic lighting, shadows, and reflections computable in real time.

These units are used in rendering tasks with physically correct lighting: in architectural visualization, film production, and video games. They enable hybrid rendering, where rasterization is combined with ray tracing for reflections, ambient occlusion, and diffuse light. Beyond entertainment, the technology is in demand in professional simulations, including acoustic modeling and ray tracing in lidar for automotive driver assistance systems.

A typical problem is noise increase with an insufficient number of rays per pixel, which requires aggressive denoising and can blur details. There is also a video memory deficit: acceleration structures (BVH) for complex scenes occupy gigabytes, causing performance drops on graphics cards with limited VRAM capacity. Furthermore, framerate instability arises from incorrect management of recursive light reflection in dynamic scenes, where geometry is rebuilt every frame.

How RT Core works

The operating principle is based on traversing a Bounding Volume Hierarchy (BVH). The shader generates a ray intersection test request; the RT Core receives the BVH data and the ray, hardware tests its intersection against parent boxes, and then descends to triangles, returning the hit point. Unlike classic CUDA cores that perform math on vertices and pixels, or tensor cores optimized for matrix multiplication in deep learning operations, the RT Core implements a finite state machine for tree traversal in transistors. This is the key difference: tensor units accelerate convolutions and MLP layers (used in DLSS for upscaling and anti-aliasing), whereas the RT Core removes the fundamental bottleneck of branching and memory search, without wasting shader resources on recursive calculations. Thanks to parallel pipeline operation, while the RT Core is busy finding intersections, streaming multiprocessors are free to calculate materials, textures, and complex lighting at the ray hit point.

RT Core functionality

1. Hardware BVH tree traversal. The RT Core unit performs BVH traversal independent of the shaders. A specialized finite state machine in silicon iteratively tests ray intersections against nodes. This relieves streaming multiprocessors (SMs) from the load of navigating the acceleration structure, allowing SMs to perform other tasks.
2. Triangle intersection testing. The core contains fixed function units for precise ray triangle testing using the Moller Trumbore algorithm. The circuit computes barycentric coordinates and the t parameter in a single cycle. The hardware implementation minimizes floating point rounding errors, ensuring watertight geometry without self shadowing artifacts.
3. Barycentric coordinates processing. Upon detecting an intersection, the RT Core returns not only the distance t but also the barycentric coordinates u, v of the hit point. These values are automatically interpolated in the SM to obtain vertex attributes. The hardware unit transmits the instance identifier and primitive index without programmable stage involvement.
4. User defined hit data output. Through Ray Payload, the RT Core transfers an arbitrary developer defined data structure to shader registers. The mechanism eliminates global memory writes during the traversal stage. The data is immediately available in the closest hit or miss shader, accelerating recursive tracing.
5. Transparency to any hit shaders. When a ray intersects geometry, the core invokes the any hit shader before confirming the closest intersection. The RT Core guarantees deterministic processing order along the ray. The developer can reject the intersection programmatically, for example for alpha testing, and BVH traversal continues without restarting the ray.
6. Hardware intersection shader invocation. For procedural geometry (spheres, voxels), the RT Core launches intersection shaders. In this mode, the fixed function search transfers control to a programmable unit when the ray hits a user defined bounding volume. The SM computes the precise intersection, and the result is returned back to the traversal pipeline.
7. Multi ray scheduling. The hardware tracing scheduler groups several independent rays into packets to hide memory access latency. The RT Core dynamically switches between warps while waiting for BVH node fetches from cache. This internal work reordering radically increases compute unit and memory bandwidth utilization.
8. Ray count scaling in tracing. The fourth generation architecture includes a Shader Execution Reordering (SER) engine. The RT Core analyzes ray coherence on the fly and regroups threads executing the same material. The chip reduces execution divergence by aligning accesses to texture units and shader arrays, multiplying overall performance.
9. Specialized BVH caches. The core is equipped with dedicated L0 cache memory for traversal data (nodes and triangles). The physically close placement of the cache to the test units reduces power consumption for data transfer. The prefetch subsystem anticipates the next traversal steps and loads the node graph before the ray requests the data.
10. Hardware opaque and non opaque flag invocation. The instance mask in BVH allows the RT Core to discard entire geometry groups without shader calls. The hardware filter checks ray and geometry bit fields in a single cycle. The mechanism dramatically reduces the number of false any hit invocations, offloading the pipeline in scenes with complex shading.
11. Motion Blur support in BVH. The RT Core uses a spatio temporal hierarchy, interpolating triangle vertices between two temporal samples. The test unit calculates the position of the moving primitive at the ray’s time instant. The circuit eliminates the need for post processing motion vectors, generating a geometrically accurate blur trail.
12. Acceleration hierarchy compression. The hardware decompression unit operates on compressed BVH nodes packed by the driver. Reducing traffic volume to the memory subsystem allows storing more complex scene geometry in the cache. Decompression occurs transparently on the read path, consuming no additional traversal pipeline cycles.
13. Ray formation in mega geometry. The DMM (Displaced Micro Mesh) function is decoded directly in the RT Core. The hardware generates micro triangles on the fly from a low poly mesh cage and a displacement map. Memory stores only the base mesh, and the RT Core emulates the detailed surface, reducing BVH volume by an order of magnitude.
14. Dedicated traversal stack. Each ray consumes a fixed amount of SRAM inside the RT Core for the recursive descent stack. The hardware stack eliminates expensive emulation through shader local memory. Stack overflow is handled via a controlled spill mechanism to L1 cache, preserving traversal correctness.
15. SRAM (Fast volatile random storage of bits)
16. Parallel register execution. The RT Core contains several independent register banks for storing ray parameters (origin, direction, t interval). The hardware test unit reads these values simultaneously over a wide bus. Simultaneous packed data operations eliminate structural hazards in the pipeline.
17. Asynchronous tracing in compute. Beyond the graphics pipeline, the RT Core can be invoked directly from compute shaders via the NVAPI interface. The scheduler asynchronously mixes tracing jobs with general purpose computations. This scenario is used in non graphics tasks: physics basis, sound simulation, and path tracing in inference.
18. Ray tracing coherence. An internal coherence tracker analyzes the attributes of rays emitted by neighboring threads. Upon detecting co directional vectors and close origins, the RT Core activates a batch memory mode. The controller reorganizes DRAM requests for maximum GDDR interface utilization, avoiding random access and bank conflicts.
19. DRAM (Storage and Byte-addressing of Data)
20. OMM (Opacity Micromap) traversal. The hardware accelerator computes visibility through an opacity micromap associated with a triangle. The RT Core evaluates the alpha state of a sub pixel before invoking the expensive any hit shader. This radically eliminates idle calls when tracing foliage and particles, accelerating alpha testing at the geometric level.
21. Triangle ray engineering. For soft shadows and blurry reflections, the core supports ray beam approximation through unclipped projections. The RT Core varies test parameters depending on the ray spread, detecting partial triangle overlap. The hardware early exit heuristic culls geometry with negligible contribution to the integral.
22. Global illumination estimation (SHARC). In recent revisions, the RT Core contains a spherical harmonics approximation unit. After processing an intersection, the cache line is updated with indirect lighting coefficients without global memory exits. The second light bounce estimation is accelerated by an order of magnitude due to the fusion of filtering and calculation within the traversal pipeline.

Comparisons

• RT Core vs Shader Execution Reordering (SER). The RT Core hardware accelerates ray geometry intersection using fixed BVH traversal units. The SER function optimizes thread divergence during tracing by dynamically grouping rays with similar trajectories. Together, the RT Core solves the geometric problem, while SER reduces compute unit idle time, increasing overall secondary ray shading efficiency without altering the accelerator’s hardware pipeline.
• RT Core vs Ray Reconstruction (RR). While the RT Core is responsible for primary ray generation and tracing to obtain lighting samples, Ray Reconstruction is a neural network based post processing stage. The RR function replaces traditional denoisers, using neighboring pixel data and motion signals to reconstruct realistic lighting where the RT Core produced a sparse and noisy output.
• RT Core vs Opacity Micromap (OMM). The RT Core hardware unit computes ray intersections with triangles, including alpha textures, which often requires an expensive any hit shader call to check transparency. Opacity Micromap technology integrates into the RT Core pipeline, replacing the software shader with a hardware opacity map. This allows the accelerator to immediately cull transparent micro geometry areas without additional computations, radically reducing the tracing load for foliage and particles.
• RT Core vs CUDA Core in software tracing mode. The specialized RT Core performs BVH intersection search operations on physically dedicated silicon in just a few cycles. A CUDA Core, performing the same task via software instructions (compute shader), loads streaming multiprocessors with complex tree traversal loops. The difference is that the RT Core frees shader arithmetic resources for material execution and color calculations, providing a manifold performance increase compared to emulation.
• CUDA Core (Performing parallel floating point computations)
• RT Core vs Direct Storage API (RTX IO). The RT Core works during the rendering stage, accelerating the math of light propagation in the virtual scene. The Direct Storage function (RTX IO) enables fast loading of scene assets directly from NVMe storage to video memory through GPU decompression. The comparison highlights that the RT Core solves the lighting problem for already loaded geometry, while RTX IO eliminates the I/O bottleneck by rapidly feeding high resolution streaming data for that geometry.

OS and driver support

The operating system interacts with RT Core through the NVIDIA graphics driver paired with a graphics API (DirectX 12 Ultimate, Vulkan with VK_KHR_acceleration_structure and VK_KHR_ray_tracing_pipeline extensions). Windows OS (starting from version 10, build 1809) and modern Linux distributions recognize the hardware through WDDM 2.7+ or proprietary kernel modules, providing user mode components access to the hardware queue scheduler. The driver translates tracing calls into commands for BVH traversal and intersection units, managing video memory allocation for acceleration structures through the API interface, and the driver abstraction layers (via NvAPI and Vulkan layers) ensure backward compatibility and hardware level profiling.

Hardware isolation and security

Execution security on RT Core is ensured by hardware context separation: the tracing units have no direct access to CPU system memory and operate exclusively within the GPU memory manager’s video memory pool. The driver strictly validates tracing shaders at the IR code compilation stage (via DXIL/SPIR-V validators), preventing out of bounds access to BVH structures and intersections. In multi user and virtualized environments, SR-IOV with a GMMU hardware memory manager is used, isolating command queues and intersection buffers; for remote rendering, driver integrated traffic encryption per SRTP standard is employed, preventing interception and modification of geometry data in the channel between the guest OS and the physical device.

Logging

Tracing core operation logging is performed through hardware counters inside streaming multiprocessors (SM), exposed by the driver to NVIDIA PerfWorks system interfaces and the GPU Trace layer. The Nsight Graphics profiler captures contextual metadata about RT block L1 cache misses, BVH internal node traversal time, and any hit shader invocations, without disrupting the back buffer to front buffer synchronization pipeline. Through the D3D12 Debug Layer and Vulkan Validation Layers APIs, the driver writes error logs for scratch memory allocation for acceleration structures, invalid geometry indices, and traversal stack overflows to a user defined callback, enabling the developer to receive deterministic RT block state dumps without a significant FPS drop.

Limitations

The recursive BVH tree traversal depth is hardware limited by a fixed size stack inside the RT Core, which terminates rays whose consecutive bounce count exceeds the threshold (typically 31), with the further strategy determined by the TraceRay flag. The TraceRay parameter from a non inline shader strictly requires the ray payload not to exceed 32 bytes, otherwise the driver compiler signals a register file oversubscription error. The intersection unit cannot modify acceleration structures during traversal; any dynamic geometry change requires a full or incremental BVH rebuild via separate command lists, and static driver analysis prohibits the use of resources in Unordered Access View mode as both a modification target and a source for AS structures.

Evolution of RT Core generations

In the Turing generation (Volta successor architecture, 2018), the RT Core performed only ray triangle intersection and BVH traversal, offloading hit processing to streaming multiprocessors. In Ampere (2020), hardware attribute interpolation for motion blur was introduced, and the unit received doubled triangle intersection throughput via pipelining. Ada Lovelace (2022) added an OMM (Opacity Micromap Engine) block for hardware alpha channel culling in BVH traversal and increased the ray reuse cache capacity; the driver can now reorder tracing threads via hardware (Shader Execution Reordering). The Blackwell generation (2024) includes a sphere linear unwrapping pipeline, a specialized Intersection Engine block for spheres and implicit surfaces, and the driver provides interfaces for compact BVH structures and parallel traversal of multiple independent acceleration structures in a single TraceRay call.