TTP: A Hardware-Efficient Design for Precise Prefetching in Ray Tracing
Abstract: Ray tracing (RT) is a 3D graphics technique that offers highly realistic visuals. It is becoming prominent and accessible as GPU vendors have integrated dedicated ray tracing acceleration hardware. However, tracing millions of rays through 3D scenes consisting of high numbers of triangles in real time is challenging and requires expensive hardware. The main bottleneck in RT workloads is the expensive Bounding Volume Hierarchy (BVH) traversal task, which is a large tree structure that encodes the 3D scene. BVH traversal is a memory-bound problem, as the GPU threads spend most of their time reading tree node data from memory. In this work, we attack the memory latency bottleneck of ray tracing through prefetching. We propose a novel hardware prefetcher, named Tree Traversal Prefetcher (TTP), for ray tracing. The main idea is to leverage the existing tree traversal stack in the RT units for highly accurate prefetching. In particular, TTP prefetches nodes using the addresses already available on the hardware traversal stacks of each thread. For DFS (Depth-first search) based traversal, prefetches are generated when nodes are being popped consecutively from the traversal stack, potentially corresponding to upward traversal through the tree. We evaluate TTP on a cycle-level simulator, Vulkan-sim 2.0, and show that it achieves 1.48x speedup on average (up to 1.89x) compared to the baseline, with nearly negligible hardware overhead. TTP achieves 98.92% average L1 accuracy, which is the ratio of the prefetched blocks being actually referenced by demand loads. The coverage, computed as the ratio of L1 miss reduction over baseline L1 misses, is 31.54%, correlating well with the achieved speedup.
Paper Prompts
Sign up for free to create and run prompts on this paper using GPT-5.
Top Community Prompts
Explain it Like I'm 14
Overview: What this paper is about
This paper is about making ray tracing (a way to create very realistic 3D graphics) run faster on graphics cards (GPUs). The authors focus on a big slow-down in ray tracing: waiting for data to come from memory. They introduce a tiny piece of hardware logic called the Tree Traversal Prefetcher (TTP) that guesses what data will be needed next and fetches it early, so the GPU spends less time waiting.
The main questions the paper asks
- Ray tracing often stalls because it must read lots of tiny pieces of a huge tree-like structure from memory. Can we hide that waiting time?
- Can we use information the GPU already has during tree traversal to prefetch the right data at the right time, without guessing wildly or wasting bandwidth?
- Will such a design be accurate, cheap to build in hardware, and actually make ray tracing meaningfully faster?
How the method works (with simple analogies)
First, a few quick explanations:
- Ray tracing: Imagine shooting millions of “light rays” from a camera into a 3D world to see what they hit. That’s how you get realistic shadows, reflections, and lighting.
- BVH (Bounding Volume Hierarchy): Think of the 3D scene as a huge family tree made of boxes inside boxes. Each small box points to triangles that make up objects. Rays check boxes first to skip large parts of the scene quickly.
- Cache: A small “desk drawer” of fast memory near the processor. If your data is in the drawer, access is fast. If not, you must walk to the “library” (main memory), which is slow.
- Prefetching: Like a helpful librarian who brings you the books you’re likely to ask for next, before you ask, so you don’t have to wait.
How BVH traversal works:
- The GPU walks the box-tree to find what a ray hits. It usually uses DFS (depth-first search), which is like following one branch down until you can’t go further, then going back up and trying another branch.
- DFS uses a stack, which is like a stack of plates: you add to the top (push) and take from the top (pop).
- BFS (breadth-first search) is another option using a queue (a line at a store): you process boxes level by level.
The TTP idea:
- Key insight: During DFS, when the traversal starts “going back up” (lots of pops in a row), the addresses of the next boxes you’ll check are already sitting right there in the stack.
- TTP watches the stack for “pop streaks.” When it sees 1 pop, it prefetches the next box on the stack; after 2 pops, it prefetches the next two; after 3 pops, it can prefetch more (up to a limit). This keeps the cache filled with the exact boxes the ray will soon need, without guessing new addresses.
- For BFS, it’s even simpler: the queue already knows the next items in order. TTP just prefetches the next few items in line.
Why this is hardware-efficient:
- TTP uses what’s already there: the traversal stack/queue and addresses.
- It adds a tiny 2-bit “state machine” per thread to decide how many items to prefetch and a small pointer—not big or expensive changes.
How they tested it:
- They used a detailed GPU simulator (Vulkan-sim 2.0) and many real 3D scenes of different sizes and complexity.
- They measured speed (how many cycles it takes), how accurate the prefetches were, how much bandwidth they used, and energy/power.
- They also compared TTP to a previous ray tracing prefetcher called Treelet.
What they found and why it matters
Key results show TTP is both fast and accurate:
- Speed: About 1.48× faster on average (up to 1.89×) compared to no prefetcher. That’s like finishing a task in roughly two-thirds of the time.
- Accuracy: About 98.9% of the prefetched data at the L1 cache was actually used. In other words, almost no wasted prefetches.
- Coverage: Around 31.5% of the slow memory misses were prevented by prefetching, which lines up with the speedups they saw.
- Energy: Despite going faster, total energy went down by about 9% (0.91×), because the GPU finished sooner.
- Bandwidth: Average memory bandwidth rose by ~18%, but the total amount of data moved didn’t really change—work was just done more quickly.
- Robustness: TTP kept working well with bigger caches, larger GPUs, and higher resolutions.
- BFS mode: When used with BFS, prefetching also helped a lot; prefetching the next 4 items in line gave about a 2.20× speedup over BFS without TTP.
- Versus prior work: TTP outperformed the Treelet prefetcher and didn’t require special changes to how the BVH is built or traversed.
Why it matters:
- The main bottleneck in ray tracing here is latency (waiting) rather than bandwidth (capacity). TTP directly attacks latency by “getting the boxes ready” before the ray asks for them.
- Because TTP is tiny and accurate, it avoids filling the cache with junk and doesn’t require complicated reorganizations of the scene data.
What this could mean in the future
- Faster real-time ray tracing: Games, VR, and interactive 3D apps could render more complex scenes smoothly without huge hardware costs.
- Better graphics on the same hardware: Studios and engines might push higher quality lighting and effects with fewer slowdowns.
- Flexible across algorithms: TTP helps both DFS and BFS, giving GPU designers and engine developers options to pick what works best per workload.
- Low risk to adopt: Since the hardware changes are small and the benefits are consistent, GPU vendors could integrate TTP-like logic into future chips.
- Beyond graphics: Ray tracing hardware is being explored for other fields (like physics or scientific simulations). Reducing memory wait time can speed those up too.
In short, this paper shows a smart, simple way to use information already inside the ray tracing hardware to get the right data early. That reduces waiting, boosts speed, and saves energy—all with minimal extra hardware.
Knowledge Gaps
Knowledge Gaps, Limitations, and Open Questions
Below is a concise list of what remains missing, uncertain, or unexplored in the paper, formulated to guide actionable future research:
- Real-hardware validation is absent: results rely on Vulkan-sim 2.0; no silicon/prototype measurements to verify feasibility, area, timing, or unintended RTL/physical-design constraints when tapping per-thread traversal stacks.
- Incomplete power/area quantification: power is from GPUWattch (not calibrated for RT units); no gate count, area, or timing analysis for the per-thread FSM, additional pointers, or added datapaths; DRAM energy impact is not reported.
- Cache/MSHR realism and sensitivity: the baseline uses a fully associative 32 KB L1 with 256 MSHRs and a 512 KB L2 with 768 MSHRs—much larger/less realistic than many GPUs; there is no sensitivity to line/sector size, associativity, replacement policy, MSHR counts, or NoC arbitration—all of which can strongly affect prefetch timeliness and pollution.
- Prefetch timeliness analysis is missing: no measurements of lead time distributions, late/early prefetch rates, or queueing delays; no tuning of per-thread prefetch distance based on observed latency, bandwidth slack, or stack depth.
- Bandwidth headroom assumption is untested under bandwidth-bound conditions: TTP adds ~18% average DRAM bandwidth; the paper focuses on underutilized scenes—there is no evaluation under bandwidth-saturated regimes (e.g., higher resolutions, more samples per pixel, more bounces, or concurrent graphics/compute workloads).
- Limited workload coverage: evaluation emphasizes closest-hit/path tracing; behavior and benefits for any-hit rays (e.g., shadows, AO), hybrid raster+RT pipelines, or mixed workloads (e.g., denoising, post-processing) remain uncharacterized.
- Resolution and ray-count scalability are not established: most results at 128×128 and a subset at 256×256; no evidence for 1080p/4K, higher samples-per-pixel, or deeper bounce counts common in production path tracing.
- BFS vs. DFS selection policy is not provided: while TTP supports both traversal strategies, there is no algorithm to select or switch (per ray, per wavefront, per scene, or dynamically) based on runtime signals (e.g., cache pressure, pop-streak statistics, BVH depth).
- BFS absolute performance trade-offs are unclear: BFS/TTP speedups are reported relative to BFS, but not compared to DFS baselines end-to-end; scenarios where BFS+TTP can outperform DFS+TTP (or vice versa) are not identified.
- Downward/sibling prefetching remains unexplored: the design avoids downward prefetching due to speculation risk, yet safe variants (e.g., immediately prefetching confirmed children/siblings post-intersection, multi-level lookahead when occlusion culling is known) are not studied.
- Duplicate prefetch suppression across threads/warps/SMs is not addressed: the design is per-thread; no cross-thread/warp deduplication, global filtering, or L2-side prefetch coalescing to reduce redundant traffic.
- Prefetch destination policy is fixed: only L1 is targeted; benefits/risks of prefetching to L2, selective L1 bypass, or dynamic destination selection based on stack depth/hit distance are not evaluated.
- Arbitration and QoS are simplistic: only fixed-cycle priority tweaks were tested; there is no adaptive policy that considers outstanding MSHRs, NoC/DRAM queue occupancy, or interference with demand traffic across SMs.
- Interaction with GPU schedulers is underexplored: prefetches are issued only when a warp is scheduled; the paper does not examine proactive/background issuance, interplay with warp selection, or potential starvation effects.
- Impact on other kernels and multi-tenant scenarios is unknown: TTP’s effect on co-running graphics/compute kernels, fairness, and QoS (especially under NoC/DRAM contention) is not studied.
- BVH dependence is not characterized: the approach assumes a particular BVH layout (6-ary, node size assumptions, sectorized fetch); there is no sensitivity to BVH construction variants (SAH, spatial splits, wide vs. binary BVHs), node ordering/layout, compression, or hardware-specific node formats.
- Dynamic/refitted BVHs are not considered: correctness and performance of TTP with per-frame BVH refits or dynamic scenes (moving geometry) and the coherence/invalidations of prefetched nodes remain open.
- Vendor RT unit compatibility is unclear: the design presumes direct access to per-thread traversal stacks; some implementations may compress/virtualize stacks or store them off-core, affecting availability/timing of addresses.
- Prefetch pressure on MSHRs and cache pollution risks need deeper study: although accuracy is high, the measured coverage (~31.5% L1) leaves many misses; the impact of prefetches on MSHR occupancy, demand blocking, and eviction of valuable data (including non-RT traffic) is not thoroughly quantified.
- Evaluation gaps and comparison fairness: one scene (park) is downscaled; Treelet prefetcher crashes on chsnt; there is no investigation into stabilizing Treelet or ensuring apples-to-apples comparisons (e.g., tree build options, tuning).
- No exploration of adaptive aggressiveness: prefetch intensity is fixed per state; there is no runtime adaptation based on observed accuracy/coverage, bandwidth slack, or pop-streak statistics to avoid over-/under-prefetching.
- Lead-time vs. stack-depth modeling is absent: the paper does not analyze how far down the stack one should prefetch as a function of DRAM/L2 latency, interconnect delay, and expected compute overlap.
- Node-size and partial-fetch inefficiencies are not examined: sectorized 32 B fetching may under/over-fetch node payloads; benefits of node-size-aware prefetch granularity or selective field prefetching (e.g., AABBs only) are unexplored.
- Effects on divergence and load balance are unknown: accelerating some rays’ memory may alter warp divergence/idle time and scheduling balance; no analysis of secondary effects on overall SM utilization.
- Security and side-channel considerations are unaddressed: whether exposing traversal-stack-driven prefetches could leak scene structure or ray paths is not discussed (relevant for multi-tenant/cloud settings).
- Path to increasing coverage is unclear: with coverage ~31–33%, there is room to capture more misses; combining TTP with complementary predictors (e.g., sibling/child, graph-based, or temporal/spatial ray reordering) is not investigated.
Practical Applications
Overview
The paper proposes TTP, a minimal-overhead hardware prefetcher integrated into GPU ray-tracing (RT) units that exploits per-thread traversal stacks/queues to prefetch BVH nodes with very high accuracy. By issuing prefetches when consecutive pops indicate upward traversal in DFS (or directly from queue head in BFS), TTP reduces latency bottlenecks in BVH traversal, delivering on average 1.48x speedup (up to 1.89x), ~9% energy savings, and ~99% L1 prefetch accuracy on a cycle-level simulator. It requires only minor on-RT-unit hardware changes and supports both DFS and BFS traversal (creating new opportunities to choose traversal per workload). Bandwidth overhead is modest (~18%) and largely attributable to shorter runtimes rather than added DRAM traffic.
Below are concrete applications of these findings for industry, academia, policy, and daily life.
Immediate Applications
These can be pursued now using existing tools, software paths, and organizational processes, or by leveraging the open-source simulator and applying the TTP idea in software-based traversal.
- Hardware evaluation and IP incubation in GPU/SoC roadmaps
- Sectors: Semiconductors, consumer GPUs, mobile SoCs, data-center accelerators
- What to build: Integrate per-thread 2-bit FSM and stack-pointer logic in RT units; reproduce results with Vulkan-sim 2.0 (open-source) and internal RTL/micro-architectural models; create a TTP-enabled RT-core IP variant for next-gen products.
- Assumptions/Dependencies: Hardware redesign cycle and validation; available headroom in memory subsystem (paper shows ~18% bandwidth overhead); RT units expose per-thread traversal stacks/queues internally.
- Software-mimicked TTP for compute/path tracers (no dedicated RT cores)
- Sectors: Software, gaming, VFX, robotics simulation, medical visualization
- What to build: Add software prefetch hints using the traversal stack/queue in CPU/GPU compute ray tracers (e.g., Embree, OptiX-like compute paths, custom CUDA/Metal/Vulkan compute kernels); issue prefetches on pop streaks (DFS) or from queue head (BFS) using platform intrinsics (e.g., __builtin_prefetch on CPU, LDG prefetch hints on GPU).
- Assumptions/Dependencies: Access to low-level prefetch intrinsics; BVH traversal implemented in software (not opaque RT units); workloads predominantly latency-bound rather than bandwidth-bound.
- Scene and traversal profiling to pick DFS vs. BFS per shader/ray type
- Sectors: Game engines (Unreal, Unity), DCC tools, CAD/CAE visualization
- What to build: Offline/online profilers that collect “pop streak” statistics and BFS prefetchability (as in paper’s Figures 9 and 10) to select traversal mode (DFS vs BFS) per scene or ray type (primary/secondary/shadow); integration into engine-level pipeline tuning and BVH build settings.
- Assumptions/Dependencies: Traversal-mode configurability in software path tracers; current commercial RT units may not expose BFS traversal selection—applicable immediately to software-based traversal and simulators.
- Curriculum, labs, and research using open-source Vulkan-sim 2.0
- Sectors: Academia (computer architecture, graphics), training
- What to build: Course labs demonstrating latency-bound traversal, prefetch accuracy/coverage vs. speedup, arbitration strategies, and cache/MSHR effects; research projects extending TTP to other spatial structures.
- Assumptions/Dependencies: Familiarity with Vulkan-sim; compute resources for simulation.
- Robotics and AV simulation accelerated in software paths
- Sectors: Robotics, automotive (sensor simulation, digital twins)
- What to build: In simulators that ray trace via compute (camera/ LiDAR/radar simulation), add stack/queue-aware software prefetch as above; expect faster sensor simulation or lower-power runs on embedded GPUs/CPUs.
- Assumptions/Dependencies: Compute-based traversal; availability of prefetch hints; BVH/octree traversal with observable pop streaks.
- Medical imaging and scientific visualization (software ray casting)
- Sectors: Healthcare, scientific computing
- What to build: Integrate software prefetch on consecutive pops for volume ray casting/isosurface extraction in CPU/GPU compute renderers to improve interactivity in surgical planning and research visualization.
- Assumptions/Dependencies: Software control over traversal; datasets large enough to be latency-bound; prefetch intrinsics available.
- Procurement and benchmarking guidance for latency-bound ray tracing
- Sectors: Cloud/HPC providers, enterprise IT
- What to build: Incorporate latency-bound RT metrics (cache MPKI, pop-streak composition, bandwidth headroom) into evaluation frameworks; prioritize hardware (present or upcoming) that demonstrates high prefetch accuracy/coverage on BVH workloads.
- Assumptions/Dependencies: Access to profiling tools and representative RT workloads; vendor cooperation for micro-architectural counters.
Long-Term Applications
These depend on hardware adoption of TTP-like mechanisms, API/driver support to surface traversal choices, or broader generalization beyond graphics.
- TTP-enabled consumer GPUs for real-time path tracing
- Sectors: Gaming, consumer graphics, XR
- What to build: Next-gen GPUs with TTP to raise ray-traced frame rates or quality (more bounces, higher resolutions) at similar power; VR/AR with lower latency for path-traced lighting.
- Assumptions/Dependencies: Hardware integration in RT cores; drivers/engines tuned to exploit DFS/BFS choices; adequate bandwidth headroom.
- Mobile SoC RT units with improved battery life for AR
- Sectors: Mobile, wearables, AR navigation
- What to build: TTP-integrated RT blocks in mobile GPUs (e.g., Immortalis-class, Apple/Qualcomm), enabling ray-traced effects in AR with better energy efficiency.
- Assumptions/Dependencies: Tight power/thermal budgets; careful bandwidth management; compatibility with mobile cache hierarchies and MSHR capacities.
- Cloud rendering and cloud gaming cost/perf improvements
- Sectors: Cloud, streaming, DaaS
- What to build: TTP GPUs in render farms to lower cost per rendered frame and datacenter energy (paper reports ~9% energy reduction for the RT phase); autoscaling policies that account for higher per-GPU throughput.
- Assumptions/Dependencies: Hardware availability; scheduling adapted to slightly increased instantaneous bandwidth use.
- Film/VFX and DCC render pipelines
- Sectors: Media/entertainment, digital content creation
- What to build: Adoption of TTP GPUs in GPU-accelerated path tracing renderers to shorten render times, expand iterative look-dev, and reduce energy costs at scale.
- Assumptions/Dependencies: Renderer paths using hardware RT units; integration and validation at high sample counts and complex scenes.
- CAD/CAE, AEC, and industrial digital twins
- Sectors: Manufacturing, architecture/engineering/construction, energy
- What to build: Real-time, path-traced design review and simulation on TTP GPUs; remote/edge visualization workflows with higher fidelity under power constraints.
- Assumptions/Dependencies: BVH-heavy scenes remain latency-bound; networked/edge deployments can handle modest bandwidth headroom locally.
- Physics engines and collision detection accelerated by TTP-like ideas
- Sectors: Robotics, gaming, simulation platforms
- What to build: Generalize stack/queue-tapping prefetch to other spatial trees (e.g., k-d trees, octrees, bounding volume hierarchies in collision detection) embedded in hardware or via ISA-level prefetch hints.
- Assumptions/Dependencies: Similar traversal dynamics (consecutive pops/upward trends) exist; hardware or ISA exposes prefetch hooks; careful cache pollution control.
- API/driver extensions to surface traversal control and counters
- Sectors: Software, standards (Vulkan, DirectX)
- What to build: API/driver options to select DFS/BFS per ray type or per dispatch, and expose relevant counters (pop-streak histograms, prefetch usefulness) to guide runtime decisions.
- Assumptions/Dependencies: Standardization effort; consensus on safety/portability; backward compatibility.
- Runtime systems that auto-select traversal mode and prefetch policy
- Sectors: Engines, middleware
- What to build: ML- or rule-based controllers that analyze scene/ray statistics and switch traversal strategies and prefetch aggressiveness (distance N in BFS; state-machine parameters in DFS) at runtime.
- Assumptions/Dependencies: Low overhead telemetry; stable correlations between coverage and speedup as shown in the paper; predictable scene dynamics.
- Cross-domain accelerators for irregular memory workloads
- Sectors: Databases, GIS, HPC (radiative transfer, neutron transport)
- What to build: Apply the “use the traversal stack/queue as ground truth” prefetch design to hardware units that traverse R-trees/B-trees/spatial indices or ray-based scientific methods; co-design cache hierarchies with MSHR capacity tailored to prefetch effectiveness.
- Assumptions/Dependencies: Availability of on-accelerator stacks/queues; workloads are latency-bound; careful arbitration to avoid starving demand misses.
- Sustainability and policy initiatives around energy-efficient rendering
- Sectors: Policy, public-sector IT, green computing
- What to build: Procurement criteria and energy labels that recognize RT hardware with proven latency-hiding and energy-saving features (like TTP); incentives for efficient interactive visualization in public services (urban planning, cultural heritage).
- Assumptions/Dependencies: Independent verification frameworks; agreement on representative workloads and metrics (accuracy, coverage, MPKI, energy/frame).
Key Assumptions and Dependencies (common across applications)
- Workloads are primarily memory-latency-bound during BVH traversal with bandwidth headroom (as measured in the paper); scenes exhibit meaningful consecutive-pop behavior.
- RT units (or software paths) maintain per-thread traversal stacks/queues and expose timing/address visibility sufficient for prefetch.
- Cache/MSHR resources are adequate to absorb additional prefetches without harming demand traffic; arbitration remains balanced.
- For hardware adoption, changes are inside RT units with minimal area/power overhead; drivers/engines may need traversal-mode controls to fully exploit TTP’s DFS/BFS support.
- Generalization beyond BVHs (e.g., octrees, R-/k-d trees) assumes similar traversal dynamics and that prefetch can be accurately timed to avoid cache pollution.
Glossary
- Ambient occlusion: A shading technique that approximates how much ambient light reaches a surface based on occlusion by nearby geometry. "Ambient occlusion shaders estimate the amount of ambient light that reaches objects by tracing rays in random directions from the objects and calculating the degree of occlusion."
- Any-hit shader: A programmable stage that can be invoked for every potential intersection and can terminate upon finding any hit. "any-hit rays terminate their search upon finding any primitive that the ray intersects."
- Axis-Aligned Bounding Box (AABB): A box aligned with coordinate axes used to spatially bound geometry for acceleration structures. "Bounding Volume Hierarchy (BVH) is employed, which consists of Axis-Aligned Bounding Boxes(AABB) that hierarchically capture scene primitives"
- Bounding Volume Hierarchy (BVH): A tree of bounding volumes organizing scene geometry to accelerate ray intersection tests. "The main bottleneck in RT workloads is the expensive Bounding Volume Hierarchy (BVH) traversal task, which is a large tree structure that encodes the 3D scene."
- Breadth-first search (BFS): A graph/tree traversal strategy that explores all nodes at a given depth before descending further. "Breadth-first search (BFS) is also a viable option."
- Cache hierarchy: The multi-level on-chip cache system used to reduce memory access latency. "thereby stressing the on-chip cache hierarchy."
- CISC-like instruction: A complex instruction that encapsulates a high-level operation into a single instruction. "BVH traversal is carried out within the RT unit by a single CISC-like instruction, i.e., the trace_ray instruction."
- Closest-hit shader: A programmable stage executed after traversal when the nearest intersection is found. "at the end of the traversal, if the ray hits an object, the closest-hit shader is called."
- Coalesced memory requests: Combining multiple memory accesses into a single request to reduce traffic. "Duplicate requests within the same warp are coalesced into one request"
- Coverage (prefetching): The fraction of baseline misses eliminated by useful prefetches. "The coverage, computed as the ratio of L1 miss reduction over baseline L1 misses, is 31.54%"
- Cycle-level simulator: A detailed simulator modeling system behavior at the granularity of clock cycles. "We evaluate TTP on a cycle-level simulator, Vulkan-sim 2.0"
- Depth-first search (DFS): A traversal strategy that explores as far as possible along branches before backtracking. "For DFS (Depth-first search) based traversal, prefetches are generated when nodes are being popped consecutively from the traversal stack"
- DRAM bandwidth utilization: The extent to which available main-memory bandwidth is used. "Average DRAM bandwidth utilization."
- Fixed-function hardware: Dedicated hardware units that implement specific operations efficiently. "As intersection tests and coordinate transformations are carried out in fast, fixed-function hardware, memory bottleneck is exposed as the primary challenge."
- Geometric mean: A multiplicative average often used to summarize normalized performance across workloads. "Our simulation results show that TTP achieves up to 1.89x performance improvement with a geometric mean of 1.48x."
- Global History Buffer (GHB) prefetcher: A hardware prefetcher that tracks recent misses to infer address patterns. "Global History Buffer (GHB) prefetchers maintain a FIFO table of recent cache misses and use a linked list to traverse addresses for prefetching"
- GPUWattch: A power modeling framework for GPUs integrated with simulators. "We use GPUWattch for power analysis, which is included in the Vulkan-sim codebase."
- Graph prefetchers: Prefetching mechanisms tailored to graph algorithms’ access patterns. "Graph prefetchers aim to accelerate graph search algorithms but are less effective for the irregular nature of ray tracing"
- Hardware prefetcher: A microarchitectural mechanism that predicts and fetches data before it is demanded. "We propose a novel hardware prefetcher, named Tree Traversal Prefetcher (TTP), for ray tracing."
- Indirect Memory Prefetchers (IMP): Prefetchers that learn pointer-based or indirect access patterns to anticipate future loads. "Indirect Memory Prefetchers (IMP) predict indirect memory accesses using address offsets and detect patterns with an Indirect Pattern Detector (IPD)"
- Indirect Pattern Detector (IPD): A component that detects indirect access patterns for IMPs. "Indirect Memory Prefetchers (IMP) predict indirect memory accesses using address offsets and detect patterns with an Indirect Pattern Detector (IPD)"
- Interconnect: The on-chip network linking SMs to shared caches and memory controllers. "All the SMs are connected to an L2 cache via an interconnect, which is in turn connected to the DRAM memory controllers."
- L1 accuracy (prefetch): The percentage of prefetched L1 cache blocks that are actually used by demand accesses. "TTP achieves 98.92\% average L1 accuracy, which is the ratio of the prefetched blocks being actually referenced by demand loads."
- L2 cache: The larger, shared on-chip cache level between SMs and DRAM. "All the SMs are connected to an L2 cache via an interconnect"
- LIFO (Last-In, First-Out): A stack access discipline where the most recently pushed item is popped first. "A stack (last-in first-out or LIFO) data structure stores node addresses (not the node data itself) that will be read from memory next."
- Lumibench: A benchmark suite of ray-traced scenes used for evaluation. "Lumibench has 16 scenes with increasing geometric complexity"
- Memory wall: A performance bottleneck where computation is stalled waiting on memory latency. "the memory wall is exposed as a key performance bottleneck."
- Miss Status and Handling Register (MSHR): Structures that track outstanding cache misses and allow merging. "There are multiple possible outcomes of a cache access: (1) Hit, (2) hit in MSHR(Miss Status and Handling Register), or (3) miss in MSHR."
- Misses-per-kilo-instruction (MPKI): A miss-rate metric normalized per thousand instructions. "Figure \ref{mpki} shows how the L1 and L2 RT read misses-per-kilo-instruction (MPKI) rates change with TTP."
- Path tracing: A physically based rendering technique tracing many rays per pixel to simulate global illumination. "Path tracing renders a 2D image of a 3D scene by tracing multiple rays per pixel and computing their resulting colors."
- Prefetch arbitration: The policy deciding priority between prefetch and demand requests. "We experiment with an arbitration scheme where prefetch requests are prioritized over demand requests if a fixed number of cycles have passed since the last prefetch request."
- Prefetch distance: How far ahead in an access stream the prefetcher brings data. "The parameter N determines the prefetch distance — that is, how far ahead in the queue the nodes are fetched."
- Procedural geometry: Geometry defined algorithmically rather than by explicit meshes. "Otherwise, it is a leaf node which can be a triangle or a procedural geometry necessitating an intersection shader to be executed."
- Queue (FIFO): A first-in, first-out data structure used for BFS traversal. "BFS uses a queue (first-in first-out or FIFO) structure to keep track of nodes, unlike the stack in DFS."
- Rasterization: A traditional rendering pipeline that converts geometry into pixels without ray traversal. "Unlike rasterization, ray tracing accurately models the lighting effects in a scene"
- Ray-box intersection test: A computation to determine if a ray intersects an axis-aligned bounding box. "Data in the response FIFO are fed into math units which perform ray-box, ray-triangle intersection tests or coordinate transformations depending on the node type."
- Ray generation (raygen) shader: The shader stage that initiates rays in a ray tracing pipeline. "Ray tracing pipelines introduce new programmable shader types such as ray generation(raygen), closest-hit(chit), any-hit(ahit), intersection(rint) and miss(miss) shaders."
- Ray tracing (RT) unit: Specialized hardware in GPUs that accelerates BVH traversal and intersection tests. "Within the RT unit, threads spend most of their time waiting for memory read requests to return"
- Ray tracing pipeline: The programmable sequence of shader stages used to implement ray tracing. "High-performance graphics application programming interfaces (APIs) such as Vulkan and DirectX support ray tracing pipelines, which enable developers to build ray tracing applications."
- Sector cache: A cache organization that fetches smaller sectors within a cache line. "the Vulkan-sim GPU model uses a sector cache model with sector size of 32B"
- SIMT (Single Instruction, Multiple Threads): The GPU execution model where many threads execute the same instruction in lockstep. "GPUs are Single Instruction Multiple Thread (SIMT) computers."
- Streaming Multiprocessor (SM): The primary compute unit in NVIDIA GPUs that executes warps. "A GPU consists of an array of Streaming Multiprocessors (SMs), as termed by Nvidia."
- Tree Traversal Prefetcher (TTP): The proposed prefetcher that uses traversal stack information to prefetch BVH nodes. "We propose a novel hardware prefetcher, named Tree Traversal Prefetcher (TTP), for ray tracing."
- Treelet prefetcher: A prior prefetching approach that builds and prefetches BVH subtrees (treelets). "Our results also show that TTP outperforms the state-of-the-art Treelet prefetcher, which was specifically designed for RT units."
- Vulkan-sim 2.0: A GPU simulator used to evaluate ray tracing and prefetching mechanisms. "We evaluate TTP on a cycle-level simulator, Vulkan-sim 2.0"
- Warp: A group of 32 threads executed in lockstep on NVIDIA GPUs. "Shader programs are executed by groups of 32 threads, called 'warps' by Nvidia, which operate in a lock-step manner."
- Warp buffer: Storage within the RT unit holding per-thread traversal stacks and metadata. "A warp buffer stores the per thread traversal stack and ray metadata."
- Writeback: The action of writing dirty data from cache back to a lower memory level. "Total number of DRAM reads and L2 writebacks with TTP normalized to baseline."
Collections
Sign up for free to add this paper to one or more collections.

