WebGPU Forward+ / Clustered Deferred renderer

• Luke (Hyuk Che) Kwon
  • LinkedIn, Personal Website, Github
• Tested on: Windows 11, AMD Ryzen 5 5600X 6-Core Processor @ ~3.7GHz 16GB, Nvidia GeForce RTX 3060 (Compute Capability 8.6)

Live Demo

Please check out the Live Demo for smoother fps than the gif (you can switch rendering modes via the dropdown menu on the top right).

This project implements and compares three real-time lighting pipelines written in TypeScript and WGSL: Naive Forward, Forward+, and Clustered Deferred. The project renders the Sponza scene with animated point lights and uses a shared 3D light-clustering pass to reduce lighting work.

Implementation Details

Naive

The naive renderer draws the scene in a single geometry pass. Each shaded fragment evaluates the point lights directly. This provides a simple baseline without a clustering pass or G-buffer, but lighting work increases with both the number of lights and the number of shaded fragments.

Forward+

Forward+ divides the camera frustum into a 3D grid. A compute pass assigns lights to clusters, storing a light count and a fixed-capacity list of light indices for each cluster. During rendering, each fragment identifies its cluster and evaluates only the lights in that list.

This trades the cost of constructing the cluster lists for reduced fragment-shader lighting work. Grid resolution, workgroup size, and list capacity are configurable.

Clustered Deferred

Clustered Deferred reuses the same clustering pass, then separates geometry processing from lighting:

1. The geometry pass writes world-space position, normal, and albedo to a G-buffer while performing depth testing.
2. A fullscreen triangle reads the G-buffer and computes lighting using the corresponding cluster’s light list.

Deferred shading adds G-buffer storage and bandwidth costs, but moves expensive lighting out of the geometry pass. Geometry overdraw can still occur, as it no longer repeats the full lighting calculation for each shaded geometry fragment.

Performance

Measurement Method

GPU timestamp queries measure the duration of each instrumented pass. After a five-second warmup, samples are collected over a ten-second window. The reported value is the sum of the mean pass durations in milliseconds, so lower is better.

The measurements exclude CPU submission, browser scheduling, and the separate light-animation pass.

The light-count, grid-resolution, and workgroup tests below use a maximum of 100 lights per cluster, but visual observations indicate that higher light counts require larger capacities to avoid missing illumination.

Number of Lights

Grid resolution, workgroup size, and list capacity remain at their baseline values.

Naive rendering is fastest at one light, where its single-pass pipeline avoids clustering and G-buffer overhead. Its cost then grows approximately linearly with light count, reaching 607 ms at 5,000 lights.

Both clustered approaches reduce the measured lighting cost substantially. Clustered Deferred is faster than Forward+ throughout this sweep. Separating lighting from geometry processing is a plausible contributor, particularly when geometry overdraw causes Forward+ to evaluate lighting multiple times for a pixel.

Above roughly 2,000 lights, the clustered curves flatten considerably. This should likely be interpreted alongside the 100-light capacity where once lists fill, additional lights may be omitted rather than shaded.

Cluster-Grid Resolution

This test varies all three grid dimensions, keeping 3,000 lights, 64 invocations per workgroup, and capacity 100 fixed.

Increasing cluster-grid resolution produced a small increase in performance between 1,728 and 13,824 clusters for Forward+, while Clustered Deferred became slower at finer resolutions. However, finer grids did not consistently improve performance overall. This maybe because reduced lighting work was likely offset by increased clustering cost. The fixed 100-light capacity may also have limited the benefit of finer grids by already capping shading work in crowded clusters.

Clustering Workgroup Size

This test uses 3,000 lights, the baseline grid, and capacity 100. The workgroup-size column counts total invocations, not the length of one axis.

Increasing from one invocation to 64 reduces total time by approximately 22.6% for Forward+ and 52.8% for Clustered Deferred. Beyond 64 invocations, the measured totals are nearly unchanged. The difference between 64 and 216 is only 0.043 ms for Forward+ and 0.004 ms for Deferred. Without variability measurements, these small differences do not establish a meaningful winner.

Maximum Lights per Cluster

This test uses 3,000 lights, the baseline grid, and 64 invocations per workgroup.

Increasing capacity allows longer light lists and increases allocated storage. When lists previously overflowed, it also restores lighting work that smaller capacities omitted. The large timing increase therefore represents an exchange between quality and workload.

Minimum Max Lights per Cluster for No Artifacts

The following capacities were visually estimated to largely remove missing-light artifacts.

These are visual observations for the tested view, not mathematically proven overflow-free limits, but they do show a linear relationship between the required number of maximum lights per cluster and the number of lights in the scene.

Performance at Higher Light-List Capacity

With 3,000 scene lights and a capacity of 600 lights per cluster (visually sufficient to avoid missing light artifacts in the tested view) Clustered Deferred achieved an 11.1× GPU speedup over Naive Forward.

Linear vs Logarithmic

Depth slicing determines how the frustum is divided along the view direction. Both schemes can use the same number of clusters while assigning different depth ranges to each slice.

Linear - Visible Artifacts	Logarithmic - No Visible Artifacts

Both images use a 32 × 18 × 24 cluster grid, 4 × 4 × 4 workgroups, and a maximum of 100 lights per cluster.

With identical settings, logarithmic depth slicing produced no visible artifacts, while linear slicing did. This likely relates to the large depth range. camera.ts sets the far plane to 1,000, while move_lights.cs.wgsl distributes lights around a much smaller box, from (-10, 0, -5) to (10, 8, 5). Linear slicing concentrates these nearby lights into a few thick slices, increasing the risk of exceeding the per-cluster light capacity. Logarithmic slicing allocates finer slices near the camera, reducing that pressure.

Credits

• Vite
• loaders.gl
• dat.GUI
• stats.js
• wgpu-matrix