BuildProcedural: accept a device buffer as AABB build input (no host round-trip) #37

New issue

Closed

opened 2026-06-16 15:31:40 +02:00 by jorijnvdgraaf · 0 comments

jorijnvdgraaf commented

2026-06-16 15:31:40 +02:00

Owner

`BuildProcedural`: accept a device buffer as AABB build input (no host round-trip)

Mesh::BuildProcedural currently memcpys the AABBs from a host std::span
(implementations/Crafter.Graphics-Mesh.cpp:212-226). A fully-GPU producer has
its AABBs in a device buffer already — copying them down to the CPU and back
up each frame defeats the purpose.

Needed by the downstream 3DForts GPU-resident particle system: point particles
(sparks/debris/rain) are rendered as procedural intersection volumes whose AABBs
are written by a GPU compute pass and change every frame. There is no CPU copy of
them, by design.

Ask: an overload of BuildProcedural (and the refit entry from #36) that
consumes an existing device buffer (buffer handle / device address + count)
as the AABB build input, skipping the host memcpy. Both backends (Vulkan +
WebGPU).

Relationship to #36

#36 ("Acceleration structure build options") covers BLAS refit (UPDATE) and
fast-build/fast-trace mode selection — the per-frame cost side. This issue is the
orthogonal input-source side: where the AABBs come from. Together they let a
GPU compute pass feed a moving procedural BLAS that refits each frame with zero
host involvement.

Verify

Extend examples/RTVolume so the per-frame AABBs live in a device buffer the GPU
writes, fed straight into BuildProcedural/refit with no host copy — on both
Vulkan and WebGPU.

## `BuildProcedural`: accept a device buffer as AABB build input (no host round-trip) `Mesh::BuildProcedural` currently `memcpy`s the AABBs from a host `std::span` (`implementations/Crafter.Graphics-Mesh.cpp:212-226`). A fully-GPU producer has its AABBs in a **device** buffer already — copying them down to the CPU and back up each frame defeats the purpose. Needed by the downstream 3DForts GPU-resident particle system: point particles (sparks/debris/rain) are rendered as procedural intersection volumes whose AABBs are written by a GPU compute pass and change every frame. There is no CPU copy of them, by design. **Ask:** an overload of `BuildProcedural` (and the refit entry from #36) that consumes an existing **device** buffer (buffer handle / device address + count) as the AABB build input, skipping the host memcpy. Both backends (Vulkan + WebGPU). ### Relationship to #36 #36 ("Acceleration structure build options") covers BLAS **refit** (UPDATE) and fast-build/fast-trace mode selection — the per-frame cost side. This issue is the orthogonal **input-source** side: where the AABBs come from. Together they let a GPU compute pass feed a moving procedural BLAS that refits each frame with zero host involvement. ### Verify Extend `examples/RTVolume` so the per-frame AABBs live in a device buffer the GPU writes, fed straight into `BuildProcedural`/refit with no host copy — on both Vulkan and WebGPU.

jorijnvdgraaf changed title from ~~Procedural BLAS: device-buffer build input + refit (UPDATE) for dynamic geometry~~ to BuildProcedural: accept a device buffer as AABB build input (no host round-trip)

2026-06-16 15:35:25 +02:00

jorijnvdgraaf added the

claude:ready

label

2026-06-16 15:48:33 +02:00