Update NanoVDB for single-space GridHandle and widen Torch-pool coverage

[swahtz]

What this PR does

Follow-up to #732. Upstream has since merged openvdb #2286 (small-builder ResourceT seams — already in our previous pin, and our only relevant call site, indexToGrid in SaveNanoVDB.cu, was already routed) and #2288 (single-space device-only GridHandle<cuda::Buffer<T,R>>, step 3 part 1 of openvdb #2232). This PR advances the pin past #2288 and widens Torch-allocator coverage where it is reachable today.

1. Pin bump: 7946f17e → e679862f

The merge commit of upstream #2288. The new hasDeviceSingle/hasHostSingle traits are detected, defaulting to false, so TorchDeviceBuffer's dual-trait specialization compiles and behaves unchanged.

2. ReinitializeSdf: VBM metadata buffers through the Torch pool

The VoxelBlockManager's firstLeafID/jumpMap buffers were allocated with nanovdb::cuda::DeviceBuffer — outside torch's pool (and, with NANOVDB_USE_SYNC_CUDA_MALLOC builds, via synchronous cudaMalloc). They now allocate through BuilderResource via a local TorchVbmBuffer adapter over the single-space nanovdb::cuda::Buffer, stream-ordered on the reinit stream.

Why an adapter and not cuda::Buffer directly: VoxelBlockManagerHandle's device accessors are gated on BufferTraits<BufferT>::hasDeviceDual and static_cast their pointers from a void*-returning deviceData(), and buildVoxelBlockManager allocates through the legacy BufferT::create(bytes, guide, device, stream) static interface. Bringing the VBM handle into the single-space world is an upstream follow-up on the #2232 roadmap (noted in the adapter's doc comment).

3. SaveNanoVDB: device staging onto cuda::Buffer<…, BuilderResource>

The defensive host-grid upload buffer and the per-batch (N+1)-element value staging buffer become nanovdb::cuda::Buffer over BuilderResource, stream-ordered on the save stream (previously TorchDeviceBuffer via stream-less raw_alloc). The indexToGrid output handle stays TorchDeviceBuffer: upstream's builder output path (getBuffer → BufferT::create → deviceData()) still requires a dual-trait buffer; #2288's edits to IndexToGrid.cuh/AddBlindData.cuh were grid-index hardening, not single-space output support.

4. TorchDeviceBuffer: stream-correct allocation

The constructor gains an optional stream and uses raw_alloc_with_stream; create() forwards the stream nanovdb builders pass instead of discarding it (the same fix review flagged on the old #655 fork). Previously the allocation was silently associated with the device's current torch stream, which is only correct when that coincides with the builder's stream. Null stream keeps the previous behavior, so all existing two-argument constructor call sites are unchanged.

What is deliberately NOT here

Replacing TorchDeviceBuffer with GridHandle<cuda::Buffer<uint8_t, TorchResource>> for grid storage stays blocked on upstream step-3 parts 2–3: cross-space transfers are a named compile error until part 2, and the pinned-host create mapping lands in part 3 — both required for GridBatch's CPU grids and .to(device).

Testing

• Full rebuild of _fvdb_cpp (112 targets, sm_120) with zero warnings under -Werror=all-warnings / -Wall -Werror.
• tests/unit/test_sdf.py 10/10 (exercises the VBM adapter), tests/unit/test_io.py 622/622 (exercises the SaveNanoVDB staging path), tests/unit/test_basic_ops.py 276 passed / 1 skipped (carries the torch peak-memory bounds sensitive to allocator routing) — on an RTX PRO 6000 Blackwell, PyTorch 2.13.

🤖 Generated with Claude Code

[harrism]

Can this be updated based on the recently merged step 3 PRs (2292, 2293), and the now open 3-3 #2301?

[swahtz]

Can this be updated based on the recently merged step 3 PRs (2292, 2293), and the now open 3-3 #2301?

Indeed. I was putting this together from the last tranche of PRs but then saw the other ones were moving quickly so thought I'd hold off for the opportunity to cover those other ones.