Megakernel vs Wavefront GPU Path Tracing
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.
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 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."
Collections
Sign up for free to add this paper to one or more collections.