@woosh/meep-engine 3.49.0 → 3.50.0

package/src/shade/renderer/light/cluster/PROPOSAL_HIERARCHICAL_2026_10_16.md

@@ -0,0 +1,1101 @@
+# Cluster light assignment: the decided design and implementation plan (2026-10-16)
+
+Status: **landed on master, 2026-10-16** (Part IV: the commits, what changed from the plan, and the
+post-landing measurements). Alex closed every fork on 2026-10-16. Part I is the design as decided, Part II
+the measurements behind it, Part III the implementation plan. Appendix A keeps the round-2 and round-3 record (`R3`, §0–§7). Where the record
+conflicts with Parts I–III, Parts I–III win.
+
+**Fixed constraints:**
+
+- The grid stays 32 px × 24 slices.
+- The input is the cull's atomic-appended `(id, type)` list, exactly as today. Nothing moves into
+  `graph_cull_lights`.
+- The last slice is unbounded: [`depth_from_slice(23)`, ∞). That is intentional, and the tests handle the
+  unbounded cell in XY only.
+- Every cell is served, empty space included. No stage reads depth or the HZB.
+- Consumers keep today's product: `LIGHT_CLUSTER_METADATA {counts, offset}` + `cluster_data`, points then
+  spots.
+
+## Part I — The design
+
+### I.1 Decisions
+
+| fork | decision (Alex) | in the design |
+|---|---|---|
+| F1 | count-then-write, no per-cell cap, counts 16 bits per type | the fine pass counts every hit, makes one exact allocation, writes all hits |
+| F2 | yes | the light-scatter coarse mask runs at every light count. 1,024 survives only as a loop budget (I.3) |
+| F3 | yes | the id-sorting prepass stays |
+| F4 | G | the coarse unit is the 4×4×4 block, which is one fine workgroup |
+| F5 | "per consumer, they decide on their own" | each consumer loop owns a budget constant and a doc line; the product imposes no limit (I.5) |
+| F6 | "size off the coarse cull … one frame incorrectness is totally acceptable on overflow" | `cluster_data` is sized through `GPUCollectionLimits` from the prepass's tight bound; an overflowing frame truncates (I.4) |
+| F7 | "don't bother" | 4×4×4 workgroup, subgroup-scan compaction as in A2/G. The order inside a cell is deterministic, not ascending (I.6) |
+
+### I.2 The passes
+
+Six direct dispatches in one compute pass. No indirect dispatch and no readback on the frame's path.
+
+| # | pass | threads | does |
+|---|---|---|---|
+| 1 | **mark** | one per culled entry; dispatch over the CPU-known clusterable count | ORs `(type, id)` into a per-type visibility bitmask sized by the light tables' extents |
+| 2 | **compact** | one workgroup of 256 | ordered compaction of the bitmask into the light list sorted by (type, id). The bitmask is a FrameGraph transient the graph clears; compact reads it through a plain read-only view. Rounds of 256 threads × 64 bits = 16,384 table slots, with a workgroup-memory scan in thread order, so the order holds by construction, not by the subgroup lane mapping. The ids are table slots, so the rounds follow the tables' extents; the set bits never exceed the cull list's limit (16,383) |
+| 3 | **prepare** | one per sorted light | one database read; writes the view-space proxy (sphere, spot apex/height/direction/cos, source radius) and the packed cell box (tile x/y from the sphere's exact tangent extents, slices from `cluster_depth_to_z_slice`); sums the **tight sizing bound** Σ cell-box volume (workgroup-memory sum, one global atomic per workgroup) |
+| 4 | **coarse clear** | blocks × ⌈L/32⌉ words, from the device count | zeroes the per-block light masks |
+| 5 | **coarse scatter** | one workgroup per sorted light | ORs the light's bit into every 4×4×4 block its cell box touches |
+| 6 | **fine** | one 4×4×4 workgroup per block, one thread per cell | per 64-light chunk: skip if the block's two mask words are 0; else compact the survivors (subgroup exclusive add + per-subgroup offsets) into workgroup memory; each cell runs box + precise test (6-plane sphere; spot cone vs the cell's bounding sphere, unbounded last slice by the cone's own bounding sphere in XY). **Sweep 1** counts per type (uncapped), **one subgroup-aggregated allocation**, **sweep 2** writes, then metadata `{point \| spot << 16, offset}` |
+
+**O() and zero-light cost:**
+
+| pass | cost is O() in | at zero lights |
+|---|---|---|
+| mark, prepare | L | early exit |
+| compact | table extent / 32 words, in rounds of 512 | one workgroup, one round per 16,384 slots |
+| coarse clear | blocks × ⌈L/32⌉ | nothing |
+| coarse scatter | Σ over lights of blocks covered | nothing |
+| fine | cells × block survivors + hits (two sweeps); + O(cells) metadata write | O(cells) metadata write: the floor |
+
+**Measured zero-light totals:** 7–8 µs on the 4090, 6–81 µs on the iGPU (II.1).
+
+### I.3 Per-thread loop budgets
+
+| loop | budget | what is past it |
+|---|---|---|
+| compact | 64 bits per thread per round; one round per 16,384 table slots | nothing |
+| scatter | coarse blocks / 64 per thread (≤ 48 at 4K) | nothing |
+| fine, chunks | ⌈L/64⌉ (≤ 256 at the cull limit); an empty pair of words costs two loads | nothing |
+| fine, survivors per chunk | ≤ 64 | nothing |
+| the 1,024 figure (F2) | survives only as a loop budget: ≤ 1,024 lights is ≤ 16 fine chunks of 64 (32 lanes × 32 bits) | there is no speed switch at 1,024; the mask path always runs |
+
+### I.4 Sizing and overflow (F6)
+
+1. **The bound.** `prepare` accumulates **Σ over sorted lights of its cell box's cells**. This is the box
+   test's candidate count, which is an upper bound on hits, since the fine pass only rejects. Measured
+   tightness is in II.2.
+   - It costs nothing measurable when summed in `prepare` with a workgroup-memory sum and one global
+     atomic per workgroup (II.2). That is the design.
+   - Putting it in the scatter instead costs the iGPU 15–48 µs: two contended atomics per light.
+2. **The column.** The bound word is recorded with `graph_record_stat` into a new `GPUCollectionLimits`
+   column, `RasterizationCollectionType.LightClusterEntries` (element size 4 B). `cluster_data` is
+   allocated at `compute_buffer_size(LightClusterEntries) + 4` bytes (the leading offset word).
+   - Priming: `prime(LightClusterEntries, …)` from today's `estimate_cluster_data_limit` (64.5 words per
+     cell) on the first frame of a resolution, so nothing regresses before the first readback.
+3. **Overflow.** The fine pass's allocation atomic keeps counting past capacity. Each subgroup gets
+   `min(its count, what is left)` (points first), and later subgroups get 0.
+   - **That frame's truncated cells are non-deterministic.** Measured: with the pool at half the demand,
+     71–149 cells differed between runs.
+   - The next frames grow the column. The limits' own runaway clamp staggers a large jump over up to about
+     3 frames (its comment, `GPUCollectionLimits.#clamp_stats_against_runaway`; not measured here).
+   - `cluster_data` is a FrameGraph transient: the size is a per-frame request, not memory held between
+     frames.
+
+### I.5 Consumer budgets (F5)
+
+The product imposes no limit. Each consumer loop owns a budget constant **in that consumer's file**, chosen
+by whoever builds it and presented as a chosen number, not a derived one. Each budget carries a doc line on
+what it drops (I.6).
+
+| consumer | loop | where the constant goes |
+|---|---|---|
+| deferred direct shading; also forward, OIT resolve, AVBOIT draw and water, which include the same chunk | `deferred/chunk_shade_standard_material_direct.js:66` (points), `:87` (spots) | the chunk is shared by five passes. Either one constant in the chunk, or a constant per including shader passed in. That is the consumers' choice. Today they all inherit one loop |
+| volumetrics irradiance | `volumetrics/shader_volumetrics_build_irradiance.js:154`, `:167` | that file |
+| volumetrics lighting | `volumetrics/shader_volumetrics_build_lighting.js:312`, `:353` | that file |
+| ReSTIR DI candidates | `restir/di/chunk_restir_generate_candidates.js:61`, `m_initial` iterations | **nothing more needed.** The loop is already bounded by `m_initial`. The cell's `count` only scales the uniform source pdf (`inv_source_pdf = count`) and picks a slot, so a longer list costs nothing per pixel. It must read the 16-bit fields through the helpers, which it already does |
+
+**Why the budgets matter (measured, R3.2 dense scene):** a cell of about 1,800 lights made the consumer
+stand-in 6–7× slower than the 128-capped list.
+
+### I.6 Order inside a cell, and what a budget drops (F7)
+
+The fine pass writes survivors in sorted-list order, chunk by chunk (64 lights per chunk, ascending).
+Inside a chunk, the order follows the **subgroup lane permutation** of the 4×4×4 workgroup, which is not
+`local_invocation_index` order on either tested GPU.
+
+- **The list is chunk-major ascending, permuted within 32-light windows.**
+- **Deterministic frame to frame:** the permutation is fixed per device, driver and pipeline, and was
+  stable across every repeated run here. It may differ between GPUs.
+- **Nothing in the design depends on ascending order:**
+  - there is no cap and no keep-smallest;
+  - the counts are exact;
+  - consumers sum light contributions (order changes only float rounding);
+  - ReSTIR samples uniformly by slot.
+- **What a consumer budget B drops:** the list's tail after position B. That is every light of the later
+  chunks, plus, inside the chunk that straddles B, whichever lanes the permutation puts last. Plainly:
+  **past the budget it drops the highest ids, except within one 32-light window where the choice follows
+  the GPU's lane order.** It is deterministic on one machine, not identical across machines. Points and
+  spots are separate runs, so a per-loop budget applies per type.
+- **Decals are different.** Their composite order is priority order, so the decal builder must not reuse
+  this compaction unchanged (III.6).
+
+## Part II — Measurements for the decided design
+
+**Method.** As in Appendix §0: paired, timestamped, mirrored minimum, p10.
+
+| | arms | iterations | foreign GPU load |
+|---|---|---|---|
+| RTX 4090 | A0 (today), A2 (round-1 cell-centric), the decided design ("final"), and the per-cell floor | 300 | 9–17% |
+| AMD RDNA2 iGPU | same | 20 | none |
+
+The final arm's sets equal the uncapped arm's in every cell, dense scene included (16-bit set check).
+
+### II.1 Assignment time (p10)
+
+| config | 4090 A0 | 4090 A2 | **4090 final** | iGPU A0 | iGPU A2 | **iGPU final** |
+|---|---:|---:|---:|---:|---:|---:|
+| 640×360, 0 | 4.1 | 5.1 | **7.2** | 106.6 | 4.8 | **5.7** |
+| 640×360, 16 | 10.2 | 9.2 | **11.3** | 123.7 | 13.6 | **14.0** |
+| 640×360, 1,024 | 486.4 | 73.7 | **82.9** | 8.12 ms | 117.6 | **122.2** |
+| 640×360, 4,096 | 2.14 ms | 302.1 | **332.8** | 36.18 ms | 499.9 | **515.8** |
+| 1898×982, 0 | 31.7 | 5.1 | **7.2** | 906.6 | 21.0 | **22.6** |
+| 1898×982, 16 | 39.9 | 8.2 | **11.3** | 953.8 | 69.5 | **61.6** |
+| 1898×982, 1,024 | 729.1 | 56.3 | **62.5** | 60.59 ms | 618.4 | **474.0** |
+| 1898×982, 4,096 | 3.16 ms | 221.2 | **239.6** | 271.8 ms | 2.64 ms | **2.07 ms** |
+| 4K, 0 | 208.9 | 6.1 | **8.2** | 3.53 ms | 76.6 | **80.8** |
+| 4K, 16 | 217.1 | 10.2 | **11.3** | 3.70 ms | 270.3 | **230.1** |
+| 4K, 1,024 | 2.32 ms | 58.4 | **62.5** | 254.3 ms | 2.43 ms | **1.71 ms** |
+| 4K, 4,096 | 10.76 ms | 236.5 | **254.0** | — ¹ | 10.33 ms | **7.77 ms** |
+
+All values are µs unless marked ms. ¹ Not run: TDR margin.
+
+- **Against today:**
+  - ≥ 1,024 lights: 5.9–42× faster on the 4090 and 66–149× on the iGPU;
+  - 0–16 lights at 1898×982 and 4K: 3.5–25× on the 4090 and 9–44× on the iGPU;
+  - **at 640×360 with 0–16 lights it is 1–3 µs slower than today on the 4090** (7.2 vs 4.1, 11.3 vs
+    10.2): six dispatches against one, where today's pass has almost nothing to do.
+- **Against A2:**
+  - 4090: +7–12% at ≥ 1,024 lights, and +1–3 µs at 0–16 lights. That is the mask path's two extra
+    dispatches (F2), measured before as ≤ 9 µs.
+  - iGPU: −11% to −30% at 1898×982 and 4K from 16 lights up; +3% to +18% at 640×360 and at 0 lights.
+
+**Per pass at 1,024 lights, 1898×982:**
+
+| | mark | compact | prepare | coarse clear | coarse scatter | fine |
+|---|---:|---:|---:|---:|---:|---:|
+| 4090 | 1.0 | 3.1 | 2.0 | 1.0 | 2.0 | 53.2 |
+| iGPU | 11.0 | 4.9 | 9.7 | 3.0 | 26.4 | ~460 ² |
+
+² The iGPU's isolated per-pass run read **1,032 µs** for the fine pass alone, more than the whole chain's
+474 µs in the paired run. **Unexplained.** The chain total is the figure to use; the iGPU's per-pass
+numbers for the fine pass are not reliable here.
+
+**Registers (measured on the exact final kernels; NVIDIA 610.88 / AMD 2.0.302 Vulkan):**
+
+| kernel | threads | NV regs | NV local | Ada occupancy | AMD VGPR | AMD scratch | AMD LDS |
+|---|---:|---:|---:|---:|---:|---:|---:|
+| fine | 64 | 48 | 0 | 83% | 42 | 0 | 1,024 |
+| coarse scatter | 64 | 30 | 0 | 100% | 10 | 0 | 0 |
+| coarse clear | 256 | 16 | 0 | 100% | 3 | 0 | 0 |
+| mark | 64 | 16 | 0 | 100% | 3 | 0 | 0 |
+| compact | 256 | 20 | 0 | 100% | 18 | 0 | 512 |
+| prepare + bound | 64 | 27 | 0 | 100% | — ³ | — | — |
+
+³ My offline `vkstats.py` route failed to compile this pipeline on the AMD driver. That is a tooling result
+and says nothing about what ships; Chrome runs it on that iGPU.
+
+### II.2 The sizing bound against actual hits (F6)
+
+Identical on both GPUs (it is geometry). Bytes are bound × 4.
+
+| scene | lights | hits (exact) | **tight bound** Σ cell-box volume | **tight / hits** | loose: Σ covered blocks' cells | loose / hits | tight bound reserves |
+|---|---:|---:|---:|---:|---:|---:|---:|
+| §2, 640×360 | 16 | 155 | 157 | **1.013** | 2,048 | 13.2 | 0.6 KB |
+| §2, 640×360 | 1,024 | 29,096 | 30,229 | **1.039** | 167,616 | 5.8 | 121 KB |
+| §2, 640×360 | 4,096 | 118,905 | 123,685 | **1.040** | 682,688 | 5.7 | 495 KB |
+| §2, 1898×982 | 16 | 717 | 733 | **1.022** | 4,544 | 6.3 | 2.9 KB |
+| §2, 1898×982 | 1,024 | 184,933 | 194,088 | **1.050** | 639,232 | 3.5 | 776 KB |
+| §2, 1898×982 | 4,096 | 761,323 | 798,852 | **1.049** | 2,666,160 | 3.5 | 3.2 MB |
+| §2, 4K | 16 | 2,854 | 2,972 | **1.041** | 12,288 | 4.3 | 12 KB |
+| §2, 4K | 1,024 | 818,675 | 857,113 | **1.047** | 2,345,152 | 2.9 | 3.4 MB |
+| §2, 4K | 4,096 | 3,356,945 | 3,517,641 | **1.048** | 9,901,376 | 2.9 | 14.1 MB |
+| dense, 640×360 | 4,096 | 2,033,294 | 2,595,249 | **1.276** | 4,204,864 | 2.1 | 10.4 MB |
+| dense, 1898×982 | 4,096 | 15,069,093 | 19,473,322 | **1.292** | 29,285,824 | 1.9 | 77.9 MB |
+| dense, 4K | 4,096 | 67,654,718 | 86,909,083 | **1.285** | 128,367,424 | 1.9 | 347.6 MB |
+
+**Reading it.**
+
+- **The tight bound is close where Alex expected:** 1.01–1.05× in the §2 scene.
+- **It is loose in the dense scene: +28–29%,** 17.6 MB over the hits at 1898×982 and 77 MB at 4K. The
+  slack is the box test's own: big spot lights whose box is the flat-capped cone's bounding sphere, and the
+  corner cells of a sphere's box.
+- **The "survivors × block cells" form is far looser:** 1.9–13×. The design uses the cell-box sum.
+
+**Cost of producing the bound** (paired, p10):
+
+| config | 4090 none | 4090 in prepare | 4090 in scatter | iGPU none | iGPU in prepare | iGPU in scatter |
+|---|---:|---:|---:|---:|---:|---:|
+| 640×360, 4,096 | 334.9 | 334.9 | 335.9 | 517.2 | 509.2 | 559.0 |
+| 1898×982, 4,096 | 237.6 | 237.6 | 239.6 | 2,071.9 | 2,063.0 | 2,101.8 |
+| 4K, 4,096 | 250.9 | 250.9 | 254.0 | 7,751.9 | 7,751.3 | 7,727.3 |
+| 1898×982, dense | 2,040.8 | 2,041.9 | 2,042.7 | — | — | — |
+
+**In `prepare` it is free** within noise on both GPUs. In the scatter, its two per-light atomics cost the
+iGPU up to 48 µs.
+
+## Part III — Implementation plan
+
+### III.1 Files
+
+All paths are under `packages/meep-engine/src/shade/renderer/`.
+
+**New:**
+
+| file | what |
+|---|---|
+| `light/cluster/chunk_cluster_light_proxy.js` | WGSL: a point/spot record + view + cluster params → view-space proxy + packed cell box + box volume. A pure function, lifted from the bench's `prepare` |
+| `light/cluster/chunk_cluster_cell.js` | WGSL: cell from `(x, y, z)` (4 eye planes from the tile's NDC edges, depths from `chunk_cluster_depth_from_z_slice`, bounding sphere when bounded); `sphere_vs_cell`; `spot_vs_cell` (cone vs the cell sphere, or the cone's own bounding sphere vs the planes for the unbounded slice) |
+| `light/cluster/shader_cluster_light_mark.js` | pass 1 |
+| `light/cluster/shader_cluster_light_compact.js` | pass 2 |
+| `light/cluster/shader_cluster_light_prepare.js` | pass 3, with the bound |
+| `light/cluster/shader_cluster_coarse_mark.js` | passes 4 + 5 (clear and scatter; two entry points or two shaders) |
+| `light/cluster/LIGHT_CLUSTER_COARSE_BLOCK.js` | the 4-cell block edge = the fine workgroup's edge |
+
+**Changed:**
+
+| file | change |
+|---|---|
+| `light/cluster/shader_cluster_assign_lights.js` | rewritten as pass 6 (fine pass). The private array, `frustum_slice` usage and per-pair corner rebuild go |
+| `light/cluster/graph_assign_clsuters.js` | encodes the 6 dispatches in one compute pass; creates the sorted list, proxies, boxes, visibility and coarse masks, bound word; sizes `cluster_data` from `GPUCollectionLimits`; records the bound with `graph_record_stat` |
+| `light/cluster/chunk_light_cluster_counts.js` | 16-bit fields; `LIGHT_CLUSTER_PER_TYPE_MAX` = 65,535 |
+| `light/cluster/LIGHT_CLUSTER_METADATA.js` | doc: bits [0:15] point, [16:31] spot |
+| `rasterize/expand/RasterizationCollectionType.js`, `rasterize/expand/GPUCollectionLimits.js` | new column `LightClusterEntries`, element size 4, initial global max |
+| consumers (I.5) | a budget constant each, chosen by their owner |
+
+**Deleted:**
+
+- `light/cluster/LIGHT_CLUSTER_LOCAL_LIGHT_LIMIT.js`;
+- `light/cluster/chunk_cluster_keep_smallest.js` and its `.spec.js`.
+
+`chunk_cluster_slice_frustum`, `chunk_frustum_from_corners`, `chunk_frustum_to_corners` and
+`chunk_plane_from_triangle` stay, because the decal builder still links them. The light path stops linking
+them.
+
+### III.2 Order of work, and the spec that pins each step red-then-green
+
+**Spec rules:** plain top-level `test()`, no mocks, spies, `.each` or hooks; helpers inside the spec;
+assertions on public API or on what reaches the device. Each step's spec is run red against the code before
+the step.
+
+| # | step | spec (tier) | the red it catches |
+|---|---|---|---|
+| 1 | 16-bit count fields | `chunk_light_cluster_counts.spec.js` (tier 2, emulator): pack/unpack round-trips every `(p, s)` on a grid up to 16,383 each, the cull limit; point and spot never alias | today's 8-bit helpers fail at 256 |
+| 2 | lift `chunk_cluster_cell` (no behaviour change: the bench's tests are A0fix's semantics) | `chunk_cluster_cell.spec.js` (tier 2), against geometry: a sphere strictly beyond one cell plane (distance > r) is rejected; a sphere containing a cell corner is accepted; a point light whose centre is inside the cell is accepted; for the last slice, a spot whose cone's bounding sphere is outside the XY planes is rejected and one crossing them is accepted | today's shipped spot test accepts every last-slice spot |
+| 3 | lift `chunk_cluster_light_proxy` | `chunk_cluster_light_proxy.spec.js` (tier 2): for seeded point and spot lights, sampled points of the influence sphere project into cells inside the packed box (conservative); the box exceeds the sampled cells by at most one tile per side (tight); box volume equals the product of extents | a box from the centre only, or off by one at the screen edge |
+| 4 | passes 1–3 (mark, compact, prepare) | tier 1 `*.wgsl_validity.spec.js` per shader; tier 2 for mark and for prepare's per-light outputs (each invocation independent); **compaction and the bound's workgroup reduction on tier 4** (headless Chrome verify function: shuffled cull list in, list sorted by (type, id) out, bound = Σ box volumes) | an unsorted output; a bound that misses a workgroup |
+| 5 | passes 4–5 (coarse) | tier 2: per light, every cell of its box lies in a block whose mask has its bit; no block outside the box's blocks has it | a scatter that drops the box's last block row |
+| 6 | pass 6 + graph wiring; delete the private array, keep-smallest and the local limit | **tier 3** (`SoftwareGPUDevice`, real `graph_assign_clsuters`): 6 dispatches in one pass, in order, with direct workgroup counts from the CPU-known light count and the grid; `cluster_data` size = `compute_buffer_size(LightClusterEntries) + 4`; the bound recorded into the limits' stat buffer. **Tier 4:** per-cell sets equal a brute-force reference that runs the step-2 chunks over every (cell, light) pair on the emulator (the oracle is the pinned chunks, not a second copy of the arithmetic), at 0 / 16 / 1,024 lights; no cell loses a light; counts above 255 in a dense scene | today's shader caps at 128 and drops lights; the old graph has 1 dispatch |
+| 7 | sizing through `GPUCollectionLimits` | tier 3: a frame whose recorded bound exceeds the column's limit grows `compute_buffer_size(LightClusterEntries)` on the following frame (the `GPUCollectionLimits.spec.js` pattern); the first frame at a new resolution primes from `estimate_cluster_data_limit` | a buffer that stays at the estimate |
+| 8 | consumer budgets, one consumer at a time, by its owner | per consumer, tier 2 on the lifted loop chunk: a cell list longer than the budget evaluates exactly `budget` entries and drops the tail; shorter lists are unaffected | the loop is unbounded today |
+
+**Landing note.** Steps 1–3 are no-behaviour-change commits. Step 6 is the switch. Steps 7–8 can land after
+6, but 7 must land before scenes rely on dense clusters, since without it the buffer stays at the estimate.
+
+### III.3 Reuse map (final)
+
+| piece | existing machinery reused |
+|---|---|
+| culled input | `graph_cull_lights` output, unchanged |
+| sorted list | ordered compaction; one workgroup suffices at the cull limit. `graph_prefix_scan_csdldf` is the general scan if the cull limit ever rises |
+| light records | `LIGHT_DATABASE_SPEC` marshalling reads, once per light instead of once per (cell, light) |
+| proxy | `chunk_point_light_to_aabb3` / `chunk_spot_light_to_aabb3` semantics, `chunk_cone_to_bounding_box`, `chunk_cluster_depth_to_z_slice`; `chunk_sphere_screen_extents` (exists, one caller, written for +z forward: the proxy uses the −z form) |
+| cell and tests | `chunk_cluster_depth_from_z_slice`; `chunk_sphere_intersects_frustum` semantics; `chunk_cone_intersects_sphere` verbatim |
+| compaction and allocation | the A2/G subgroup scan; `chunk_vsm_append_mover`'s subgroup-aggregated allocation |
+| sizing | `GPUCollectionLimits` + `graph_record_stat` |
+| validity / emulator / software device / playground | the four testing tiers |
+
+**Duplication removed:** the per-pair corner rebuild, the per-pair record re-read, the private array, and
+`chunk_cluster_keep_smallest`.
+
+### III.4 What breaks
+
+| what | impact |
+|---|---|
+| the 8-bit count readers | every consumer reads the counts through `chunk_light_cluster_counts`, so step 1 covers them all (grep-verified: no other masks) |
+| `LIGHT_CLUSTER_LOCAL_LIGHT_LIMIT` | no longer drives `estimate_cluster_data_limit` |
+| order of lights within a cell | changes from the cull's atomic order (non-deterministic) to the I.6 order (deterministic). Lighting sums change in the last bits; a pixel-exact golden image would need re-baselining |
+| crowded cells | in scenes with crowded cells, lights the cap dropped now shade, and consumer cost rises until the budgets (step 8) land |
+
+### III.5 CPU-side cost
+
+Six dispatches in one compute pass replace one. At the frame-anatomy report's measured ≈ 4 kcyc per extra
+dispatch in an open pass, that is ≈ 20 kcyc of Chrome's GPU-process thread per frame. This is
+**predicted**: the price is measured, the count is from this design. No indirect dispatch.
+
+### III.6 Follow-up, out of scope: the decal builder
+
+`engine/graphics3/decal/shader_cluster_assign_decals.js` has today's shape: a sorted 32-entry private
+array, keep-largest by record index (priority).
+
+It can take the same prepass → coarse → fine structure, but its composite **depends on priority order**.
+So it needs an order-preserving compaction, either:
+
+- the 1D-workgroup variant (measured ordered, fast; Appendix R3.1), or
+- the LDS-ranked one (spec-proof);
+
+not F7's lane order. It also needs its own decision on whether a cap stays. Not planned here.
+
+---
+
+## Part IV — As landed
+
+### IV.1 Commits
+
+| step | commit | |
+|---|---|---|
+| plan | `a33e8a355` | this document and PROPOSAL_ALGORITHM |
+| 1 | `7cccdc28a` | counts 16 bits per type |
+| 2 | `cce95c4d7` | `chunk_cluster_cell` |
+| 3 | `db5fac70c` | `chunk_cluster_light_proxy` |
+| 4 | `0281b8eb1` | mark, compact, prepare |
+| 5 | `b0291ed5a` | coarse clear and scatter |
+| 6 | `c6b17e747` | the fine pass and the graph: the switch |
+| 7 | `83cedf8d9` | `cluster_data` sized from the bound through `GPUCollectionLimits` |
+| fix | `5fcb1201c` | dispatches sized by the tables' live lights, not their slots |
+| 8 | `94665ac11` | consumer budgets |
+| fix | `96f0fdf31` | the coarse clear one thread per mask word |
+
+### IV.2 What differs from Parts I–III
+
+- **Compact** works in rounds of 16,384 table slots, since ids are slots and a table can hold more than the
+  cull list. It scans in workgroup memory in thread order, so the list is sorted by construction, not by the
+  subgroup lane mapping. The visibility bitmask is a FrameGraph transient the graph clears; compact reads it
+  through a plain read-only view. Nothing self-clears.
+- **The bound saturates** at 2^32 − 1 rather than wrapping (measured: 1,000 whole-grid lights on a 16,384²
+  grid).
+- **Six dispatches in one pass** needed `ComputeShader.dispatchInPass` and
+  `ShadeGPUCommandContext.bindComputePipeline`.
+- **Dispatch sizes** come from the tables' live counts (`GPUTypedTable.count`), capped at the cull list's
+  16,383. The coarse clear is one thread per mask word, folded into rows of 1,024 workgroups. Both were
+  measured regressions in the first landing (IV.3).
+- **Priming:** the `LightClusterEntries` column is primed with 64.5 entries a cell whenever a grid needs
+  more than it holds, so it never drops below today's size.
+- **Budgets (I.5),** chosen in tens: deferred 64, AVBOIT draw 32, MBOIT resolve 32, fog irradiance 32, fog
+  in-scatter 16, per type. The shared chunk takes the two budgets as parameters, and each including shader
+  passes its own. Water does not walk the clusters. Of the "five passes", three include the chunk:
+  deferred, AVBOIT draw and MBOIT resolve.
+
+### IV.3 Measured after landing
+
+The assignment, p10 µs, paired in one process with A0 (the shader before step 6) and Part II's arm, mirrored:
+
+| | 4090 A0 | 4090 landed | ×A0 | iGPU A0 | iGPU landed | ×A0 |
+|---|---:|---:|---:|---:|---:|---:|
+| 640×360, 0 | 4.1 | 2.0 | 2.0 | 104.6 | 3.7 | 28 |
+| 640×360, 16 | 10.2 | 11.3 | 0.9 | 123.4 | 14.2 | 8.7 |
+| 640×360, 1,024 | 486.4 | 78.8 | 6.2 | 8,109.8 | 122.2 | 66 |
+| 640×360, 4,096 | 2,146.3 | 318.5 | 6.7 | 36,172.5 | 511.2 | 71 |
+| 1898×982, 0 | 32.8 | 2.0 | 16 | 913.6 | 20.7 | 44 |
+| 1898×982, 16 | 39.9 | 11.3 | 3.5 | 953.2 | 62.4 | 15 |
+| 1898×982, 1,024 | 729.1 | 59.4 | 12 | 60,656.2 | 461.0 | 132 |
+| 1898×982, 4,096 | 3,164.2 | 225.3 | 14 | 271,849.6 | 2,019.4 | 135 |
+| 3840×2160, 0 | 208.9 | 4.1 | 51 | 3,519.3 | 80.4 | 44 |
+| 3840×2160, 16 | 218.1 | 12.3 | 18 | 3,698.0 | 230.6 | 16 |
+| 3840×2160, 1,024 | 2,325.5 | 60.4 | 39 | 254,395.6 | 1,650.1 | 154 |
+| 3840×2160, 4,096 | 10,632.1 | 242.1 | 44 | not run ¹ | 7,564.2 | — |
+
+¹ A0 there takes about a second a pass on the iGPU. Part II did not run it either.
+
+The landed code against Part II's arm in the same runs: 0.94–1.00 on the 4090 and 0.97–1.00 on the iGPU
+wherever there are lights, and 0.29–1.00 with none (it skips the passes the arm ran).
+
+Per-cell lists, tier 4, both GPUs, checked against `chunk_cluster_cell` on the emulator: every cell equal at
+0, 16 and 1,024 lights (1898×982) and in the dense 1,200-light scene (cells up to 694 points / 460 spots).
+At 3840×2160 with 4,096 lights, one cell of 195,840 lacks a spot the oracle keeps. Its cap plane touches
+the cell's bounding sphere within 6.2e-7 m at 20 m, below f32 resolution.
+
+A playground (tonemap_sdr scene 1 with 300 bounded points and 100 spots added, camera frozen, TAA and SSAO
+off): the landed build is bit-identical run to run. Against the build before step 6 it differs in 2–6 of
+1.34 M channels by one code; that build differs from itself by 4.
+
+# Appendix A — the round-2 and round-3 record
+
+Superseded wherever it conflicts with Parts I–III.
+
+## A.0 Round 2: hierarchical, linked list, small-set path
+
+(Round 2 status.) Proposal only, nothing built for landing. This round implements what Alex picked out of the two
+first-round proposals (`PROPOSAL_ALGORITHM_2026_10_16.md`, `PROPOSAL_STRUCTURE_2026_10_16.md`): a hierarchy
+that bins in 2D first and then walks the slices, a linked-list output instead of per-thread arrays, and a
+small-set path. The fused-cull idea and the 64 px tile tweak are dropped.
+
+## R3. Round 3: decided — G, count-then-write, no per-cell cap (added 2026-10-16)
+
+Alex pinned **G** (F4) and settled **F1**: count-then-write into today's product, **with the per-cell cap
+removed** and `LIGHT_CLUSTER_METADATA.counts` widened to **16 bits per type** (point in bits 0–15, spot in
+bits 16–31). The sections after this one are the round-2 record. Where they talk about the cap,
+keep-smallest or the 8-bit fields, this section supersedes them. All of this is still a proposal: nothing is
+built for landing.
+
+The coarse path used is **mask always** (F2's recommendation): light-scatter coarse masks at every light
+count.
+
+### R3.1 The arm: "G ctw uncapped"
+
+1. Prepass, as before: id-sorted (F3).
+2. Coarse clear + light scatter.
+3. Fine pass:
+   - **Sweep 1** counts every hit per type. **No cap.**
+   - **One allocation** covers the exact total: one subgroup-aggregated `atomicAdd` per subgroup, skipped
+     when the subgroup's total is 0.
+   - **Sweep 2** writes all of them: points, then spots, ascending id.
+   - Metadata `{counts: point | spot << 16, offset}`.
+
+keep-smallest is gone: no cell drops lights unless the global pool overflows (R3.4).
+
+**Per-thread loop budgets:**
+
+| loop | budget | past it |
+|---|---|---|
+| prepass compaction | 64 bits | — |
+| coarse scatter | coarse blocks / 64; ≤ 48 at 4K | — |
+| fine sweeps | ≤ W/2 word pairs × ≤ 64 survivors per pair; W ≤ 512 at the cull limit, so ≤ 256 pairs | nothing is dropped: the cull limit bounds W |
+
+**Ordering finding, and the fix.** The 4×4×4 workgroup's `subgroup_invocation_id` is not in
+`local_invocation_index` order on this hardware. Subgroups are index/32, but the lanes are permuted inside
+one. So the subgroup-scan compaction inherited from A2 left each cell's list deterministic but *not
+ascending* inside 32-light windows, on both GPUs.
+
+That also explains round 1's "borderline light flips between compiled variants" (and the one A2 ≠ G cell at
+640×360 × 4,096 in §1): it was this permutation picking a different 128th light at the cap, not codegen.
+Capped A2 therefore keeps a near-smallest set, not the smallest, where the cap binds.
+
+The fix measured below runs the fine pass as a **1D 64-thread workgroup**, with the cell decoded from the
+index (x = i & 3, y = (i >> 2) & 3, z = i >> 4). Lanes then follow the index on both GPUs, and the lists
+come out ascending, with 0 violations in every configuration.
+
+- WGSL does not promise this lane order.
+- The spec-proof alternative ranks survivors through a 64-bit keep mask in workgroup memory ("ranked 3D"
+  below). It costs the iGPU +16–38%. (My offline `vkstats.py` route failed to compile it on
+  the AMD driver: a tooling result, not a statement about what ships.)
+
+**Registers.** Uncapped G (1D) is identical to capped:
+
+| | regs | local mem | shared mem | occupancy | scratch |
+|---|---:|---:|---:|---:|---:|
+| NVIDIA | 48 | 0 | 1,296 B | 83% | — |
+| AMD | 42 VGPR / 76 SGPR | — | 1 KiB LDS | — | 0 |
+
+The 16-bit consumer stand-in compiles to the same 32 regs / 21 VGPR as the 8-bit one.
+
+**Correctness.** At every configuration below:
+
+- uncapped ⊇ capped;
+- uncapped = capped wherever the cap did not bind;
+- capped G = A2, except the permutation cell;
+- lists ascending.
+
+### R3.2 Measured: capped vs uncapped (same scene as §2; p10, mirrored minimum)
+
+| config | 4090 capped | 4090 uncapped | 4090 uncapped, ranked 3D | iGPU capped | iGPU uncapped | iGPU uncapped, ranked 3D | words capped | words uncapped | worst cell, capped (pt/sp) | worst cell, uncapped (pt/sp) |
+|---|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|
+| 640×360, 0 | 6.1 | 6.6 | 6.1 | 5.4 | 5.5 | 5.7 | 0 | 0 | 0/0 | 0/0 |
+| 640×360, 16 | 11.3 | 11.3 | 11.3 | 13.4 | 13.4 | 13.8 | 155 | 155 | 2/1 | 2/1 |
+| 640×360, 1,024 | 85.0 | 84.0 | 76.8 | 123.5 | 121.6 | 145.0 | 29,096 | 29,096 | 37/22 | 37/22 |
+| 640×360, 4,096 | 337.9 | 333.8 | 306.2 | 539.0 | 518.4 | 600.6 | 118,708 | 118,905 | 128/81 | 143/81 |
+| 1898×982, 0 | 7.2 | 7.2 | 7.2 | 21.7 | 21.7 | 23.7 | 0 | 0 | 0/0 | 0/0 |
+| 1898×982, 16 | 11.3 | 11.3 | 11.3 | 60.4 | 60.2 | 61.9 | 717 | 717 | 2/1 | 2/1 |
+| 1898×982, 1,024 | 62.5 | 62.5 | 58.4 | 485.4 | 473.8 | 644.8 | 184,933 | 184,933 | 33/20 | 33/20 |
+| 1898×982, 4,096 | 241.7 | 238.6 | 223.2 | 2.15 ms | 2.09 ms | 2.72 ms | 761,323 | 761,323 | 125/72 | 125/72 |
+| 4K, 0 | 8.2 | 8.2 | 8.2 | 77.2 | 77.1 | 86.4 | 0 | 0 | 0/0 | 0/0 |
+| 4K, 16 | 11.3 | 11.3 | 11.3 | 225.2 | 225.2 | 232.1 | 2,854 | 2,854 | 2/1 | 2/1 |
+| 4K, 1,024 | 62.5 | 61.4 | 63.1 | 1.75 ms | 1.71 ms | 2.35 ms | 818,675 | 818,675 | 35/21 | 35/21 |
+| 4K, 4,096 | 255.0 | 251.9 | 252.9 | 8.10 ms | 7.82 ms | 10.34 ms | 3,356,922 | 3,356,945 | 128/75 | 132/75 |
+
+**Consumer stand-in, capped vs uncapped (p10):**
+
+| config | 4090 capped | 4090 uncapped | iGPU capped | iGPU uncapped |
+|---|---:|---:|---:|---:|
+| 640×360, 1,024 | 14.3 | 14.3 | 785 | 785 |
+| 640×360, 4,096 | 45.1 | 44.0 | 2.94 ms | 2.94 ms |
+| 1898×982, 1,024 | 61.4 | 61.4 | 5.18 ms | 5.18 ms |
+| 1898×982, 4,096 | 198.7 | 197.6 | 19.02 ms | 19.02 ms |
+| 4K, 1,024 | 256.0 | 253.9 | 23.02 ms | 23.02 ms |
+| 4K, 4,096 | 833.5 | 829.4 | 84.67 ms | 84.70 ms |
+
+At 0 and 16 lights they are identical. **In this scene removing the cap costs nothing**: the cap binds in a
+handful of cells, and the uncapped arm is 0–4% faster because it drops the cap compares.
+
+**A dense stress scene, to make the cap bind.** 4,096 lights (2,048 point + 2,048 spot) with a 10–30 m
+range, packed into 2–40 m of depth. The uncapped pool is sized to its demand (6× today's) so that nothing
+is truncated (p10):
+
+| | 4090 640×360 | 4090 1898×982 | 4090 4K | iGPU 640×360 | iGPU 1898×982 |
+|---|---:|---:|---:|---:|---:|
+| assignment, capped | 1.36 ms | 1.19 ms | 1.26 ms | 1.80 ms | 10.0 ms |
+| assignment, uncapped | 2.25 ms | 2.05 ms | 2.72 ms | 3.17 ms | 21.4 ms |
+| consumer, capped | 93 µs | 564 µs | 2.43 ms | 7.15 ms | 58.6 ms |
+| consumer, uncapped | 630 µs | 3.52 ms | 17.8 ms | 50.1 ms | 379 ms |
+| cells over 128 of one type (uncapped) | 1,440 of 5,760 | 11,160 of 44,640 | 48,960 of 195,840 | 1,440 | 11,160 |
+| worst cell, uncapped (pt/sp) | 1,821/767 | 1,755/708 | 1,791/734 | 1,821/767 | 1,755/708 |
+| `cluster_data` words, capped / uncapped | 0.33 M / 2.03 M | 2.52 M / 15.07 M | 11.08 M / 67.65 M | same | same |
+
+**Reading it.** Where the cap binds, removing it makes the assignment 1.6–2.2× slower. The consumer gets
+6.2–7.3× slower, because its per-pixel loop grows with the cell. In exchange, it shades exactly the lights
+that reach the pixel instead of the 128 smallest ids. Today 25% of the cells at 1898×982 lose lights in this
+scene.
+
+### R3.3 Demand against today's capacity
+
+`estimate_cluster_data_limit` sizes `cluster_data` at max(⌈C/2⌉ · 128 + ⌊C/2⌋, 64 · C) ≈ **64.5 words per
+cell**. Today's assign shader truncates at that capacity, and that sizing rule is the
+`LIGHT_CLUSTER_LOCAL_LIGHT_LIMIT` cap in disguise.
+
+| 4,096 lights | cells | capacity (words) | uncapped demand | demand / capacity |
+|---|---:|---:|---:|---:|
+| 640×360, §2 scene | 5,760 | 371,520 | 118,905 | 32.0% |
+| 1898×982, §2 scene | 44,640 | 2,879,280 | 761,323 | 26.4% |
+| 4K, §2 scene | 195,840 | 12,631,680 | 3,356,945 | 26.6% |
+| 640×360, dense | 5,760 | 371,520 | 2,033,294 | **547%** |
+| 1898×982, dense | 44,640 | 2,879,280 | 15,069,093 | **523%** |
+| 4K, dense | 195,840 | 12,631,680 | 67,654,718 | **536%** (271 MB) |
+
+There is no cap-derived upper bound any more. The worst case is cells × the cull limit (16,383) words.
+
+### R3.4 Pool overflow (measured)
+
+**Mechanism.** The fine pass allocates one block per subgroup, in whatever order the subgroups reach the
+atomic.
+
+- When the counter passes capacity, a subgroup's cells get `min(count, what is left)`: points first, then
+  spots, ascending.
+- Later subgroups get 0.
+- **Which cells lose lights is not deterministic.**
+
+**Measured.** Uncapped G at 1898×982 × 4,096 lights, with the pool forced to half its demand (380,661 of
+761,323 words), run 4 times:
+
+- every run wrote exactly the capacity;
+- the set of truncated cells differed between runs in **71, 71 and 149 cells** (against run 0).
+
+**Covering it.**
+
+1. **Sizing feedback (reuse):** `GPUCollectionLimits` (`rasterize/expand/GPUCollectionLimits.js`) already
+   reads back per-collection demand counters a frame late and grows the buffers; `cluster_data` becomes
+   one more collection there. (Decided in Part I: the counter is the coarse cell-box bound.) A frame that
+   overflows loses lights non-deterministically in the cells above; the next frame is sized to fit.
+2. **Initial size:** keep `estimate_cluster_data_limit`'s 64.5 words per cell as the starting point and
+   let the feedback grow it. It is no longer tied to a cap.
+3. **Deterministic overflow (option, unmeasured):** allocate by a prefix scan over per-cell counts in
+   cell order (`graph_prefix_scan_csdldf`) instead of the subgroup atomic. Overflow would then truncate the
+   highest cell indices, the same ones every frame. It costs a count pass, a scan, and the write pass. That
+   is fork F6.
+
+### R3.5 Consumer loop budget (fork F5 — facts, no number)
+
+With no per-cell cap, a consumer's light loop is bounded only by the cull list (16,383 lights).
+
+**Today it is bounded by the cap:** 128 per type written, but the field allows 255.
+
+**The loops:**
+
+| consumer | where | loop over | bound today |
+|---|---|---|---|
+| deferred direct shading | `deferred/chunk_shade_standard_material_direct.js:66` (points), `:87` (spots) | the cell's point / spot list | count field |
+| forward / OIT resolve / AVBOIT draw / water | the same chunk, via `rasterize/forward/chunk_forward_shade_standard_fragment.js`, `rasterize/native/oit/oit_resolve_fragment_body.js`, `rasterize/native/avboit/avboit_draw_fragment_body.js` (water's `shader_water_avboit.js` uses the AVBOIT body) | same | count field |
+| volumetrics irradiance | `volumetrics/shader_volumetrics_build_irradiance.js:154`, `:167` | the froxel cell's points / spots | count field |
+| volumetrics lighting | `volumetrics/shader_volumetrics_build_lighting.js:312`, `:353` | same | count field |
+| ReSTIR DI candidates | `restir/di/chunk_restir_generate_candidates.js:61` | `m_initial` candidates, sampling uniformly over `count` | its own `m_initial` (unchanged) |
+
+**The measured cost of a long list** is in R3.2's dense table: the consumer grew 6–7× when the worst cell
+went from 128 to ~1,800 lights.
+
+**The question for Alex (F5).** Does each of these loops get its own budget? A budget means a constant per
+consumer and a doc line on what is dropped past it: with ascending ids, the highest ids in the cell,
+deterministically.
+
+The alternatives are to leave them bounded only by the cull limit, or to use ReSTIR-style sampling as the
+budgeted path for crowded cells. No number is proposed here.
+
+### R3.6 What breaks with 16-bit count fields, and what goes away
+
+**Changes:**
+
+| file | change |
+|---|---|
+| `light/cluster/chunk_light_cluster_counts.js` | `light_cluster_count_point` → `counts & 0xFFFFu`; `light_cluster_count_spot` → `counts >> 16u`; `light_cluster_pack_counts` → `(p & 0xFFFFu) \| (s << 16u)`. Every consumer goes through these helpers, so no consumer source changes: `chunk_shade_standard_material_direct.js:63–64`, `chunk_restir_generate_candidates.js:50–51`, `shader_volumetrics_build_irradiance.js:151–152`, `shader_volumetrics_build_lighting.js:309–310`. Verified by grep: no other reader masks the field. |
+| `LIGHT_CLUSTER_PER_TYPE_MAX` (same file) | 255 → 65,535. Grep finds no other user. 16 bits cannot saturate: the cull list holds ≤ 16,383 lights. |
+| `light/cluster/LIGHT_CLUSTER_METADATA.js` | doc comment: bits [0:15] point, [16:31] spot. The reserved bits "decals, other future light types" are gone. Decals have their own `DECAL_CLUSTER_METADATA`. |
+| `light/cluster/graph_assign_clsuters.js` | `estimate_cluster_data_limit` no longer derives from `LIGHT_CLUSTER_LOCAL_LIGHT_LIMIT` (R3.3), and the buffer joins `GPUCollectionLimits`. |
+
+**Goes away:**
+
+- `LIGHT_CLUSTER_LOCAL_LIGHT_LIMIT.js`;
+- `chunk_cluster_keep_smallest.js` and its spec;
+- the private `local_lights` array, and today's `shader_cluster_assign_lights.js`, replaced by G's passes.
+
+**Unchanged:**
+
+- the consumer contract (offset + points then spots);
+- the grid;
+- the cull pass;
+- the unbounded last slice.
+
+**Reuse map additions:**
+
+- sizing: `GPUCollectionLimits`;
+- the deterministic-overflow option: `graph_prefix_scan_csdldf`;
+- everything else: §5's map.
+
+### R3.7 Forks still open
+
+- **F2:** mask always (recommended) vs the 1,024 switch.
+- **F3:** sort (recommended).
+- **F5:** consumer loop budgets (R3.5).
+- **F6:** overflow allocation:
+  - subgroup atomic + grow-on-feedback: measured, non-deterministic on the overflowing frame — recommended,
+    because overflow is a sizing transient once the feedback is in;
+  - cell-ordered scan: deterministic truncation, one more pass, unmeasured.
+- **F7:** lane order:
+  - 1D 64-thread fine pass: measured ascending on both GPUs, fast — recommended, with the spec caveat
+    stated;
+  - LDS-ranked 3D: spec-proof, +16–38% on the iGPU.
+
+**Constraints kept:**
+
+- The grid stays 32 px × 24 slices.
+- The input is the cull's atomic-appended `(id, type)` list and its count, exactly as today. Nothing moves
+  into `graph_cull_lights`.
+- The last slice stays unbounded: [`depth_from_slice(23)`, ∞). The precise tests handle an unbounded cell
+  in XY only, the `A0fix` way. The first round's "defect" wording is withdrawn: the unbounded slice is
+  intentional, and only the spot test needs that treatment there.
+- Every cell of the 32 px × 24 grid is served, empty space included. No stage reads depth or the HZB to
+  skip cells: clusters are the 3D structure, and that generality is why they were chosen.
+- (Round 2) The per-type cap stays today's (`LIGHT_CLUSTER_LOCAL_LIGHT_LIMIT`, keep-smallest). Its value
+  is not derived from anything here. **Superseded by R3: no per-cell cap.**
+
+**Measurement method.** Every number is **measured**: paired in one process, every arm in its own
+timestamped pass, the order alternating per iteration, behind a ballast pass.
+
+| | RTX 4090 | AMD Radeon iGPU (RDNA2, 2 CUs, `--use-adapter-luid=0,120673`) |
+|---|---|---|
+| iterations | 300 | 20 |
+| per-iteration value | **minimum of two mirrored runs** (A..Z then Z..A) | **minimum of two mirrored runs** |
+| reported statistic | p10 | p10 |
+| foreign GPU load | 1% at the start of the final run | none (no other client) |
+
+4090 numbers are relative on that device. The scene, the shipped WGSL, the real `GPUDatabase` and the
+engine camera are as in round 1, §6.
+
+## 0. Summary
+
+1. **2D first, then slices, as specified (H), loses at 4K and on the modest GPU, and wins on the 4090 at
+   ≤1898×982.**
+   - 4090, 1,024 lights: 36 µs at 1898×982 vs A2's 56 µs, but 102 µs at 4K vs 57.
+   - iGPU: 1.43 ms vs 0.62 ms (1898×982), and 6.1 ms vs 2.4 ms (4K).
+   - **Why:** each tile walks its survivors serially, so the work is O(Σ tile–light pairs), which grows with
+     the pixel count. Only the 1–4 lanes inside a survivor's slice range do work. Packing 4 tiles per
+     workgroup (100% occupancy instead of 50%) gains ≤ 12%.
+2. **The hierarchy that wins on both GPUs is coarse-to-fine with a 3D coarse unit: "G".** G is A2's shape:
+   - **coarse unit:** a 4×4×4 cell block, which is one workgroup;
+   - **small set:** the coarse cull is an in-workgroup box test per light;
+   - **scalable path:** each light marks the blocks it covers in a per-block bitmask, one workgroup per
+     light, no gather;
+   - **fine stage:** every cell runs the precise test on its block's survivors, in id order.
+3. **Linked list against count-then-write, same hierarchy (G):**
+   - **assignment:** the list's single sweep is 20–31% faster on the 4090 and 25–31% on the iGPU.
+   - **compaction into today's product** (UE's `LightGridCompactCS` shape) costs 9–125 µs on the 4090 and
+     0.4–15 ms on the iGPU.
+   - **consumers walking the list directly** pay +8–30% per consumer pass on the 4090 and +6–27% on the
+     iGPU (stand-in shading pass).
+   - **Net:** on the iGPU count-then-write wins against both list options for any consumer count ≥ 1. On the
+     4090 the list wins only with 1–2 consumers.
+   - **Fork F1; recommendation: count-then-write into today's product.** It has no per-thread arrays
+     either: counts live in registers and survivors in workgroup memory.
+4. **The small-set threshold: derived 1,024, measured crossover device-specific.**
+   - **Derivation:** 32 lanes × 32 bits. 32 is the minimum subgroup width both adapters report, and it is
+     also 24 slices rounded up to the next power of two.
+   - **Measured crossover between the in-workgroup box test and the light-scatter mask:**
+     - 4090: the box path wins up to 1,024 lights (by 3–9 µs) and ties at 4,096.
+     - iGPU: the mask path wins at **every** count at 1898×982 and 4K (−17% at 16 lights, −31% at 4K with
+       1,024).
+   - **Fork F2; recommendation: one path, the mask, everywhere.**
+5. **Recommended: G**, run as:
+   - id-sorting prepass (3 small direct dispatches);
+   - light-scatter coarse mask (2 direct dispatches);
+   - fine pass, count-then-write into today's `{counts, offset}` (1 direct dispatch).
+
+   No indirect dispatch.
+
+   | lights | 4090 | iGPU |
+   |---:|---:|---:|
+   | 0 | 4–6 µs | 5–81 µs |
+   | 1,024 | 62–85 µs | 0.12–1.74 ms |
+   | 4,096 | 240–340 µs | 0.53–8.1 ms |
+   | **today, 1,024** | **0.49–2.5 ms** | **8.1–256 ms** |
+
+## 1. What was built
+
+All arms produce **identical per-cell sets to A2** at 1898×982 × {0, 16, 1,024, 4,096} lights, 640×360 ×
+4,096 and 4K × 4,096. That includes cells at the cap of 128, where keep-smallest decides. One cell at
+640×360 with 4,096 lights differs at the cap; R3.1 traces that to subgroup lane order in the A2-shaped
+compaction, not codegen. Walking a list gives the same sets as compacting it. The two consumer read paths agree to within
+summation order (≤ 3e-6).
+
+### 1.1 Prepass (owned by the assignment; what it buys)
+
+| variant | dispatches | what it does | cost (4090 / iGPU) |
+|---|---|---|---|
+| **unsorted** (the cull's own order) | 1 | per culled entry: one database read, a view-space record, a packed tile rect + slice range | 1–3 µs / 8–27 µs |
+| **id-sorted** | 3 | per-type visibility bits (mark), one-workgroup ordered compaction, then the same records in (type, id) order | +2–4 µs / +3–25 µs over unsorted |
+
+**What sorting buys:**
+
+- keep-smallest falls out as "the first CAP hits per type";
+- the order within a cell is deterministic (today the order follows the cull's `atomicAdd`);
+- types are grouped, so there are fewer divergent branches.
+
+Without sorting, keep-smallest is still exact (§3.3) but costs a walk on overflow, and the order stays the
+cull's. Measured on the 4090: sorted H vs unsorted H is +5 µs at ≤1,024 lights and −72 µs at 640×360 with
+4,096 (163 vs 235 µs). That is fork F3.
+
+**One workgroup for the compaction suffices** because 256 threads × 64 bits covers 16,384 lights, which is
+the cull list's own limit (16,383).
+
+### 1.2 H: 2D tiles first, then the 24 slices (as specified)
+
+**Stage 1, tile bitmask over the light list:**
+
+- **Small set (L ≤ 1,024, read on the device):** inside the stage-2 workgroup, lane *w* tests lights
+  32w…32w+31 against its tile. The tile's whole mask is one register per lane. There is no mask in memory
+  and no extra pass.
+- **Above 1,024:** a separate gather pass in the structural session's BT form. One thread per (tile, word)
+  runs 32 rect tests and writes the whole word, with no atomics. Its dispatch is only encoded when the
+  CPU-known light count exceeds 1,024. Its threads leave when the device count says the small path runs.
+
+**Stage 2:** one 32-thread workgroup per tile, lane *z* owns cell (tile, z).
+
+1. Per chunk of 32 words, the tile reserves **one pool block** (one global atomic per tile and chunk). Its
+   size is the sum of the survivors' slice extents.
+2. All lanes walk the survivors in list order.
+3. A lane whose cell passes the precise test links a node at block + survivor prefix + (z − z0), and
+   prepends it to its own per-type head.
+
+No head atomics are needed, because one lane owns one cell. About 5% of reserved nodes end up as holes (a
+cell in the slice range that fails the precise test).
+
+**H2 (variant):** survivors are listed in workgroup memory; the lanes precise-test them in parallel into a
+24-bit slice mask each; then lane *z* walks the masks. Allocation is exact.
+
+**O():**
+
+| stage | cost |
+|---|---|
+| stage 1 | O(tiles × L) rect tests, 32 per thread |
+| stage 2 | O(Σ over tiles of survivors) serial walk steps per tile + O(hits) node writes |
+| zero lights | O(cells) head writes (8 + 4 B/cell) + one prepass dispatch |
+
+### 1.3 G: the coarse unit is a 3D block (A2's shape), small set and scalable path
+
+**Coarse unit:** the 4×4×4 workgroup.
+
+**Small set (L ≤ 1,024):** per chunk of 64 lights, thread *i* box-tests light *i* against the block. The
+survivors are compacted in order into workgroup memory (subgroup exclusive add plus per-subgroup offsets).
+The per-chunk survivor bits are the block's mask held two words at a time in the lanes, and never written.
+
+**Scalable path:**
+
+1. One workgroup per light (direct dispatch over the CPU-known count) ORs the light's bit into every block
+   its cell box covers. That is light-centric, O(Σ blocks per light).
+2. The block masks are cleared first: O(blocks × W).
+3. The fine pass reads its block's words two at a time and skips empty pairs with one uniform load.
+
+The round-1 bench called this coarse-mask scatter "A3". A gather-built coarse mask (BT at block level) was
+measured and **rejected**: it repeats exactly the O(blocks × L) box tests the small path does. On the iGPU
+that is 0.99 ms at 1898×982 and 4.3 ms at 4K with 4,096 lights.
+
+**Fine stage, per cell, over its block's survivors:** box test, then the precise test (A2's tightness:
+6-plane sphere, cone vs the cell's bounding sphere, unbounded last slice in XY only).
+
+- **Count-then-write (`G ctw`):** sweep 1 counts per type, capped. One subgroup-aggregated allocation,
+  then sweep 2 writes today's `{counts, offset}` + list. Points come before spots and the order is
+  ascending id.
+- **Linked list (`G list`):** one sweep. One pool reservation per block and chunk, sized by the survivors'
+  box ∩ block cell counts. Each survivor owns a sub-block at an in-order prefix, so the node is
+  base + prefix + the cell's index inside the survivor's box.
+
+**O():**
+
+| stage | small set | scalable path |
+|---|---|---|
+| coarse | O(blocks × L) box tests, in-workgroup, L/64 chunks per thread | O(Σ blocks per light) `atomicOr` + O(blocks × W) clear |
+| fine | O(cells × survivors per block) precise tests + O(hits) writes | same; ×2 sweeps for count-then-write |
+| zero lights | O(cells) metadata write + prepass dispatches | same |
+
+## 2. Measured
+
+### 2.1 Assignment (p10)
+
+**RTX 4090:**
+
+| config | A0 today | A2 | H | H + compaction | G ctw (1,024 switch) | G ctw (mask always) | G list | G list (mask always) | G list + compaction | floor |
+|---|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|
+| 640×360, 0 | 3.1 | 4.1 | 2.0 | 4.1 | 4.1 | — | 4.1 | — | 6.1 | 1.0 |
+| 640×360, 16 | 11.3 | 9.2 | 7.2 | 9.2 | 9.2 | 12.3 | 8.2 | 11.3 | 9.9 | 1.0 |
+| 640×360, 1,024 | 489.5 | 74.8 | 43.0 | 53.3 | 74.8 | 85.0 | 59.4 | 62.5 | 68.6 | 1.0 |
+| 640×360, 4,096 | 2.16 ms | 303.1 | 235.5 | 269.3 | 329.7 | 340.0 | 229.4 | 227.3 | 261.1 | 1.0 |
+| 1898×982, 0 | 32.8 | 5.1 | 4.1 | 6.1 | 5.1 | — | 5.1 | — | 6.1 | 1.0 |
+| 1898×982, 16 | 41.0 | 8.2 | 8.2 | 10.2 | 8.2 | 11.3 | 8.2 | 10.2 | 10.2 | 1.0 |
+| 1898×982, 1,024 | 734.2 | 56.3 | 35.8 | 47.1 | 57.3 | 63.5 | 46.1 | 50.2 | 56.3 | 1.0 |
+| 1898×982, 4,096 | 3.38 ms | 221.2 | 138.2 | 180.2 | 241.7 | 244.7 | 171.0 | 169.0 | 207.9 | 1.0 |
+| 4K, 0 | 206.8 | 6.1 | 13.3 | 16.1 | 6.1 | — | 6.1 | — | 9.2 | 2.0 |
+| 4K, 16 | 217.1 | 10.2 | 19.5 | 22.5 | 10.2 | 11.3 | 10.2 | 11.3 | 12.3 | 2.0 |
+| 4K, 1,024 | 2.52 ms | 57.3 | 102.4 | 133.1 | 59.4 | 62.5 | 47.1 | 49.1 | 72.7 | 2.0 |
+| 4K, 4,096 | 10.77 ms | 236.5 | 436.2 | 562.2 | 255.0 | 256.0 | 176.1 | 174.1 | 285.7 | 2.0 |
+
+**AMD iGPU:**
+
+| config | A0 today | A2 | H | H + compaction | G ctw (1,024 switch) | G ctw (mask always) | G list | G list (mask always) | G list + compaction | floor |
+|---|---:|---:|---:|---:|---:|---:|---:|---:|---:|---:|
+| 640×360, 0 | 105.6 | 4.9 | 6.5 | 9.0 | 5.2 | — | 4.4 | — | 6.7 | 1.2 |
+| 640×360, 16 | 124.6 | 13.4 | 24.8 | 27.2 | 14.1 | 13.5 | 11.9 | 11.9 | 14.4 | 1.2 |
+| 640×360, 1,024 | 8.11 ms | 117.1 | 253.5 | 314.5 | 121.3 | 123.8 | 91.0 | 100.0 | 125.4 | 1.2 |
+| 640×360, 4,096 | 36.23 ms | 495.2 | 1.50 ms | 1.85 ms | 528.4 | 531.0 | 383.2 | 378.3 | 641.7 | 1.2 |
+| 1898×982, 0 | 953.1 | 21.0 | 51.0 | 72.3 | 22.2 | — | 17.7 | — | 40.0 | 9.2 |
+| 1898×982, 16 | 959.0 | 69.6 | 157.0 | 179.3 | 73.7 | 61.4 | 60.2 | 50.0 | 83.6 | 9.4 |
+| 1898×982, 1,024 | 60.61 ms | 618.2 | 1.43 ms | 2.13 ms | 638.7 | 483.0 | 479.8 | 354.0 | 859.6 | 9.3 |
+| 1898×982, 4,096 | 272.0 ms | 2.65 ms | 8.62 ms | 11.84 ms | 2.21 ms | 2.13 ms | 1.53 ms | 1.46 ms | 3.69 ms | 9.3 |
+| 4K, 0 | 3.64 ms | 76.6 | 222.1 | 304.0 | 80.9 | — | 61.0 | — | 144.7 | 28.4 |
+| 4K, 16 | 4.01 ms | 270.7 | 668.8 | 760.1 | 288.8 | 229.7 | 233.3 | 181.6 | 323.3 | 30.7 |
+| 4K, 1,024 | 256.2 ms | 2.43 ms | 6.08 ms | 9.28 ms | 2.51 ms | 1.74 ms | 1.89 ms | 1.24 ms | 3.95 ms | 29.7 |
+| 4K, 4,096 | — ¹ | 10.33 ms | 36.0 ms | 50.4 ms | 8.33 ms | 8.06 ms | 5.88 ms | 5.63 ms | 15.34 ms | 28.8 |
+
+All values are µs unless marked ms. ¹ Not run: a single dispatch would come too close to the 2 s TDR.
+
+- At zero lights, the "mask always" columns equal the switch columns (W = 0).
+- The "mask always" columns are a separate paired run (switch vs always, the same four arms interleaved).
+  Within that run, the switch arms read within 3% of the main table.
+
+### 2.2 Where the time goes (per pass, p10, 1,024 lights)
+
+| | 4090 1898×982 | 4090 4K | iGPU 1898×982 | iGPU 4K |
+|---|---:|---:|---:|---:|
+| prepass, sorted: 3 passes | 6.1 | 7.1 | 20.8 | 24.5 |
+| H walk (stage 2; small-set stage 1 inside) | 33.8 | 100.4 | 1,763 | 6,042 |
+| H compaction | 11.3 | 29.7 | 742 | 3,126 |
+| G fine, count-then-write | 50.2 | 53.2 | 647 | 2,521 |
+| G fine, list | 39.9 | 39.9 | 479 | 1,888 |
+| G list compaction | 10.2 | 25.6 | 410 | 1,711 |
+
+At 4,096 lights the scalable coarse stage of G costs:
+
+| | 4090 1898×982 | 4090 4K | iGPU 1898×982 | iGPU 4K |
+|---|---:|---:|---:|---:|
+| clear + `atomicOr` scatter | 4.1 µs | 6.1 µs | 132 µs | 612 µs |
+
+**Why H's walk loses at 4K.** Its cost tracks Σ over tiles of survivors. That roughly triples from
+1898×982 to 4K (33.8 → 100.4 µs), while G's fine pass stays flat (50 → 53 µs), because G amortizes one
+survivor iteration over 64 cells.
+
+**What the H walker's occupancy says.** NVIDIA: 53 regs, 50% occupancy, capped by the 32-thread groups.
+The 4-tiles-per-workgroup variant reaches 100% (40 regs) and gains only 4–12%, so the serial walk is the
+limit.
+
+### 2.3 Consumers: list walked directly vs today's compacted list (stand-in shading pass, p10)
+
+**The stand-in pass.** Full screen, a ray-cast ground plane, the cell's lights read by id from the light
+database, a distance and cone falloff summed. It is not the 80-register deferred pass, so the walk's
+latency would be hidden better there; that part is **unmeasured**.
+
+| config | 4090 compacted | 4090 list walk | Δ | iGPU compacted | iGPU list walk | Δ |
+|---|---:|---:|---:|---:|---:|---:|
+| 640×360, 1,024 | 14.3 | 17.4 | +21% | 783 | 827 | +6% |
+| 640×360, 4,096 | 44.0 | 57.3 | +30% | 2.93 ms | 3.26 ms | +11% |
+| 1898×982, 1,024 | 62.5 | 67.6 | +8% | 5.17 ms | 5.50 ms | +6% |
+| 1898×982, 4,096 | 199.7 | 227.3 | +14% | 19.0 ms | 24.0 ms | +26% |
+| 4K, 1,024 | 257.0 | 277.5 | +8% | 23.0 ms | 27.1 ms | +18% |
+| 4K, 4,096 | 839.7 | 938.0 | +12% | 84.4 ms | 107.5 ms | +27% |
+
+At 0 and 16 lights the difference is 0 on both GPUs.
+
+**Break-even.** The cost of each output option, with N consumer passes reading the lights:
+
+- **count-then-write:** the assignment alone;
+- **list + compaction:** the list assignment plus the compaction pass;
+- **list walked directly:** the list assignment plus N × the walk penalty.
+
+| | count-then-write | list + compaction | list walked directly |
+|---|---:|---:|---:|
+| 4090, 1898×982, 1,024 | 57 | 56 | 46 + N × 5 |
+| iGPU, 1898×982, 1,024 (mask always) | 483 | 764 | 354 + N × 321 |
+| iGPU, 4K, 1,024 (mask always) | 1,742 | 2,955 | 1,244 + N × 4,120 |
+
+Today the lists feed:
+
+- the deferred direct shading chunk (`chunk_shade_standard_material_direct`);
+- the volumetrics irradiance and lighting builds;
+- ReSTIR DI candidate generation;
+- the OIT/AVBOIT raster passes;
+- water.
+
+So N ≥ 2 whenever more than one of these runs in a frame. **On the iGPU, count-then-write wins for N ≥ 1.**
+
+### 2.4 Registers, occupancy, scratch (NVIDIA 610.88 Vulkan; AMD 2.0.302 Vulkan, compiling Tint's own SPIR-V)
+
+| pipeline | threads | NV regs | NV local | NV shared | Ada occupancy | AMD VGPR | AMD SGPR | AMD scratch | AMD LDS |
+|---|---:|---:|---:|---:|---:|---:|---:|---:|---:|
+| A0 today | 64 | 72 | 1,024 | 1,792 | 58% | 72 | 48 | 1,344 | 0 |
+| A2 | 64 | 48 | 0 | 520 | 83% | 41 | 68 | 0 | 1,024 |
+| **G ctw (fine)** | 64 | 48 | 0 | 528 | 83% | 42 | 76 | 0 | 1,024 |
+| **G list (fine)** | 64 | 48 | 0 | 1,044 | 83% | 42 | 86 | 0 | 1,536 |
+| G coarse scatter (`A3_scatter`) / clear | 64 / 256 | 30 / 16 | 0 | 0 | 100% | 10 / 3 | 29 / 12 | 0 | 0 |
+| G coarse gather (rejected) | 64 | 20 | 0 | 0 | 100% | 12 | 19 | 0 | 0 |
+| H prep (unsorted) | 64 | 27 | 0 | 0 | 100% | 30 | 28 | 0 | 0 |
+| H BT (stage 1, large) | 64 | 16 | 0 | 0 | 100% | 35 | 12 | 0 | 0 |
+| H walk (stage 2) | 32 | 53 | 0 | 140 | 50% | ² | ² | ² | ² |
+| H walk, 4 tiles per workgroup | 128 | 40 | 0 | 548 | 100% | ² | ² | ² | ² |
+| H2 walk (survivor-parallel) | 32 | 55 | 0 | 9,872 | 19% | ² | ² | ² | ² |
+| compaction (UE shape) | 64 | 18 | 0 | 0 | 100% | 17 | 24 | 0 | 0 |
+| consumer, compacted / list walk | 64 | 32 / 32 | 0 | 0 | 100% | 21 / 20 | 40 / 40 | 0 | 0 |
+| sorted prepass: mark / compact / lights | 64 / 256 / 64 | 16 / 20 / 27 | 0 | 0 / 512 / 0 | 100% | 3 / 18 / 30 | — | 0 | 0 / 512 / 0 |
+
+² My offline `vkstats.py` route failed to compile the H walkers on the AMD driver. That is a tooling result
+and says nothing about what ships; Chrome runs them on that iGPU, which is where the timings come from. No
+figures, no prediction.
+
+**Every new pipeline: 0 scratch, 0 local memory.**
+
+## 3. The linked list: semantics
+
+### 3.1 Layout
+
+- Per cell, two heads (point, spot): 8 B.
+- Per cell, a count word, which only the compaction reads.
+- A node pool of `vec2u(light id, next)`.
+
+**Memory.** Pool demand was 1.05× the hit count, the holes being the precise-test rejections inside a
+reserved box. That fits inside today's `cluster_data` budget, about 64.5 words per cell:
+
+| config | demand (nodes) | capacity in today's bytes (nodes) |
+|---|---:|---:|
+| 1898×982, 4,096 lights | 798,852 | 1,439,640 |
+| 640×360, 4,096 lights | 123,685 | 185,760 |
+| 4K, 4,096 lights | 3,517,641 | 6,315,840 |
+
+### 3.2 Determinism
+
+**The set:**
+
+- Exact, keep-smallest per type, every frame, in both the sorted and the unsorted builds (§3.3).
+- This assumes **no pool overflow.** On overflow, the reservations past capacity are dropped, and which
+  tiles or blocks lose depends on the order of the reservation atomics. That is non-deterministic, the
+  same class as today's `cluster_data` truncation.
+- It needs the same sizing feedback loop (read back the reservation counter, grow).
+
+**The order within a cell:**
+
+- **Sorted build:** deterministic. A lane prepends in survivor order (ascending id), so walking yields
+  descending id; the compaction writes it reversed, giving ascending. Node *indices* vary from frame to
+  frame (reservation order); the traversal order does not.
+- **Unsorted build:** the cull's append order, as today.
+
+### 3.3 Keep-smallest
+
+- **Sorted:** free. The first CAP hits per type are the smallest ids.
+- **Unsorted:** at overflow, the lane walks its own list (≤ CAP nodes in global memory, dependent loads)
+  and overwrites the largest id if the newcomer is smaller. That is today's `cluster_keep_smallest`, moved
+  from a private array to the node pool. It costs only in overflowing cells.
+- **Verified:** identical sets at 4K × 4,096, where cells sit at the cap (128 point / 75 spot).
+
+## 4. The small-set path and its threshold
+
+### 4.1 Derivation (H, as asked)
+
+- The stage-2 workgroup is 32 lanes: the 24 slices rounded up to a power of two. 32 is also the minimum
+  subgroup width both adapters report (`subgroupMinSize` = 32 on Ada and on RDNA2).
+- One u32 per lane holds 32 lights' bits.
+- So a whole tile mask stays in registers up to **32 × 32 = 1,024 lights**. Up to that, stage 1 needs no
+  memory and no pass.
+- Above it, the mask goes to memory (BT), and the walker loops ⌈W/32⌉ chunks. That is ≤ 16 at the cull
+  list's 16,383 limit; doc line: none is dropped, the chunk loop is the budget.
+
+### 4.2 G has the same number
+
+At ≤ 1,024 lights a block's coarse survivors for a 64-light chunk are two lane-held words, and the chunk
+loop is ≤ 16 iterations of 64 threads.
+
+### 4.3 Measured crossover between G's two coarse sources
+
+| | 4090 1898×982 | 4090 4K | iGPU 1898×982 | iGPU 4K |
+|---|---:|---:|---:|---:|
+| 16 lights: box / mask | 8.2 / 11.3 | 10.2 / 11.3 | 73.3 / 61.4 | 287 / 230 |
+| 1,024 lights: box / mask | 57.3 / 63.5 | 59.4 / 62.5 | 638 / 483 | 2,512 / 1,742 |
+| 4,096 lights: box / mask | 241.7 / 244.7 | 254 / 256 | 2,228 / 2,132 | 8,480 / 8,064 |
+
+(µs; count-then-write; 640×360 is within ±3% on the iGPU and favours the box path on the 4090.)
+
+**Why the crossover moves:**
+
+- On the iGPU, barriers and subgroup operations are expensive. The mask lets a block with no lights skip a
+  chunk with one uniform load instead of a compaction round.
+- On the 4090 those are cheap, and the mask's two extra dispatches cost more.
+
+So the threshold that holds the budget (1,024) is not the threshold that minimizes time, and the latter
+depends on the device.
+
+## 5. Ranked proposal
+
+1. **G, count-then-write into today's product, mask path always** (forks F1 and F2 at their
+   recommendations).
+   - **Passes:** id-sorted prepass, coarse clear + light scatter, fine pass: 6 direct dispatches, no
+     indirect.
+   - **Consumers:** unchanged.
+   - **Determinism:** set and order, keep-smallest exact.
+   - **Per-thread budgets:**
+
+     | stage | per-thread budget |
+     |---|---|
+     | prepass compact | 64 bits |
+     | scatter | coarse blocks / 64 (≤ 48 at 4K) |
+     | fine | ≤ W/2 word pairs × ≤ 64 survivors per pair |
+
+   - **Cost:** 4090 4–6 µs at 0 lights, 62–85 µs at 1,024 (switch: 57–75 µs). iGPU 5–81 µs at 0 lights,
+     0.12–1.74 ms at 1,024. 65–147× faster than today on the iGPU at 1,024.
+2. **G with a linked list, walked by consumers** — only if F1 goes the other way. Fastest assignment on
+   both GPUs (4090 46–59 µs, iGPU 0.10–1.24 ms at 1,024). It pays per consumer pass, which loses on the
+   iGPU for any N ≥ 1.
+3. **H (2D then slices)** — recommended only for a 4090-class device at ≤ ~2 Mpx. It loses 2–4.5× on the
+   iGPU, and at 4K on the 4090. Kept in the record because it is the shape that was asked for.
+
+### Reuse map
+
+| piece | existing machinery |
+|---|---|
+| sorted prepass | the bench's mark/compact; generalizes to `graph_prefix_scan_csdldf` beyond one workgroup |
+| per-light record + box | `chunk_point_light_to_aabb3`, `chunk_spot_light_to_aabb3`, `chunk_cluster_depth_to_z_slice`, `chunk_sphere_screen_extents` |
+| precise tests | `chunk_sphere_intersects_frustum` semantics, `chunk_cone_intersects_sphere` (cell sphere once per cell) |
+| subgroup allocation | `chunk_vsm_append_mover` |
+| ordered compaction | `chunk_subgroup_active_count_bits` pattern, `workgroupUniformLoad` |
+| tile / block gather (BT) | the structural session's R1 bin step, which is the rejected gather here |
+| compaction | UE 5.4 `LightGridCompactCS` (VERIFIED, round 1 §2.1) |
+| decals | `shader_cluster_assign_decals` takes the same fine pass with keep-largest; not built |
+
+## 6. Forks for Alex
+
+- **F1. Output: count-then-write into today's `{counts, offset}`, or a linked list?**
+  - The list's single sweep is 20–31% cheaper to build.
+  - Compacting it UE-style costs more than that on both GPUs.
+  - Walking it directly costs +6–30% in every consumer pass.
+  - *Recommendation:* **count-then-write.** It has no per-thread array, which was the thing to get rid of:
+    counts live in registers and survivors in workgroup memory. The list only wins on a 4090-class device
+    with one or two consumers.
+- **F2. Small-set switch at 1,024 (derived) or the mask path always?** *Recommendation:* **mask always.**
+  It wins at every count on the modest GPU (−17% to −31% at 1898×982 and 4K). It costs the 4090 ≤ 9 µs
+  below 1,024. The derived threshold stays the loop budget, not a speed switch.
+- **F3. Sort in the prepass (+2 dispatches) or keep the cull's order?** *Recommendation:* **sort.** For
+  2–4 µs (4090) and 3–25 µs (iGPU) it buys keep-smallest for free, a deterministic order, and type
+  grouping. Without it, keep-smallest needs the overflow walk of §3.3.
+- **F4. The 2D-first stage at 32 px (H) against the 3D block (G).** *Recommendation:* **G.** The data in
+  §2.1 and §2.2 is the reason. H's 2D binning does reduce the culling dimension, but its walk then repeats
+  every light once per tile.
+
+## 7. Method notes and data
+
+- **Bench:** `H:/tmp/clusteralgo/bench/` (scratchpad copy):
+  - `h_arms.js`: H, H2, G, the compaction and the consumers;
+  - `arms.js`, `bench.js`;
+  - jobs `job_hcheck.js` (correctness) and `job_htime.js` (timing);
+  - results `final_nv3.json`, `final_amd2.json`, `thr_nv.json`, `thr_amd.json`;
+  - SPIR-V and driver statistics: `H:/tmp/clusteralgo/hdumps`, `hvkstats.json`.
+- **Earlier 4090 runs this round** were taken under 50–70% foreign GPU load and showed contamination. They
+  are superseded by the mirrored run quoted here.
+- **Not measured:**
+  - the real deferred pass's sensitivity to the list walk;
+  - decals;
+  - a GPU between the two tested.