Papers
Topics
Authors
Recent
Search
2000 character limit reached

Megakernel vs Wavefront GPU Path Tracing

Published 26 May 2026 in cs.GR, cs.AR, and cs.PF | (2605.27323v1)

Abstract: Over the last decade, advances in GPU hardware have been driven in large part by the demands of real-time graphics, culminating in dedicated hardware ray tracing cores (RT cores). These units accelerate ray scene intersection queries directly in hardware, making physically based ray tracing algorithms increasingly practical for interactive applications. This paper compares and analyzes the performance of two ray-based rendering algorithms: forward path tracing (PT) and wavefront path tracing (WPT). GPU-based PT computes the color of each pixel by having each thread trace a single path to completion, naturally leading to a megakernel approach - while WPT maintains state buffers between specialized kernel invocations to trace path stages simultaneously. We find that WPT affords a ~16% speedup over PT in our implementation. By analyzing traces from NVIDIA Nsight Graphics, we attributed this speedup to WPT's improved cache locality compared to PT. We also find that our implementation does not achieve maximum GPU throughput across any of its units, suggesting that communication and memory latency, as well as synchronization, are the limiting factors. Finally, we address potential algorithmic improvements and future work for real-time path tracing implementation for practical applications.

Summary

  • The paper presents a comparative evaluation of two GPU-based path tracing algorithms, highlighting a 16% speedup of wavefront over megakernel.
  • It details the architectural differences, with megakernel assigning one thread per pixel and wavefront using staged kernels to enhance memory coherence.
  • The study demonstrates that optimizing memory utilization and cache reuse is crucial for achieving high throughput in complex rendering scenarios.

Comparative Analysis of Megakernel and Wavefront GPU Path Tracing

Introduction

This paper presents a methodical comparison between two pivotal GPU-based path tracing algorithms: forward megakernel path tracing (PT) and wavefront path tracing (WPT). Both algorithms address the physically-based rendering of global illumination via Monte Carlo solutions to the light transport equation, yet they diverge in their exploitation of GPU parallelism and memory organization. The motivation is to provide an empirical and profiling-driven evaluation of their relative strengths and bottlenecks on modern GPU hardware, leveraging a shared, Vulkan-based implementation framework and detailed analysis using NVIDIA Nsight Graphics.

Algorithmic Foundations

Forward megakernel PT operates by assigning one GPU thread per pixel, with each thread independently tracing an entire light transport path in a single kernel dispatch. This straightforward approach reduces synchronization and orchestration overhead but becomes susceptible to warp divergence and poor memory locality as path transport complexity increases, particularly with varying material responses, path lengths, and early terminations.

By contrast, WPT decomposes the path tracing pipeline into orthogonal stages—ray generation, scene intersection, material shading, and radiance accumulation—executed as specialized kernels. Path states are maintained and advanced across persistent queues in device memory. WPT explicitly addresses intra-warp divergence and cache inefficiency by grouping threads according to execution stage, leveraging scene and path coherence to optimize global memory access and reduce control-flow divergence.

Implementation and Architectural Optimizations

The renderer targets Vulkan compute shaders and hardware-accelerated ray tracing via inline ray queries. Scene and material data are prepacked into GPU-accessible buffers. Forward PT leverages a monolithic execution model for rapid prototyping, whereas WPT introduces persistent queues, indirect dispatch, and dynamic compaction of active path lists to amortize overhead as paths terminate due to Russian Roulette or scene misses. Furthermore, WPT’s compaction mechanism ensures only the subset of active paths are processed in each kernel pass after the initial bounces, optimizing thread utilization.

Performance Evaluation

Empirical analysis employs the "A Beautiful Game" scene on an RTX 3060 Ti, evaluating both throughput and hardware resource utilization. The key findings include:

  • Frame performance: WPT achieves 73.6 FPS (13.58 ms/frame) versus PT's 64.7 FPS (15.47 ms/frame), a 16% speedup for WPT.
  • Hardware utilization (Nsight metrics): WPT shows elevated VRAM (41.4% vs. 19.3%) and L2 cache throughput (22.5% vs. 15.8%), while PT yields higher SM (37.1% vs. 34.1%) and RTCore (16.9% vs. 11.7%) throughput, indicating differential balance between memory and arithmetic stages. Figure 1

    Figure 1: Sample real-time path-traced images generated by the GPU-accelerated renderer.

(Figure 2)

Figure 2: Top—Nsight Graphics throughput trace for megakernel PT; Bottom—trace for wavefront PT, showing distinct stage profiles and memory activity.

These observations corroborate the theoretical expectation that WPT’s staged design increases cache reuse and memory coalescing at the cost of some additional kernel synchronization. The persistent gap in global GPU resource saturation for both approaches points to persistent memory and synchronization barriers as the primary limiting factor, rather than computational throughput.

Discussion

The quantitative dominance of WPT in the tested setting supports its utility in scenarios with significant path divergence, complex materials, and longer path depths, where memory coherence and cache locality become critical for overall efficiency. The elevated VRAM and L2 throughput for WPT further underscore the import of spatial and temporal coherence in path state management. However, the marginally superior SM/RTCore utilization in PT highlights the inherent arithmetic intensity and reduced orchestration overhead of the monolithic approach, likely explaining PT’s competitiveness in simpler scenes or latency-sensitive applications.

A crucial insight is that neither approach reaches peak multiprocessor or ray tracing core utilization, suggesting that further improvements should probe reductions in synchronization overhead, reduction in global memory pressure, and more granular kernel launches or hardware queues. The implementation's modularity positions it as a testbed for investigating hybrid strategies that adaptively toggle between megakernel and wavefront organization based on scene or workload analysis.

Implications and Future Directions

The results have both practical and theoretical repercussions for GPU path tracer design. For real-time graphics applications, such as interactive previews or games, adopting a wavefront approach is increasingly viable as scene and material complexity grows—especially on hardware with robust cache hierarchies and concurrent kernel dispatch support. For production or offline rendering, where throughput rather than latency dominates, these benefits scale further as the rendering equation becomes more intractable.

Future work should consider:

  • Heuristic or hardware-driven adaptive scheduling between megakernel and wavefront phases,
  • Layout and ordering optimizations for path state data to further exploit contiguous accesses,
  • Integration of persistent threads or "work stealing" queues to improve hardware occupancy,
  • Comprehensive study across greater scene diversity and with path-guided sampling or spectral rendering extensions.

Conclusion

This study provides a rigorous, implementation-driven comparison of forward megakernel and wavefront GPU path tracing architectures. WPT demonstrates a substantial performance advantage through increased cache and memory efficiency while retaining the theoretical scalability for complex scenes. The uncovered performance bottlenecks in both approaches highlight the unfinished agenda of path tracer architecture: closing the gap between theoretical peak hardware utilization and realized performance. These results are instructive for both future real-time renderer development and the continued advancement of global illumination algorithms on modern parallel hardware.

Paper to Video (Beta)

No one has generated a video about this paper yet.

Whiteboard

No one has generated a whiteboard explanation for this paper yet.

Explain it Like I'm 14

Overview: What this paper is about

This paper looks at two different ways to make realistic computer images using a graphics card (GPU). The method they use is called “path tracing,” which simulates how light bounces around a scene to create lifelike pictures. They compare:

  • Megakernel path tracing: one big program where each pixel is handled start-to-finish by one worker.
  • Wavefront path tracing: a pipeline of smaller steps, where groups of workers do the same step together before passing results to the next step.

Their goal is to see which approach runs faster on modern GPUs and why.

Key questions the paper asks

The authors focus on a few simple questions:

  • Which design is faster on a modern GPU: one big “do-everything” program (megakernel) or a series of specialized stages (wavefront)?
  • What parts of the GPU are being used more in each design (computing, memory, special ray-tracing hardware)?
  • Why does one approach perform better—because of math speed, memory use, or something else?

How they tested it (explained simply)

Think of making a sandwich:

  • Megakernel = one person makes each sandwich from start to finish.
  • Wavefront = an assembly line: one station slices bread, another adds fillings, another wraps, and so on.

GPUs are like a huge team of tiny workers. If each worker does the whole sandwich alone (megakernel), some workers get stuck on different steps, and they don’t always use the kitchen’s tools efficiently. If you use an assembly line (wavefront), similar tasks happen together, which can make better use of shared tools and ingredients.

What they did:

  • Built both versions (megakernel and wavefront) inside the same rendering program so the comparison is fair.
  • Used the same scene, computer, and GPU (an NVIDIA RTX 3060 Ti).
  • Measured speed in frames per second and used a tool (NVIDIA Nsight Graphics) to see how much the GPU’s “brain,” memory, and ray-tracing units were working.
  • Kept the number of bounces realistic. Sometimes a light path ends early using a trick called “Russian Roulette,” which is just a smart way to randomly stop unimportant light paths to save time—like flipping a coin to decide whether to continue a long, low-value task.
  • In the wavefront version, they added a “compaction” step so later stages only work on the paths that are still alive, avoiding wasted effort.

Helpful translations:

  • “Ray” = a pretend beam of light sent into the scene to see what it hits.
  • “Kernel” = a small program run by many GPU workers.
  • “Cache/memory locality” = keeping needed data close at hand, like placing ingredients near the station that needs them so workers don’t waste time walking back and forth.
  • “Divergence” = when workers in the same group have to do different things, so some wait while others finish.

What they found and why it matters

Main results:

  • Wavefront path tracing was about 16% faster than megakernel in their tests.
    • Wavefront: about 73.6 frames per second.
    • Megakernel: about 64.7 frames per second.
  • The wavefront approach used the GPU’s memory system more effectively (better cache and VRAM activity), which helped speed.
  • Neither method fully maxed out the GPU’s compute or ray-tracing units. This suggests the slowdown isn’t about raw math speed; it’s more about waiting on memory, communication between steps, and synchronization (making sure stages run in the right order).

Why this matters:

  • Grouping similar work together (wavefront) helps GPUs avoid “traffic jams” in memory and reduces wasted work.
  • Even if one big program sounds simpler, smarter staging can make the whole process faster in real scenes.

What this could change going forward

  • For real-time graphics (like games), the wavefront approach can give smoother performance because it keeps the GPU busy in a more organized way.
  • For very complex scenes or many light bounces, wavefront methods are likely to help even more, because they reduce the chaos when rays take different paths.
  • There’s still room to improve: since neither approach used the GPU to its limits, better queueing, memory layouts, and mixing both strategies could deliver bigger gains.
  • The big idea: balancing simplicity (megakernel) and organization (wavefront) can lead to faster, more realistic rendering on modern GPUs.

Knowledge Gaps

Knowledge gaps, limitations, and open questions

The following list summarizes what remains missing, uncertain, or unexplored in the paper and can guide actionable follow-up research:

  • Hardware generality: Results are reported only on a single NVIDIA RTX 3060 Ti; no evaluation across other NVIDIA generations (Turing/Ampere/Ada), AMD RDNA2/3, or Intel Arc to assess architectural sensitivity.
  • API/path tracing stack choices: The study uses Vulkan inline ray queries only; it does not compare against Vulkan ray tracing pipelines (SBT), DXR, or OptiX to quantify API-level overheads and traversal differences.
  • Shader Execution Reordering (SER): The impact of hardware SER (Ada Lovelace and beyond) on megakernel and wavefront approaches is not evaluated; whether SER narrows or widens the gap remains open.
  • Scene diversity: Only one moderately complex scene (“A Beautiful Game”) is tested; no systematic sweep over geometry scale, instance counts, materials, textures, light types, or visibility complexity.
  • Path depth sensitivity: Performance and behavior versus maximum bounce depth and Russian Roulette parameters are not explored or modeled; no break-even analysis for deeper paths.
  • Sampling strategy effects: The roles of next-event estimation, MIS configurations, light sampling strategies, and BSDF sampling complexity are not varied or isolated.
  • Time-to-quality metrics: Comparisons are FPS-based without image-quality controls; no MSE/SSIM/FLIP vs. time analysis to ensure equal noise levels or convergence rates.
  • Denoising integration: No study of how real-time denoisers (spatial/temporal) interact with megakernel vs. wavefront scheduling, bandwidth, and latency.
  • Kernel launch and synchronization overheads: Vulkan pipeline barriers and per-bounce dispatch costs are not quantified; barrier/launch overhead vs. compute time is unknown.
  • Warp divergence quantification: Divergence/branch efficiency, occupancy, and stall reasons (e.g., memory dependency, barrier stalls) are not measured, leaving the root causes of underutilization uncharacterized.
  • Register pressure and occupancy tuning: Workgroup sizes, register usage, and shared memory allocations per kernel are not reported or tuned to understand occupancy ceilings.
  • Queue/compaction cost-benefit: Stream compaction is introduced but not dissected; the overhead, scalability, and break-even conditions of compaction/indirect dispatch are not quantified.
  • Ray reordering granularity: No exploration of more advanced binning/sorting (by BSDF/material, depth, roughness, hit instance, direction) to further improve coherence in wavefront tracing.
  • Data layout optimization: No controlled comparison of AoS vs. SoA, alignment, packing, and compression (e.g., half/quantized) for path state/hit records to reduce bandwidth.
  • Cache behavior details: While VRAM/L2 throughput is reported, cache hit rates, locality metrics, and reuse patterns (L1/L2/texture caches) are not analyzed to guide layout and staging decisions.
  • PCIe traffic sources: Not explained what causes the reported PCIe throughput; unclear whether host-device transfers (e.g., readbacks, UI) can be eliminated or overlapped.
  • Inline ray query tradeoffs: The performance difference between inline ray queries and dedicated RT pipelines (with SBT) is not measured; the chosen approach may bias conclusions.
  • Hybrid scheduling policies: No mechanism or heuristic is proposed to switch between megakernel and wavefront per scene, per bounce, or per material; no decision model predicting the better mode.
  • Persistent threads vs. multi-kernel: Persistent megakernels with in-kernel work queues (path regeneration) are not benchmarked against external wavefront queues.
  • Material/BSDF complexity scaling: OpenPBR is used, but the sensitivity to layer count, texture access intensity, normal mapping, and anisotropy is not varied; impact on divergence and cache pressure is unknown.
  • Texture system behavior: Bindless usage, sampler settings, texture working set size, and texture cache hit rates aren’t profiled; texture locality optimizations remain unexplored.
  • Shadow ray handling: The cost and scheduling of shadow rays (if any) are not separated; effect of many lights and visibility rays on each architecture is unmeasured.
  • Dynamic scenes: No evaluation with animated geometry, skinned meshes, or updated TLAS/BLAS to expose rebuild/update overhead interactions with megakernel vs. wavefront.
  • Memory footprint: Additional VRAM consumption for wavefront queues and state buffers is not quantified; scalability under memory pressure is unknown.
  • Power/thermals: Energy efficiency and thermal throttling effects are not measured; performance-per-watt differences may be material for real-time use.
  • Latency and interactivity: End-to-end latency and responsiveness (important in interactive settings) are not analyzed; megakernel may offer different latency characteristics than wavefront.
  • Overlap and concurrency: Potential gains from overlapping kernel stages, asynchronous compute, or multi-queue submission are not explored.
  • Multi-GPU scaling: No investigation into distributing queues across multiple GPUs or NVLink/PCIe constraints on wavefront state sharing.
  • Acceleration structure settings: GAS/TLAS build flags, update strategies, and compaction options are not varied; traversal performance sensitivity is unknown.
  • Reproducibility detail: Exact integrator settings (max bounces, RR thresholds), scene configurations, and measurement protocol (run-to-run variance, CI) are not fully specified; repeatability is uncertain.
  • Theoretical model: No analytic or empirical model predicts when wavefront will outperform megakernel as a function of scene/material/path-depth parameters; guidance for practitioners is missing.
  • Underutilization diagnosis: The paper notes that no unit is saturated but does not pinpoint limiting factors (e.g., long scoreboard, memory latency, sync) or propose targeted fixes validated by metrics.

Practical Applications

Immediate Applications

Below are concrete, deployable uses that build directly on the paper’s findings (wavefront path tracing + compaction yields ~16% speedup and better cache locality on RTX-class GPUs; Vulkan + inline ray queries; OpenPBR; Halton+Cranley-Patterson sampling; Nsight-based profiling).

  • Game/real-time engine optimization via wavefront PT
    • Sectors: software (games, real-time visualization)
    • Action: Replace/augment megakernel PT with a wavefront pipeline plus stream compaction and indirect dispatch to cut idle work at deeper bounces; adopt Halton+Cranley-Patterson jitter for low-spp image quality.
    • Tools/workflows: Engine modules/plugins (Vulkan/Slang or HLSL) implementing stages (ray-gen, intersect, shade, accumulate); Nsight-based performance playbooks.
    • Assumptions/dependencies: RTX-class GPUs with hardware RT and Vulkan ray queries (or DXR equivalents); scenes/materials where divergence is significant; engineering capacity to manage queueing/synchronization overhead.
  • Interactive AEC/product visualization speedups
    • Sectors: architecture/engineering/construction (AEC), design
    • Action: Integrate wavefront PT into design viewers and configurators to improve FPS during look-dev and client reviews; use OpenPBR for material consistency.
    • Tools/workflows: Viewport renderers for CAD/DCC tools with progressive accumulation and compaction; presets for interior/exterior bounce budgets.
    • Assumptions/dependencies: Workstation-class GPUs; adequate VRAM; path-traced mode already present or planned.
  • DCC/VFX look-dev viewport acceleration
    • Sectors: media/entertainment (VFX, animation)
    • Action: Port viewport path tracers to wavefront staging with persistent path-state buffers and atomics-based compaction to reduce divergence and cache misses.
    • Tools/workflows: Host-integrated render delegates/plugins (e.g., Hydra delegates) that swap kernels; profiling harness using Nsight Graphics.
    • Assumptions/dependencies: Willingness to re-architect monolithic kernels; careful material/shader graph batching.
  • Cloud streaming graphics cost reduction
    • Sectors: cloud gaming/remote visualization
    • Action: Adopt wavefront PT to reduce per-frame GPU time by ~16%, enabling higher user density or quality within fixed budgets.
    • Tools/workflows: Containerized Vulkan render services; autoscaling policies keyed to bounce depth and active-ray counts.
    • Assumptions/dependencies: Datacenter GPUs with RT cores; orchestration to exploit reduced GPU time; network constraints remain the dominant end-to-end latency factor.
  • Synthetic data for robotics and AV simulation
    • Sectors: robotics, autonomous vehicles
    • Action: Use faster wavefront PT to increase throughput for photorealistic sensor renders (RGB, NIR, fisheye) in simulators (Isaac/Omniverse/CARLA).
    • Tools/workflows: Scene/material libraries in OpenPBR; staged PT kernels with per-sensor camera models.
    • Assumptions/dependencies: Path tracing already used for sensor fidelity; multi-sensor synchronization and domain randomization pipelines in place.
  • Curriculum and lab modules for GPU architecture
    • Sectors: education, academia
    • Action: Build course labs that compare megakernel vs wavefront PT using Nsight throughput metrics (SM/RT/L2/VRAM) and show the impact of compaction.
    • Tools/workflows: Public Vulkan sample with A Beautiful Game scene and step-by-step profiling guide.
    • Assumptions/dependencies: Access to modern NVIDIA GPUs; instructor familiarity with Vulkan and Nsight.
  • Architecture decision heuristic and runtime switch
    • Sectors: software (engines, renderers)
    • Action: Embed a heuristic to switch between megakernel and wavefront based on runtime divergence/active-ray statistics and scene/material complexity.
    • Tools/workflows: Telemetry collectors for warp divergence and cache hit rates; config flags per scene/profile.
    • Assumptions/dependencies: Both integrators implemented; additional QA complexity.
  • Memory layout and cache-friendly path-state design
    • Sectors: software (rendering infrastructure)
    • Action: Reorganize path-state buffers to SoA and align with L2/VRAM throughput patterns; leverage compaction’s “active index” pattern to minimize dead lanes.
    • Tools/workflows: Data-oriented design audits; microbenchmarks tracking L2/VRAM throughput in Nsight.
    • Assumptions/dependencies: Low-level access to buffer layouts; performance engineering expertise.
  • Low-spp visual quality improvements in interactive views
    • Sectors: software (viewports), AEC, design
    • Action: Use Halton (bases 2/3) with Cranley-Patterson rotation to reduce structured noise at 1–4 spp interactive previews.
    • Tools/workflows: Sampling utilities integrated into camera-ray generation; per-pixel RNG state management.
    • Assumptions/dependencies: Progressive accumulation and tonemapping in place.
  • Reproducible benchmarking for procurement and research
    • Sectors: academia, industry R&D, policy (IT procurement)
    • Action: Package a minimal, cross-vendor Vulkan benchmark that reports FPS and throughput metrics for both architectures to inform hardware purchasing and method selection.
    • Tools/workflows: CI-tested releases; standardized scenes and settings.
    • Assumptions/dependencies: Vendor driver maturity; consistent API support for ray queries.

Long-Term Applications

These opportunities require further research, scaling, or ecosystem maturity before broad deployment.

  • Hybrid, adaptive schedulers for PT
    • Sectors: software (engines, renderers)
    • Action: Develop schedulers that mix megakernel and wavefront stages dynamically per-bounce or per-material cluster based on live telemetry (warp divergence, queue sizes).
    • Tools/products: Runtime micro-scheduler libraries; ML-guided policy learners.
    • Assumptions/dependencies: Robust, low-overhead counters; compiler/runtime support for dynamic kernel graphs.
  • Film/production-scale wavefront PT with out-of-core support
    • Sectors: media/entertainment
    • Action: Extend queue-based decomposition to multi-GPU and distributed render farms with out-of-core geometry/textures and deep path depths.
    • Tools/products: Queue managers across nodes; persistent path state sharding; I/O-aware compaction.
    • Assumptions/dependencies: Networked memory systems; denoising and MIS optimizations to contain noise at high complexity.
  • Energy-efficient rendering policy and reporting
    • Sectors: policy (sustainability), industry R&D
    • Action: Standardize energy-per-frame metrics for PT architectures; encourage wavefront-like coherence optimizations in green-computing guidelines.
    • Tools/products: Energy metering integrated with Nsight traces; procurement criteria factoring joules/frame.
    • Assumptions/dependencies: Reliable power telemetry; consensus benchmarks; vendor cooperation.
  • Real-time path-traced VR at 90–120 Hz
    • Sectors: AR/VR, gaming
    • Action: Combine wavefront PT, aggressive compaction, foveated rendering, and advanced denoisers to meet VR frame budgets.
    • Tools/products: Eye-tracked foveated PT pipelines; ultra-low-latency kernel orchestration.
    • Assumptions/dependencies: Next-gen GPUs; improved kernel launch/sync overheads; sophisticated denoising.
  • Mobile/edge ray tracing adoption
    • Sectors: mobile AR, edge computing
    • Action: Port wavefront concepts to mobile-class RT hardware when available; tailor compaction to tighter memory and power envelopes.
    • Tools/products: Lightweight Vulkan RT backends; power-aware schedulers.
    • Assumptions/dependencies: Mature mobile RT cores and drivers; thermal budgets; simplified scenes.
  • Auto-tuning compilers/runtime for ray tracing
    • Sectors: software tooling, compilers
    • Action: Integrate wavefront/megakernel selection and buffer layout tuning into shader compilers (e.g., Slang/HLSL) and drivers via profile-guided optimization.
    • Tools/products: PGO toolchains; driver-exposed scheduling primitives; IR that captures stage graphs.
    • Assumptions/dependencies: Vendor API support; stable intermediate representations.
  • Standard academic testbeds for GPU ray tracing architecture
    • Sectors: academia
    • Action: Establish open datasets, kernels, and metrics to evaluate divergence, cache locality, and synchronization across architectures/vendors.
    • Tools/products: Community-maintained suites; reproducibility checklists.
    • Assumptions/dependencies: Funding and cross-institution collaboration; vendor engagement.
  • Building energy/daylighting simulation with PT backends
    • Sectors: energy, AEC
    • Action: Leverage wavefront PT to accelerate physically based daylighting/lighting compliance simulations for design iteration.
    • Tools/products: Plugins for simulation suites using OpenPBR-like materials mapped to photometric data; validated workflows.
    • Assumptions/dependencies: Accurate light transport features (MIS, spectral models) and validation; regulatory acceptance.
  • High-fidelity, real-time sensor simulation in HIL loops
    • Sectors: robotics, automotive
    • Action: Use more efficient PT to render multiple sensors concurrently in hardware-in-the-loop testing without offline precomputation.
    • Tools/products: Multi-sensor wavefront schedulers; deterministic seeding and timing controls.
    • Assumptions/dependencies: Further speedups and denoising advances; predictable latency guarantees.
  • Applying wavefront-style queueing to non-graphics SIMT Monte Carlo
    • Sectors: finance (risk/option pricing), energy (stochastic simulation), HPC
    • Action: Investigate whether wavefront-like staging improves coherence and cache behavior for divergent Monte Carlo workloads on GPUs.
    • Tools/products: Pattern libraries for queue-based SIMT kernels; benchmarking suites.
    • Assumptions/dependencies: Problem structure must allow staging; care with memory traffic and synchronization overheads.
  • Cloud-native GPU scheduling leveraging active-ray telemetry
    • Sectors: cloud computing
    • Action: Scale-out render services that adjust bounce depth, sample counts, and kernel staging based on live active-ray counts to balance quality and throughput.
    • Tools/products: Kubernetes operators with rendering-aware autoscalers; SLA-driven quality governors.
    • Assumptions/dependencies: Robust observability; multi-tenant isolation; predictable demand profiles.

Glossary

  • Acceleration structure: A spatial data structure that accelerates ray–scene intersection queries by organizing geometry for efficient traversal. "We use BLAS/TLAS acceleration structures to support efficient ray-scene intersection"
  • Adobe OpenPBR: An open material model specification from Adobe for physically based rendering. "Material response is modeled using Adobe OpenPBR"
  • Assimp: A library for importing assorted 3D asset formats into applications. "assets are imported through Assimp"
  • Bidirectional scattering distribution function (BSDF): A function that defines how light is reflected and transmitted at a surface for given incoming and outgoing directions. "f is a bidirectional scattering distribution function (BSDF)"
  • BLAS (Bottom-Level Acceleration Structure): An acceleration structure built over individual meshes or geometry instances, referenced by TLAS for ray traversal. "BLAS/TLAS acceleration structures"
  • Cache locality: The tendency for memory accesses to be clustered so that cache lines are reused effectively. "improved cache locality compared to PT."
  • Cranley-Patterson rotation: A technique to decorrelate low-discrepancy sample sequences by applying a random shift in the unit cube. "Cranley-Patterson rotation to decorrelate spatially adjacent pixels"
  • GPU stream compaction: Parallel removal of inactive elements from arrays to keep only active work items, improving efficiency. "GPU stream compaction via atomic index lists and indirect dispatch to reduce idle thread overhead across bounce iterations."
  • Halton low-discrepancy sequence: A quasi-random sequence that provides well-distributed sample points for Monte Carlo integration. "Halton low-discrepancy sequence with bases 2 and 3"
  • Hardware ray tracing cores (RT cores): Dedicated GPU units that accelerate ray traversal and intersection operations. "dedicated hardware ray tracing cores (RT cores)"
  • Indirect dispatch: Launching GPU work where thread counts are read from GPU memory, enabling data-dependent execution sizing. "indirect dispatch to reduce idle thread overhead across bounce iterations."
  • Inline ray queries: Ray tracing operations invoked directly from shaders without separate ray tracing pipeline stages. "Vulkan inline ray queries"
  • Khronos glTF: An open standard 3D asset format by the Khronos Group for efficient transmission and loading. "the Khronos glTF sample assets"
  • L2 cache: The on-GPU second-level cache that buffers data between memory and compute units. "L2 cache throughput (22.5\% vs.\ 15.8\%)"
  • Light Transport Equation: The integral equation describing radiance transfer in a scene; also known as the rendering equation. "Light Transport Equation"
  • Megakernel: A single, monolithic GPU kernel that performs all stages of an algorithm end-to-end per thread. "The megakernel implementation does the above steps from a single kernel dispatch"
  • Monte Carlo Integrator: A numerical estimator that approximates integrals using random or quasi-random samples. "A Monte Carlo Integrator provides an estimate of an integral"
  • Nsight Graphics: NVIDIA’s profiling and debugging tool for analyzing GPU workloads and performance. "NVIDIA Nsight Graphics"
  • OpenPBR layered BSDF: A layered material model within OpenPBR that combines multiple BSDF lobes for complex appearances. "OpenPBR layered BSDF"
  • Path throughput: The cumulative weight of a light path due to successive BSDF evaluations and geometry terms. "T(\mathbf{x}_n) is the path throughput"
  • PCIe Throughput: The data transfer rate between the GPU and host over the PCI Express bus. "PCIe Throughput"
  • Queue-based decomposition: Organizing work into queues per stage to improve coherence and scheduling in wavefront methods. "queue-based decomposition improved coherence"
  • Radiance: The measure of light power per unit area per unit solid angle traveling in a given direction. "Rendering can be formulated as a recursive integral equation that describes the transport of radiance between surfaces."
  • Ray generation: The stage that initializes rays (often from the camera) and per-ray state before traversal. "The ray generation stage initializes per-pixel ray state"
  • Ray-scene intersection: The computation of where (and if) a ray intersects objects in the scene. "ray-scene intersection queries"
  • Russian Roulette: A probabilistic path termination technique to keep estimators unbiased while reducing computation at deeper bounces. "due to Russian Roulette and scene misses."
  • SIMT divergence: Inefficiency on GPUs when threads in a warp take different execution paths under the Single-Instruction Multiple-Thread model. "primarily addresses SIMT divergence and memory coherence."
  • Slang shaders: Shaders authored in Slang, a shading language designed for modular, cross-platform GPU programming. "shading and light transport are evaluated in Slang shaders"
  • SM (Streaming Multiprocessor): The primary compute unit on NVIDIA GPUs that executes warps of threads. "SM throughput (37.1\% vs.\ 34.1\%)"
  • TLAS (Top-Level Acceleration Structure): An acceleration structure over instances that references BLAS for traversal across the whole scene. "top-level acceleration structure (TLAS)"
  • Tonemapping: Mapping high dynamic range render values to a displayable range for output images. "tonemapping for display output."
  • Vulkan: A low-overhead, cross-platform graphics and compute API used for GPU programming. "Vulkan-based GPU path tracer"
  • Vulkan pipeline barriers: Synchronization primitives in Vulkan that ensure correct memory visibility and execution ordering between GPU stages. "explicit Vulkan pipeline barriers ensure that buffer writes produced by each kernel are fully visible"
  • Warp: A group of threads that execute in lockstep on a GPU; divergence within a warp reduces efficiency. "threads within a warp can quickly diverge"
  • Wavefront Path Tracing (WPT): A path tracing architecture that processes stages in separate kernels with queues to improve coherence. "Wavefront Path Tracing (WPT) decouples the path tracing pipeline into four sequential GPU compute stages: ray generation, scene intersection, material shading, and radiance accumulation."

Open Problems

We haven't generated a list of open problems mentioned in this paper yet.

Collections

Sign up for free to add this paper to one or more collections.

Tweets

Sign up for free to view the 2 tweets with 53 likes about this paper.