BuildTLASUpload pushed GPU-driven (transformOwnedByGpu) runs one element
at a time — a separate FlushDeviceRange of the 16 strided metadata bytes
per element — each paying WebGPU validation / encode / JS-boundary cost,
while the CPU-driven arm already batched contiguously.
Upload the whole active instance range in a single writeBuffer instead.
Pushing the (stale) transform bytes for GPU-driven slots is harmless: the
only supported way to drive a transform from the GPU is the manual
Upload -> physics compute pass -> Build sequence, and that compute pass
runs after this upload and rewrites the transform on the GPU before the
TLAS build reads it. For the in-repo (all-CPU) usage the bytes uploaded
are identical to before — with one CPU-driven run the old loop already
emitted exactly this single FlushDeviceRange(0, 0, primitiveCount*64).
Verified: native suite (24 passed) and the RTStress wasm example (512
ray-traced instances) render correctly through the new path.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The metadata mirror is padded to kNPadded (65536) but only primitiveCount
slots are live. metadataBuffer.FlushDevice() wgpuWriteBuffer'd all 256 KB
through the WASM->JS staging path every frame (~100-250x waste for a
few-hundred-instance scene). Switch to the existing FlushDeviceRange
overload — the same one the instanceBuffer loop directly above uses —
sized to primitiveCount * sizeof(uint32_t). The Vulkan parallel already
sizes its flush to primitiveCount, so this was WebGPU-specific.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
