[swahtz]

Part of #775 (item 1). Stacked on #835, which is stacked on #834. Until those merge, this PR also shows their commits. Review only the last commit, 0e0bb3d5.

Summary

dispatchBuildPaddedGrid<torch::kCUDA> sits behind GridBatch.dual_grid() and the build_padded_grid binding. It looped over batch members, ran one PadGrid pass per member per unit of padding, and merged the per-member storages. So its wall clock grew linearly with batch size.

This PR covers pure positive padding: bmin == 0 with exclude_border == False, which is dual_grid() and build_padded_grid(0, k). That case now builds the whole batch in k chained batched::TopologyPassSpec::boxDilate(Coord(0), Coord(1)) passes through batched::batchedTopologyStorage. After #835 those passes run on NanoVDB's TopologyBuilder.

• One output buffer
• Two host waits per pass
• Empty members become valid empty grids inline
• Sliced and non-contiguous views are read through the view-aware member pointers

Changes

• src/fvdb/detail/ops/BuildPaddedGrid.cu includes BatchedTopologyBuilder.cuh. After the totalPasses == 0 identity branch, when numNegative == 0 && !excludeBorder, it builds bmax boxDilate(0, +1) passes and returns batchedTopologyStorage(...).
• bmax chained Minkowski sums with {0,1}^3 equal the Minkowski sum with {0..bmax}^3, which is what buildPaddedGridFromGridCPU computes for [0, bmax]^3.
• These paths are unchanged:
  • the identity branch
  • the negative-pad and exclude_border erosion branch, which is Batch the remaining per-member CUDA topology builders #775 item 7
  • the dual-transform fix-up in buildPaddedGrid
  • the CPU and PrivateUse1 dispatches

Benchmark

GridBatch.dual_grid(), median of 20 runs after 3 warmups. GPU: RTX PRO 6000 Blackwell Workstation Edition, CUDA 13.4. "main" is main's per-member path. Peak is the extra device memory one call allocates.

• random128 members are 100k random coordinates in [-64, 64)^3. They straddle 0, so each grid spans 8 root tiles, which is TopologyBuilder's worst case.
• shell64 members are sphere shells inside one root tile.

input	B	voxels	main ms	this PR ms	speedup	main peak MiB	this PR peak MiB
random128	1	97,632	0.55	0.33	1.7x	133	133
random128	4	390,623	1.91	0.64	3.0x	141	532
random128	16	1,562,422	7.34	2.13	3.4x	175	1,085
random128	64	6,249,883	29.89	8.51	3.5x	360	1,218
shell64	1	14,096	0.36	0.27	1.3x	16.6	16.6
shell64	4	46,634	1.06	0.30	3.5x	17.5	66
shell64	16	180,695	3.85	0.56	6.9x	21.2	265
shell64	64	728,057	14.76	1.59	9.3x	39.9	1,060

Every output matched main's ijk and offsets exactly.

Peak memory grows because TopologyBuilder allocates about 16.5 MiB of lower-node masks per speculative root tile. Chunking by FVDB_TOPOLOGY_MAX_TILES (#835) caps it near 1.1 GiB plus the output. AcademySoftwareFoundation/openvdb#2392 tracks the upstream fix.

Tests

tests/unit/test_batched_topology_builder.py gains these tests:

• test_dual_grid_matches_expected_and_cpu runs over _tricky_batches() and checks three things:
  • ijk.jdata elementwise against a from_ijk build of unique(ijk + {0,1}^3)
  • coordinate sets against the CPU dual_grid
  • the dual-transform fix-up: voxel size is preserved and the origin shifts by half a voxel
• test_padded_grid_positive_matches_expected_and_cpu runs build_padded_grid(0, k) for k in (1, 2). It checks against unique(ijk + {0..k}^3) and CPU, and checks that the origin is unchanged.
• test_dual_grid_of_sliced_batch runs dual_grid on a [1:6] slice of a batch with empty members. It checks the result against per-member builds and the expected coordinates.

Test plan

• Build: ./build.sh wheel (CUDA 13.4, sm_120)
• Full unit suite: cd tests && pytest unit -q gives 3130 passed, 85 skipped
• clang-format-18 --style=file --dry-run, ruff check --select I and ruff format --check report nothing on the changed files

🤖 Generated with Claude Code