Advance NanoVDB pin to openvdb #2319 and adopt single-space cuda::Buffer where it now fits (#770 steps 1-2)

[harrism]

Supersedes #752 (carrying its commit, with @swahtz as author). Steps 1–2 of #770, plus a latent-bug fix the new pin's validation exposed.

Summary

Advances the NanoVDB pin to 31d1e596 (merge of openvdb #2319) — past the whole "introduce + deprecate" arc of openvdb #2232 that has landed so far — and uses the single-space nanovdb::cuda::Buffer directly at the three device-only scratch/output sites where #2301 removed the reasons for an adapter or a dual-space type.

Grid storage is unchanged. GridBatchData's GridHandle<TorchDeviceBuffer> stays as it is; that flip is #770 steps 3–5 and deliberately not in this PR.

Commit 1 — normalize grid headers before constructing GridHandles (new)

A pre-existing bug, surfaced by the pin: NanoVDB #2292/#2301 make GridHandle validate a host buffer's grid chain at construction — every header must be valid, carry index i of count N, and have a size that fits. Two fvdb sites copied a header out of a multi-grid batch into a single-grid buffer and built a handle around it without resetting those fields:

• SaveNanoVDB.cu indexToGridHost() — *dstGrid->data() = *srcGrid->data() kept the source's mGridIndex, mGridCount and (index-grid) mGridSize. The CUDA tools::cuda::indexToGrid it ports resets index/count (IndexToGrid.cuh:167-168); the port didn't.
• LoadNanovdb.cpp copyIndexGridToHandle() — set mGridCount = 1 but left mGridIndex at the batch position.

copyIndexGridToHandle also copies the grid only up to its first blind-metadata record yet left mBlindMetadataCount/Offset claiming it, and every one of these header writes left the file's checksum stale; both are now normalized too (checksum marked disabled, as MakeContiguous/ConcatenateGrids do after their fixups).

Harmless before (the fields were overwritten later or never read); at the new pin, saving N>1 grids to a standard type fails with "invalid host buffer (grid 1 of N)" and loading grid i>0 of a tensor-grid file fails with "inconsistent grid index/count (grid 0 of 1)" — 275 of 622 test_io.py cases. Nine lines, correct at the old pin too, so it leads the series and every commit passes.

Commit 2 — pin + -Werror fallout (swahtz's #752, rebased)

• Pin 9df9ec06 → 31d1e596. Update NanoVDB for single-space GridHandle and widen Torch-pool coverage #752's original target e679862f is now behind main (which moved to 9df9ec06 in Use fused NanoVDB ReadAccessor::getDimAndActive in the HDDA iterators #754), so the conflict was resolved forward inside the commit to keep it building.
• PadGrid.cuh: #2301 makes cuda::DeviceBuffer a [[deprecated]] alias of DualDeviceBuffer and removes TopologyBuilder::mProcessedRoot outright. The getHandle() default template argument takes the non-deprecated spelling; padRoot() is ported to allocateProcessedRoot() / uploadProcessedRoot() mirroring upstream DilateGrid::dilateRoot. Net effect: the root upload is now asynchronous (pinned staging) and its device copy allocates through BuilderResource. A now-dead cudaGetDevice is removed.
• Update NanoVDB for single-space GridHandle and widen Torch-pool coverage #752's three allocator improvements are carried unchanged: SaveNanoVDB staging buffers on cuda::Buffer<…, BuilderResource>, TorchDeviceBuffer::create forwarding the builder's stream to raw_alloc_with_stream, and the VBM adapter (removed in commit 2).

Commit 3 — single-space buffers where NanoVDB now allows them

site	before	after
ReinitializeSdf.cu VBM metadata	local TorchVbmBuffer adapter (−79 lines)	VoxelBlockManagerHandle<cuda::Buffer<std::byte, BuilderResource>> directly
BuildPrunedGrid.cu per-leaf mask scratch	TorchDeviceBuffer + two reinterpret_cast; PruneGrid on legacy stream 0	cuda::Buffer<Mask<3>, BuilderResource>, typed data(); PruneGrid on the fill stream
SaveNanoVDB.cu indexToGrid output	GridHandle<TorchDeviceBuffer> via a TorchDeviceBuffer(0, device) guide	GridHandle<cuda::Buffer<std::byte, BuilderResource>> via a default-constructed pool buffer

Why each is safe now, verified against the pinned headers rather than assumed:

• The adapter existed because VoxelBlockManagerHandle's accessors were gated on hasDeviceDual and buildVoxelBlockManager allocated through BufferT::create. #2301 adds BufferHasDeviceSingle accessors and routes allocation through createDeviceStorage(bytes, proto, …); BufferTraits<cuda::Buffer<T,R>>::hasDeviceSingle is !is_host_accessible_resource<R>, true for BuilderResource, which is default-constructible and stream-ordered — so the nullptr prototype yields Buffer(stream, bytes, noInit) on the reinit stream. reset() releases via destroy().
• noInit for the mask scratch is behaviour-preserving: TorchDeviceBuffer never zeroed the allocation, and InjectPredicateToMaskFunctor writes every word (zero, then setOnAtomic) before PruneGrid reads it.
• PruneGrid takes a cudaStream_t defaulting to 0 and fvdb never passed one, so its mask reads and its two internal cudaStreamSynchronizes were not ordered after the fill kernel whenever torch's current stream is a non-blocking one. Pre-existing; closed here because the new comment on that block would otherwise be false.
• IndexToGrid::getHandle allocates through createDeviceStorage<BufferT>(size, &pool, …) at this pin, so a default-constructed pool supplies the resource and no device guide is needed.

With this, no TorchDeviceBuffer is allocated in SaveNanoVDB.cu; the remaining mentions read the grid batch's own handle and belong to the storage flip.

Not in scope

openvdb #2319's UnifiedBuffer deprecation (fvdb never uses it); openvdb #2322 (open) which, after #757, touches only PadGrid.cuh — the one file this PR already reworks; everything under #770 steps 3–6.

Verification

On an RTX PRO 6000 Blackwell (sm_120), torch 2.13.0 / CUDA 13.0 env built from env/build_environment.yml + the test_environment.yml delta:

• ./build.sh install gtests — -Werror=all-warnings clean, zero diagnostics.
• gtests via ctest: 47/47 passed.
• pytest unit/test_sdf.py unit/test_io.py unit/test_basic_ops.py unit/test_basic_ops_single.py unit/test_prune_single_voxel.py unit/test_sliced_batch.py unit/test_inject.py unit/test_batched_topology_builder.py: 1270 passed, 1 skipped, 18 subtests passed.
• Without commit 1, the same run at this pin is 995 passed / 275 failed, all in test_io.py — that is the regression test for the header fix.

Each commit builds on its own; commit 1 is also correct at the old pin. Note for anyone reproducing: ./build.sh ctest currently picks up the CPM blosc-subbuild's CMakeCache.txt (find … -print -quit) and reports no tests; run ctest in build/<tag>/src directly. Pre-existing, not touched here.

clang-format 18 / black 24 check: clean.

Review

Codex-reviewed (read-only, full diff + tree) before this revision. It confirmed the PruneGrid stream omission and the blind-metadata/checksum staleness above — all folded in. Two further pre-existing items it raised are not fixed here and are noted for follow-up: patchGridWithBlindShape (and the CUDA export path) rewrite checksum-covered GridData fields after the checksum is computed, so exported standard-type files carry a stale checksum; and TorchDeviceBuffer::create treats a null stream as "unspecified", which makes the legacy default stream 0 indistinguishable from "use torch's current stream" — this is the design documented in the header comment (commit 2), flagged for @swahtz rather than changed.

🤖 Generated with Claude Code

[harrism]

Analysis by Claude Code, run by @harrism.

Revised since the first push, after a Codex review of the full diff (which should have preceded opening this — it didn't; corrected now). Two of its confirmed findings were real and are folded in:

• BuildPrunedGrid.cu — PruneGrid was never given a stream. Its constructor defaults to legacy stream 0, so its mask reads and its two internal cudaStreamSynchronizes were not ordered after the fill kernel whenever torch's current stream is non-blocking. Pre-existing, but the new comment on that block asserted same-stream ordering, so it is fixed rather than reworded: pruneOp(grid, leafMask, stream.stream()).
• LoadNanovdb.cpp — copyIndexGridToHandle header now fully describes its buffer. Beyond mGridIndex, it copies the grid only up to the first blind-metadata record yet left mBlindMetadataCount/Offset claiming it, and every header write left the file's checksum stale. Both cleared; checksum marked disabled per the MakeContiguous/ConcatenateGrids convention.

Two further pre-existing items from the review are not fixed here, deliberately, and are in the body under Review: stale checksums in exported standard-type files (patchGridWithBlindShape and the CUDA export path both rewrite checksum-covered fields after computing it), and TorchDeviceBuffer::create's null-stream-means-current-stream ambiguity, which is the design documented in commit 2 — @swahtz, flagging that one to you rather than changing it.

Re-verified at the new head: -Werror clean, 47/47 gtests, 1270 passed / 1 skipped across the eight suites, CI-equivalent clang-format clean on all 344 src/ files.

[swahtz]

Review of steps 1–2 against the pinned headers at 31d1e596 and the local c10 source. One regression that should be fixed before merge (inline on TorchDeviceBuffer.cpp), one comment that mis-states an upstream invariant, and cleanups. Plan-level items that belong to later steps are on #770 rather than here.

Two notes on lines outside the diff hunks:

• BuildPrunedGrid.cu:103 — nanovdb::cuda::mergeGridHandles(handles, &guide) still runs on legacy stream 0 while this PR is making the rest of the file stream-correct (the new comment on the PruneGrid call describes exactly this read-before-write class). Suggest passing stream.stream() here since the file is already open; the other eight mergeGridHandles sites and three voxelsToGrid sites are step 5's.
• SaveNanoVDB.cu:11,16 — <nanovdb/cuda/DeviceBuffer.h> and <c10/cuda/CUDACachingAllocator.h> have no remaining uses in the file; the diff added <nanovdb/cuda/Buffer.h> next to DeviceBuffer.h rather than replacing it.

Not raised: the unreachable H2D fallback in fvdbToNanovdbGridWithValues (rewritten in step 4) and the raw_alloc ternary (class is deprecated in step 6).

🤖 Generated with Claude Code

[harrism]

Analysis by Claude Code, run by @harrism.

CI is 41/41 on d6e9300. For the record, the pip CUDA 13.2 workflow shows three attempts: attempt 1 failed only test_sample.py::test_trilinear_dense_vs_pytorch_05_cuda (fp16 × 16ch, Max grad error 0.1875) — a pre-existing flake unrelated to this PR (its backward accumulates with gpuAtomicAddNoReturn, so seeded inputs still see order-dependent fp16 rounding; it passed 8/8 locally on this exact code and on the previous head's identical job). Attempt 2 was a "re-run failed jobs" that can never start on our ephemeral runners (noted on #761); attempt 3 is the full rerun, all green.

[swahtz]

Analysis by Claude Code, run by @harrism.

CI is 41/41 on d6e9300. For the record, the pip CUDA 13.2 workflow shows three attempts: attempt 1 failed only test_sample.py::test_trilinear_dense_vs_pytorch_05_cuda (fp16 × 16ch, Max grad error 0.1875) — a pre-existing flake unrelated to this PR (its backward accumulates with gpuAtomicAddNoReturn, so seeded inputs still see order-dependent fp16 rounding; it passed 8/8 locally on this exact code and on the previous head's identical job). Attempt 2 was a "re-run failed jobs" that can never start on our ephemeral runners (noted on #761); attempt 3 is the full rerun, all green.

I also noted that flaky test. I have a fix for it in the #753 PR because I hit it there too.

[swahtz]

Nice, thanks for addressing my notes. Looks good to go.

[harrism]

Follow-up 6f605b9, after a codex review of d4d4cbf and 6e8420c that should have preceded pushing them. Its main finding was a race d4d4cbf introduced: keying scratch to torch's current stream is wrong, because TorchResource::deallocate_async does not order the free and the pinned PointsToGrid destroys its per-tile counts right behind an in-flight scan on legacy stream 0. The block has to be keyed to the stream its work runs on. So the two policies are now two resources:

• TorchResource (scratch, BuilderResource): back to raw_alloc_with_stream(bytes, stream), with the comment stating why that is load-bearing and that the stream must outlive the block.
• TorchStorageResource (grid storage): allocate on the current torch stream, event-order the caller's writer stream after it, free the block if any event call fails. TorchDeviceBuffer uses this one. @swahtz, this is the body I'd suggest TorchDeviceResource in Finish adopting NanoVDB's injectable CUDA memory resources (openvdb #2232): move grid storage off the dual-space TorchDeviceBuffer #770 step 3 adopts; it settles item 1 as before, just no longer at the expense of scratch.

Also in the commit, all surfaced by the same review: TorchDeviceBuffer::to()'s CUDA copies move off the legacy default stream onto the writing device's torch stream, are synchronized and error-checked, use cudaMemcpyPeerAsync across devices, and hold the destination in a scope guard so a failed copy neither leaks nor half-moves the buffer (all pre-existing). BuilderResource.h no longer claims to cover ops that still take CUB scratch from c10 directly. And a correction to d4d4cbf's message: BuildDenseGrid's PrivateUse1 dispatch builds one mesh for the first item and copies for the rest; only BuildGridFromIjk builds one per item.

Five codex rounds to clean. Re-verified at 6f605b9: -Werror clean, 47/47 gtests, 1605 passed / 1 skipped across nine suites, clang-format clean.

[swahtz]

[P3] Preserve zero-byte buffer transfers to CUDA — src/fvdb/TorchDeviceBuffer.cpp:177

The new allocation path changes the behavior of an empty C++ buffer:

fvdb::TorchDeviceBuffer buf;
buf.to(torch::Device(torch::kCUDA, 0));

Previously this succeeded: the native allocator returns a null pointer for a zero-byte allocation, and the zero-byte H2D cudaMemcpy succeeds. Now deviceAlloc(0) reaches TorchResource::allocate_async, whose null-pointer check throws fvdb: TorchResource::allocate_async failed. The new CUDA-to-CUDA allocation path has the same issue for zero-sized buffers.

Please handle zero-sized transfers without allocating, while preserving the requested destination device, and add a focused buffer-level regression test. This concerns zero-byte TorchDeviceBuffer objects, not empty voxel grids that still have an allocated NanoVDB header.

Validation: confirmed the native allocator's null result and the old zero-byte H2D copy's success with a local CUDA probe; the new exception follows from the allocation call chain at 6f605b9. I did not rebuild the updated PR.

[harrism]

Confirmed, thank you: to() reached the storage resource's null check for a zero-byte request. Fixed in 8a77387: to() returns early for size 0, recording the requested device and nothing else, and that now precedes the same-device check, which also used to reject an empty buffer moved to the device it was already on.

New TorchDeviceBufferTest (four gtests): the empty moves, plus two that were worth writing while here. Each of those two was rebuilt until a mutation run proved it earns its keep: with the CPU-to-CUDA synchronization removed from to() and the allocation-to-writer event removed from TorchStorageResource, the two tests fail on 3 of 3 runs; with the source restored all four pass on 3 of 3, 48/48 gtests, 1605 pytest. The one residual is a host thread descheduled for longer than the 0.25 s spin at exactly the wrong moment, which turns a would-be failure into a pass, never the reverse; it is documented on the constant.