Giving rays an index of the scene

Why rays need an index

ADR 0020 decides how Praxis will light a frame. Indirect light comes from ray-traced irradiance probes, and direct light from one hard shadow ray per pixel per light. A shadow ray asks whether anything lies between a shaded point and the light. Testing every triangle for every ray would not scale. The helmet's one Mesh alone has 23,358 triangles, and town, M3's dense Reference scene, plans about 250k Instances of 10 to 20 Meshes.

The usual answer is a bounding volume hierarchy, or BVH, a tree of nested boxes over the triangles. A ray tests a box before anything inside it and skips every box it misses, along with everything that box holds. A query then costs roughly logarithmic time in the number of triangles, where testing them all costs linear time.

GPUs build and search such trees themselves, behind the API's acceleration structures. The application hands over triangles and gets back an object it can build, copy and trace rays against. The APIs leave the form of the tree to the driver; Real-Time Rendering's ray-tracing chapter calls DXR's acceleration structure "mostly opaque to the user". wgpu 30 does not even have a call that returns how many bytes one takes, which chapter 4 deals with.

Rays will come from ray queries. An ordinary shader starts a query against a TLAS, steps it until it is done, and reads its committed hit, the closest one it accepted. wgpu offers them behind EXPERIMENTAL_RAY_QUERY, which the Capability floor has required since M1 (ADR 0021).

Two lessons carry over to the real structures. A better-built tree sends a ray through fewer boxes, and spending build time on that is what PREFER_FAST_TRACE asks for. A tree also fits one arrangement of triangles, so when they move it must be refitted or rebuilt; chapter 6 covers which of the two wgpu 30 allows.

Two levels

Ray-tracing APIs split the index in two. A bottom-level acceleration structure, or BLAS, covers one piece of geometry in its own local space; Praxis builds one per Mesh that rays trace. A top-level acceleration structure, or TLAS, holds a list of entries, and each entry points at a BLAS through a 3×4 transform that places it in the world. Metal calls the two levels primitive and instance acceleration structures.

wgpu calls an entry a TlasInstance, and Vulkan an instance. This guide says TLAS entry, as the PRs' code does, because in Praxis's glossary an Instance is one Renderable's data on the GPU. An entry holds a BLAS, the transform as three rows of four f32, 24 bits of custom data and an 8-bit mask.

Two levels make copies cheap. The helmet scene shows 11 Instances of one Mesh, so it builds one BLAS and points 11 entries at it. Moving or adding a copy changes entries and leaves every BLAS untouched.

A ray starts at the TLAS, whose boxes enclose the entries in world space. For each entry whose box it enters, the ray is moved into that entry's local space by the inverse of its transform, and the search continues down the entry's BLAS. A hit there is a hit on that entry. The query keeps the closest hit and reports the entry's custom data with it.

One BLAS per Mesh, at load

PR #234 gives each Mesh a BLAS when the Mesh loads. (Since #274, #276 and #289, each Mesh is loaded for a use: one the GPU bends and only draws gets no BLAS, a shadow proxy gets a BLAS but no Meshlets, and a refitted Mesh's BLAS allows updates and is never compacted. Crowd Shadows Explained and BLAS Refit Explained cover them.) MeshPool::load creates the BLAS and records its build, which reads the Mesh where it already lives, in its ranges of the vertex and index Arenas.

A cooked vertex is 28 bytes: a position of three f32, a uv of two f32 and a qtangent of four i16. The build reads Float32x3 at a vertex stride of 28, so it sees each vertex's leading 12 bytes, the position, and nothing else. first_vertex is the Mesh's offset into the vertex Arena, counted in vertices, and wgpu multiplies it by the stride. first_index skips the indices before the Mesh's range. The cooked indices count from the Mesh's own first vertex, so they land on the right positions.

The BLAS is created with PREFER_FAST_TRACE | ALLOW_COMPACTION. PREFER_FAST_TRACE asks the driver to spend build time on faster tracing, which suits geometry built once and traced every frame. ALLOW_COMPACTION permits the copy described below. The triangles are flagged OPAQUE, with no alpha test, so a hit counts as soon as the traversal finds it. Without the flag, a hit would reach the shader as a candidate and count only once the shader confirmed it with rayQueryConfirmIntersection, unless the ray's own flags force every BLAS opaque. wgpu-types' own doc for the flag says a BLAS without it has no hits, since naga has no candidate intersections yet; naga 30.0.1 has them.

The build is recorded into the load encoder after the copies that fill the Arenas, "so it reads what they write" (LoadStaging::build_blas). Both Arenas gain the BLAS_INPUT usage for it. The vertex Arena becomes STORAGE | BLAS_INPUT, and the index Arena trades INDEX, which nothing used, for BLAS_INPUT. Arena::new adds COPY_DST to both, as to every Arena, for the copies that fill them.

For the memory estimate in chapter 4, a BLAS counts its triangles from the Mesh's index range, mesh.indices.len() / 3. Meshlets play no part in it.

// The position leads each vertex; the cooked indices count from the
// Mesh's first vertex.
staging.build_blas(&wgpu::BlasBuildEntry {
    blas: &blas,
    geometry: wgpu::BlasGeometries::TriangleGeometries(vec![wgpu::BlasTriangleGeometry {
        size: &geometry,
        vertex_buffer: &self.vertex_arena.buffer,
        first_vertex: vertices.offset,
        vertex_stride: size_of::<CookedVertex>() as u64,
        index_buffer: Some(&self.index_arena.buffer),
        first_index: Some(indices.offset),
        transform_buffer: None,
        transform_buffer_offset: None,
    }]),
});

Compaction, step by step

A BLAS's exact size is known only once it is built. Compaction then copies it into a tighter allocation and frees the original. Metal splits it into writeCompactedSize and copyAndCompact, and Vulkan has a compacting copy mode. MeshPool::compact_blases runs it in wgpu 30:

1. Create each BLAS with ALLOW_COMPACTION. Without it, wgpu refuses to compact.
2. Build it. Renderer::upload now submits the staged loads, builds included, at its start; before PR #234 they went at the end of render.
3. Call prepare_compaction_async on every new BLAS.
4. Wait. device.poll(PollType::wait_indefinitely()) blocks the CPU until the GPU has finished the builds and everything submitted with them.
5. Replace each BLAS that reports ready_for_compaction() with queue.compact_blas(&blas). One that is not ready keeps its uncompacted BLAS, and a warning is logged.
6. Wait again, before any TLAS reads them. queue.compact_blas only records each copy into the queue's pending writes, which go to the GPU at the start of the next submission, and wgpu-core 30.0.1 records no barrier after it; on Metal, wgpu-hal's acceleration-structure barrier is empty anyway (gfx-rs/wgpu#9215). These PRs stopped at the step above, so a TLAS built in the next submission could read a BLAS before its copy finished. PR #267, merged on 2026-10-23 as 470221e, made compact_blases submit those writes and wait for them too; GPU Ordering Explained follows the race.
7. Keep the copy for good. wgpu documents the returned BLAS as "more restricted than a normal BLAS because it may not be rebuilt or compacted."

wgpu-types' own doc for ALLOW_COMPACTION names Blas::prepare_for_compaction and CommandEncoder::compact_blas. Neither exists in 30.0.1; the names above do.

for &(handle, _) in &self.awaiting_compaction {
    self.blases[handle.0 as usize].prepare_compaction_async(|_| {});
}
if let Err(error) = self.device.poll(wgpu::PollType::wait_indefinitely()) {
    tracing::error!(%error, "waiting for BLAS builds failed");
}
for (handle, triangles) in self.awaiting_compaction.drain(..) {
    let blas = &mut self.blases[handle.0 as usize];
    if !blas.ready_for_compaction() {
        // lines 291 to 294: tracing::warn!(…, "BLAS not compacted: not ready after its build")
        continue;
    }
    *blas = queue.compact_blas(blas);
    self.uncompacted_blas_triangles -= triangles;
    self.compacted_blas_triangles += triangles;

Compaction needs each build finished, so the frame that completes a load now waits for every load submitted with it, Textures included. texture-wall shows it most. Its first frame went from 75.5–76.6 ms to 88.1–92.8 ms, "waiting for its 10,000 Textures' copies before compacting". M4's streaming takes this wait off the critical path, together with the static TLAS's rebuild.

A build also needs a scratch buffer while it runs. wgpu 30 allocates one inside each build call, sized for everything that call builds, and the engine never sees it. Each Mesh's BLAS is its own call here. The PR's review raised batching them to share scratch, and the PR declined: town has 10 to 20 Meshes, and M4 reworks load submission.

The test loads a Mesh made of one degenerate triangle, then the Mesh under test, a triangle around (0.8, 0). It builds a one-entry TLAS over that Mesh's compacted BLAS and traces rays down −Z with a ray query. The ray through (0.8, 0, 0) hits and returns the entry's custom data, 7; the rays through (0, 0, 0) and (0.8, 0.5, 0) miss. The PR shows the test failing three ways: with first_vertex 0, with first_index 0, and without ALLOW_COMPACTION.

Counting bytes nobody reports

Frame stats carry gpu_memory_bytes, the GPU memory the engine allocates, and the bench compares it with committed Baselines. wgpu 30 has no call that returns an acceleration structure's size. wgpu-core keeps the size crate-private, and its internal counters track acceleration structures only on DX12. On Vulkan, wgpu's allocator report lists the memory behind each one by name, which is how lavapipe's figures below were measured; on Metal, wgpu gives no allocator report. M3's decision was to count them anyway, from sizes measured once per backend and labelled as estimates, and to leave exact sizes to M4.

AccelerationStructureBytes::estimate(backend) picks the figures. It returns lavapipe's on Vulkan, software or not, and the M4 Pro's on every other backend, as the Budgets' reference machine. (Since #303, merged on 2026-10-26 as 4a7ab0b, it takes the adapter instead of the backend: an NVIDIA GPU, on any backend, gets figures measured on an RTX 2070 SUPER, and every other adapter gets lavapipe's or the M4 Pro's as before.)

The M4 Pro's figures come from the GI survey's one-off scratch program, which read Metal's currentAllocatedSize before and after creating its structures. 199,098,368 bytes for 2,117,632 triangles gave 94 B per triangle, and 28,868,608 bytes for a TLAS of 100,064 entries gave 288.5. The survey states 45.5 after compact_blas without a raw byte count. The program is not in the repo, so committed code cannot re-run it.

lavapipe's come from PR #231, a throwaway that ran in CI's software-Vulkan job and summed wgpu's allocator report by allocation name. From 2,048 triangles up, a BLAS took 104.0 B per triangle, and each compacted copy came out 56 B larger; 2 triangles took 248 B either way. A TLAS took 240.1 B per entry at 1,024 entries and 240.0 B at 100,064 and 262,144, made of 176 B of acceleration structure and 64 B of wgpu-core's buffer of entries.

Open question. Whether the M4 Pro's 288.5 B includes wgpu-core's buffer of entries was never measured apart. On Metal that buffer holds a 72-byte MTLIndirectAccelerationStructureInstanceDescriptor per slot, not the 64 bytes it holds on Vulkan. wgpu-core creates the buffer with the TLAS, so a device-wide count around creation would take it in, and the code's comment says the figure includes it; the survey did not separate the two.

PR #234 adds a Frame stat of its own, estimated_acceleration_structure_bytes, whose name says what it is, and adds it into gpu_memory_bytes. After a load, each BLAS counts at its compacted figure, or at its built figure if compaction failed. PR #235 adds the static TLAS to the same stat, at full capacity.

The static TLAS

PR #235 gives the Renderer a StaticTlas, a TLAS over every Instance whose entity carries no PreviousWorldTransform. The glossary calls those Instances static and the rest Moving Instances. The TLAS is created in Renderer::new with 2¹⁸ = 262,144 slots and updated at the end of Renderer::upload from that frame's Instance writes (since #258, first in the frame's encoder, so that the camera uniform can carry the load Anchor). Chapter 7 explains the size.

Its entries are indexed by Instance slot, so the Instance in slot 7 gets entry 7. Each static Instance's entry comes from TlasInstance::new(blas, transform, custom_data, mask), given:

• its Mesh's compacted BLAS, from PR #234;
• its transform, the three rows of a 3×4 matrix measured from the load Anchor, below;
• its slot, as the custom data;
• 0xff, as the mask, commented "Every ray's cull mask".

A freed slot's Instance names no Mesh (NO_MESH), so it has no BLAS and its entry is empty, None.

A hit returns its entry's custom data as instance_custom_data, so a shader will know which Instance its ray struck. The field holds 24 bits, wgpu-core rejects larger values at build time, and 2¹⁸ slots fit. Storing the slot has a reason the PRs do not state; what follows is this guide's reading of wgpu-core. wgpu-core uploads only the filled entries, so a hit's own instance index counts filled entries. That index drifts from the slot as soon as a lower slot is empty or holds a Moving Instance.

The mask filters hits. A ray carries an 8-bit cull mask, and an entry counts only if the two share a set bit. With 0xff every ray sees every entry. Masks could later keep some geometry out of shadow rays and other geometry out of probe rays.

A frame anchored at load

ADR 0014 keeps f32 World positions off the GPU. f32 positions lose precision beyond 512 m from their origin, and Praxis's worlds must work at 10 by 10 km and more. Positions travel as an Anchor, the 64 m grid cell that holds them, plus an f32 offset from the cell's corner. Subsystems that compute in f32 "convert at their boundary into a local frame they own", and ADR 0014 lists ray-tracing acceleration structures among them. A TLAS transform is twelve f32, so the static TLAS owns such a frame.

Its origin is the load Anchor, the corner of the camera's Anchor cell in the first Frame data the TLAS takes, and it is never re-anchored in M3. Each entry's translation is composed in f64 and rounded to f32 once, in anchored_transform:

translation = (Instance Anchor − load Anchor) × 64 m + Instance offset

The rows come out as [R | t], row-major as wgpu expects; Metal's layer transposes them into its own column-major record. The Instance's offset is itself an f32 from prepare, but it is under 64 m, so its own rounding is at most 2⁻¹⁹ m, about 1.9 µm, by this guide's arithmetic.

Item 3 of the M3 decision on issue #17 anchors the static TLAS at load "so M1's 100 km check holds for shadows". The 100 km check renders each Reference scene that has a Golden, shifted 100 km from the World origin, and requires it to match that Golden; the helmet scene, whose source is fetched, has none. Placed by raw World position, entries 100 km out would step 7.81 mm in f32. Measured from the load Anchor, a scene within about 2 km of it steps at most 0.24 mm.

That 0.24 mm is an upper bound. The f32 step at distance d is 2^{(⌊log₂ d⌋ − 23)} m: at most 0.122 mm below 2,048 m, and 0.244 mm from 2,048 to 4,095 m. A coordinate "about 2 km" out can pass 2,048 m once the up to 64 m between the camera and its cell's corner is added. For comparison, ADR 0014's bar for drawn positions is 0.043 mm, for a point 0.3 m from the camera at 1440p.

PR #235's test runs the anchoring 100 km out. It puts the load Anchor at cell [1562, 0, −3], whose x is 1562 × 64 = 99,968 m, and writes three Instances: a static one "turned and doubled", a Moving one, and an unturned static one at x 5. Only the two static ones get entries, tagged with their slots, 0 and 2. The turned one's Anchor [1563, −1, −3] and offset [0.25, 63.5, 10.0] give a translation of (64.25, −0.5, 10), and its rows come out as [0, −2, 0, 64.25, 2, 0, 0, −0.5, 0, 0, 2, 10]. A ray at (64.25, 1.1, 10) hits it. A ray at (64.25, −2.1, 10), where a transposed rotation would have put it, misses.

When it rebuilds

wgpu 30 cannot update a TLAS in place. ALLOW_UPDATE exists, but its documentation reads "currently this is unimplemented and will build as normal", and wgpu-core always passes Build, although Metal's and Vulkan's layers below it implement updates. Every change to the static TLAS is therefore a full rebuild, so PR #235 rebuilds only when it must:

• The first Frame data always builds it, even with no static Instance. wgpu refuses to submit a pass that binds an unbuilt TLAS, which #203's shadow rays will do. The orrery exposed the gap: its bodies all move, so until the PR's second commit its static TLAS was never built.
• After that, a frame rebuilds it only if it writes a static Instance or frees one's slot. In the PR's words, a static Instance is written when it is "spawned, moved, or given another Mesh or Material". A despawn frees its slot, and a static Instance that turns Moving empties its entry the same way. The code rebuilds on any write of a static Instance, even one whose data did not change, such as the rewrite of every Instance after lost uploads. The review weighed rebuilding on a Material-only change and kept it, as "right and rare".
• Nothing else does. A Moving Instance's write, freeing a Moving Instance's slot (its entry was already empty), a write past capacity, and a frame that writes no Instance, such as one where only the camera moves, all leave it alone.

A Moving Instance is one whose entity carries PreviousWorldTransform, which stays on every entity the fixed schedule moves. When these PRs merged, only the orrery's five bodies carried it; town's 10,000 pigeons (#275) and the crowd's 1,600 shadow proxies (#276) have joined them since. Prepare flags each run of Instance writes with InstanceWrite::moving and splits runs where the flag changes, so the static TLAS can skip them. #204's dynamic TLAS will take them from there.

Each rebuild costs about 4.3 to 4.7 ms of CPU at 2¹⁸ slots on the M4 Pro, as PR #235 measured in scenes of 5 to 100 Instances (chapter 8).

Why 2¹⁸ slots

A TLAS's capacity is fixed when it is created, as max_instances, and in wgpu 30 every rebuild walks all of it, filled or not:

• Device::create_tlas allocates one None per slot, so a Tlas always holds a Vec as long as its capacity.
• Recording a build maps every element of that Vec, and wgpu-core then resolves and collects every element into a new one.
• When the encoder is processed, which the PR times as finish, wgpu-core converts each filled entry into the bytes the GPU reads. The build itself counts only the filled entries.
• wgpu tracks the lowest unmodified slot, but wgpu-core 30.0.1 only passes it through and never builds part of a TLAS.

Ticket #202's split comment measured the effect on the M4 Pro. Rebuilding a TLAS holding 11 Instances took 0.8 ms of record plus finish at 2¹⁶ slots, 4.3 ms at 2¹⁸ and 9.7 ms at 2¹⁹.

By this guide's arithmetic, that is about 16.4 ns per slot at 2¹⁸. The GI survey timed a TLAS of 100,064 entries at 4.8 to 6.4 ms of record plus finish, about 48 to 64 ns per entry by the same arithmetic; it did not record whether that TLAS's capacity exceeded its entries. Empty slots look cheaper than filled ones, but at 2¹⁸ they make up nearly all of the cost.

So the static TLAS has 2¹⁸ slots, sized for town's planned 250k Instances and no larger. At 2¹⁹, the Instance buffer's size, every static spawn would cost about 10 ms of CPU even in an 11-Instance scene, by the PR's estimate from the 9.7 ms point.

The TLAS is indexed by slot, so its capacity caps slot numbers. A static Instance in slot 262,144 or above is left out even when fewer Instances than that are static, and Moving Instances hold slots too. In prepare, "a slot freed in an earlier frame is taken again before a fresh one", so slot numbers grow only when no freed slot is waiting. All of town's about 250k Instances, its 10,000 Moving ones included, must fit below slot 262,144, which leaves 12,144 slots of headroom by this guide's arithmetic. As built in #273 and #275, town has 254,256 Instances, which leaves 7,888.

Past capacity, a static Instance is left out, so it will cast no shadow. Frame stats count it in static_instances_left_out, shown on the counts line, and the log warns once each time the count rises from zero: "Static Instances left out of the static TLAS: their slots are past its capacity, so they cast no shadow". A test with a capacity of 2 writes static Instances to slots 0 to 3, then checks that 2 are left out, that freeing slot 3 leaves 1, and that one warning appears.

Memory follows capacity as well. wgpu-core sizes both the TLAS and its buffer of entries by capacity, so the estimate counts the static TLAS full, whatever it holds.

The capacity is provisional, like every GPU buffer M3 adds. M4's split of the 8 GB Budget sizes them all (spec #188, story 44).

What it costs today

Both PRs were benched with praxis bench on the M4 Pro at 2560×1440, as medians over 1,800 frames. Main ran before and after each branch, at a load average of 6 to 25, while other work on the machine held the GPU. Steady frames did not move:

• GPU medians equal main's within 2 µs, after each part.
• CPU medians are 38 to 43 µs after part 1 and 41 to 44 µs after part 2, within main's own spread of 39 to 51 µs across its two runs. texture-wall, which is load-sensitive (#183), measured 1,984 µs and then 2,053 µs, against main's 1,957 and 1,994.
• Draw calls, uploaded bytes, Arena bytes in use and heap allocations (98 a frame in these runs, 138 in the Baselines both PRs recorded on main as of c77647f, after other PRs had added 40) are unchanged, so a steady frame does not rebuild the static TLAS, orrery's Moving Instances included.
• gpu_memory_bytes grows by each scene's BLASes, as in chapter 4, and by a further 75,628,544 B in every scene for the static TLAS at capacity.

The cost lands in two kinds of frame: one that rebuilds the static TLAS, and the first frame, where the load completes.

• CPU of a static spawn or despawn: about 4.3 to 4.7 ms. Recording takes 3.5 to 3.7 ms in upload, finish 0.6 to 1.1 ms in encode, and submit under 0.1 ms. The PR puts all of it down to wgpu walking the 2¹⁸ slots.
• GPU: the rest of the frame's growth. On texture-wall and helmet it is 0.25 to 0.56 ms. On orrery's spawn it is about 2 ms, because these runs predate the first-build fix, so that spawn built orrery's TLAS for the first time. The build sits outside the passes' timestamps, so Frame stats' GPU total leaves it out.
• First frame. In the PR's words, this is where the load completes. It now builds the BLASes, waits for them and compacts them (part 1), then builds the TLAS for the first time, which costs more than a rebuild. On helmet that is about 9 ms more than part 1 alone.

Part 1 alone moved setup and the first frame as below. These were separate runs from the table above, so the main columns differ.

For scale, the GI survey's scratch program, whose figures spec #188 repeats, measured 4.8 to 6.4 ms of CPU to record and finish, plus 1.1 to 1.4 ms of submit, for a TLAS rebuild of 100,064 entries. ADR 0020 keeps a rebuild of that size, 6 to 8 ms of CPU, out of the frame, with the near field's radius and the move off the critical path both settled in M4. Until then a static spawn or despawn is a hitch, and spec #188 asks for it to be measured until M4 moves the rebuild.

Goldens are unchanged on Metal and on CI's software Vulkan. Nothing renders differently, because nothing traces a ray until #258.

What this unlocks

• #203 traces the first rays. Every directional light gets one hard shadow ray per pixel from the lit pass, an inline ray query against the static TLAS from a normal-offset origin, skipped where N·L ≤ 0, with a render switch to turn shadow rays off. It adds the shadows Reference scene, a sphere over a plane checked against an analytic oracle, and the 100 km check must pass with shadows on every scene. PR #235's first-build fix exists for it. (#258, merged on 2026-10-23 as 0db5e46, traced them that way. Later that day #277, merged as bd7b988, moved every shadow ray into a compute pass that writes a shadow mask of up to 59 lights per pixel, which the lit pass reads; Shadow Rays Explained covers both.)
• #204 adds the dynamic TLAS: the Moving Instances, rebuilt each frame in the static TLAS's load-anchored frame, with a fixed capacity of 10,000. Past it they are left out, counted and warned about. It starts from the writes that InstanceWrite::moving flags, and the orrery's planets begin to cast shadows. (As #264 built it, merged on 2026-10-23 as 79cdabb, prepare also lists each Moving Instance it writes, with its slot, in moving_instances, and the dynamic TLAS is built from that list; Dynamic TLAS Explained covers it.)
• #205 adds point-light shadow rays, one per light in the pixel's Froxel list, against both TLAS.
• #206 builds town: about 1 × 1 km within 2 km of its TLAS anchor, about 250k Instances of 10 to 20 Meshes, 10,000 of them Moving. It checks that 2¹⁸ slots fit. #207 then records its Baselines and the dynamic TLAS's CPU and GPU ceilings. (#273 and #275 built it, with 254,256 Instances of 19 Meshes, below the 262,144 slots, and #275 recorded its first Baselines; PR #299, merged on 2026-10-26 as 800c0d2, re-recorded them and closed #207, with praxis compare holding the dynamic TLAS to the owner's ceilings, 1.1 ms of CPU and 1.0 ms of GPU. Town Explained covers it.)
• #208 and #209 measure a crowd: 100 meshes of 5,120 triangles deformed on the GPU each frame, each BLAS refitted through wgpu-hal on Metal in one documented unsafe block on the bench path, against rigid per-bone proxies in the dynamic TLAS. The crowd's acceleration-structure update has a budget of at most 1.0 ms of GPU and 0.5 ms of CPU per frame, and the owner picks M7's form at M3's exit. (The owner picked the per-bone proxies on 2026-10-26: they update in 597 to 603 µs of GPU and 319 to 326 µs of CPU, where the refit, merged in #289 behind the crowd_form Render switch, took 1.37 to 1.38 ms of GPU, on Metal only. Crowd Shadows Explained and BLAS Refit Explained cover them.)
• M4 sets the TLAS's near field and merged far proxies with Chunk streaming, re-anchors the static TLAS, takes its rebuild and compaction's wait off the frame's critical path, and replaces the estimates with exact sizes in its 8 GB split.
• M5's probe GI will read the same TLAS as the shadow rays.

Reading list

Grouped by source, each with what it is good for here. Every link below resolved when the guide was written. wgpu links are pinned to v30.0.1, and repo links to the PRs' merge commits or to main at 0b29a3c.

Glossary