NanoVDB: injectable CUDA memory resources — design & roadmap

[harrism]

Summary

NanoVDB's CUDA path hard-wires its allocations — grid storage via GridHandle<BufferT>, scratch via cuda::TempPool/cuda::DeviceResource, and raw cudaMallocAsync/cudaMallocHost in builders. This tracks a layered design to let downstream inject its own allocator wherever NanoVDB allocates, aligned with CCCL's cuda::mr / cuda::buffer model — without a hard CCCL dependency. New APIs land alongside the existing ones; the legacy dual buffer + handle surface are deprecated and removed a release or two later, so there is no hard break at introduction.

Why

• Inject your own allocator without forking headers — downstream currently forks NanoVDB headers to route through their pool (e.g. PyTorch's c10::cuda::CUDACachingAllocator; cf. Fork a small set of nanoVDB headers to share PyTorch's CUDA allocator openvdb/fvdb-core#655, which vendored three headers).
• Fix the pinned-host stall — the synchronous cudaMallocHost inside cuda::DeviceBuffer serializes streams where a dual buffer is actually constructed host-side. Note this is not every DeviceBuffer use: init allocates host or device but never both, so buffers created with a real device id never touch cudaMallocHost (see the correction under B1).
• Share one pool across tensors, scratch, and grid buffers (caching; fewer fragmentation OOMs).
• Familiar + future-proof — method/type shapes match CCCL, so a resource_ref / cuda::buffer adapter is a thin shim later, while NanoVDB keeps its low CUDA floor.

Design — three pieces, each a minimal NanoVDB analog of a CCCL standard

1. Resource (allocator): two tiers matching CCCL's refinement. A synchronous resource exposes allocate(bytes, alignment)/deallocate(...) — no stream (cuda::PinnedResource is one). A stream-ordered resource adds allocate_async/deallocate_async(bytes, alignment, stream) and still provides the sync pair (typically thin delegates through the null stream), so is_async_resource<R> implies is_resource<R> — exactly cuda::mr's shape. cuda::DeviceResource provides all four; its legacy static allocateAsync/deallocateAsync are [[deprecated]]. Plus default_resource<R>() and the two detection traits. A custom allocator is a ~25-line struct.
2. cuda::Buffer<T,R> (storage) + cuda::BufferView<T> (view): one single-space, resource-aware, stream-ordered container modelled on CCCL's cuda::buffer<T> (the RMM device_buffer/device_uvector lineage). Buffer<T> typed, Buffer<std::byte> raw. Constructor order and shape follow cuda::buffer exactly — (stream, resource, count, noInit), the tag mandatory: there is no implicitly initializing count constructor (implicit fill of fresh memory is a hidden cost the allocate-then-overwrite pattern wastes). size() counts elements, size_bytes() bytes; a synchronous R yields a buffer with no stream API at all. Alongside it, BufferView<T>: a typed non-owning view with span semantics (element constness in T, trivially copyable, no resource, no stream) that satisfies the same static interface — so a GridHandle can wrap externally owned memory (an ONNX Runtime or Torch tensor) with zero copies. Owning and viewing do not share a type: the legacy mManaged owns-or-wraps flag is deleted, not re-spelled.
3. Single-space GridHandle (surface): one buffer per handle; grid() returns its pointer; host↔device is an explicit stream-carrying copyTo.

Rules that matter

• Stream ownership: a buffer retains its allocation stream and frees on it (not the null stream); the stream must outlive the buffer or be reset via a non-synchronizing setStream (the RMM cuda_stream_view contract). resize orders everything — including the free of the old block, whose last use is the prefix copy — on the passed stream.
• Resource ownership (revised — decision of record): cuda::Buffer holds the resource by value, matching cuda::buffer — but ownership semantics are selected by what is placed in that slot, completing the CCCL model rather than adopting half of it (cuda::buffer owns an any_resource; CCCL's borrowing and sharing tiers are resource_ref and shared_resource, and its constructor's static_assert points users at them). The tiers here: a concrete resource in the slot is owned as a copy (so it must be a cheap-to-copy handle, stateless or pointer-to-state); ResourceRef<R> (NanoVDB: SyncFromAsync, ResourceRef, and resource seams for MeshToGrid and TempPool (CUDA) #2269) borrows — a non-owning, dependency-free static analog of cuda::mr::resource_ref that is itself a resource, with enable_if-gated async members so a ref over a synchronous resource does not misreport its tier, and pointer-identity equality; a refcounted SharedResource<R> analog is deferred until the Python-bindings need materializes. Non-owning containers (TempPool, and the builders' ResourceT* members over time) compose with Buffer via ResourceRef. History: an earlier decision ("reference-at-API, pointer-as-member", pre-cuda::buffer reshape) was superseded by the by-value rule without reconciling the artifacts built on it — TempPool's pointer contract and the stateful test resources — which is what the first TempPool conversion attempt tripped over. Type-erased CCCL resource_ref interop remains step 4.
• Synchronous arenas (e.g. ONNX Runtime's) are wrapped as synchronous resources — never as a silent allocate_async facade (a facade misrepresents its semantics and hands multi-stream callers unexpected serialization). Contract: deallocate implies the memory is quiescent. The explicit lift is AsyncFromSync<R> (NanoVDB: run the builders on a synchronous memory resource (CUDA) #2272), the analog of CCCL's synchronous_resource_adapter: allocate_async forwards (synchronously allocated memory is valid on every stream — stronger than stream-ordering requires) and deallocate_async synchronizes the stream first, making the quiescence contract hold; the serialization cost is documented at the type and chosen by the caller.
• Naming: types are CamelCase per OpenVDB style (cuda::Buffer, cuda::BufferView) — type names are aliasable, so the opt-in using Buffer = ::cuda::buffer<T> at CUDA ≥ 13.2 is preserved. Member names keep the standard spelling (data, size, size_bytes, allocate_async) because member matching is structural and cannot be aliased.
• CUDA graph capture: the async resource tier is capture-safe — stream-ordered allocation records as graph allocation/free nodes, and Buffer's async path performs no hidden synchronization or initialization (verified by a capture → instantiate → relaunch test). The sync tier can never be captured (it synchronizes), visibly: a sync-R buffer has no stream API.
• No hard CCCL dependency; an optional adapter bridges to cuda::mr / cuda::buffer / cuda::std::span.

Roadmap

• Step 1 — resource concept (NanoVDB: add stream-ordered async memory-resource seam (CUDA) #2231, merged): DeviceResource instance methods + default_resource + detection traits; new PinnedResource; TempPool routes through a resource instance and frees on its retained stream; PointsToGrid instance-injection seam. Additive. Follow-up in review: NanoVDB: encode points for any resource in PointsToGrid (CUDA) #2244 (point encoding for any resource).

• Step 2 — cuda::Buffer<T,R> + BufferView<T> + scratch retrofit (in progress): ship the container, the view, the synchronous is_resource trait and the sync/async dispatch (PR A — NanoVDB: add cuda::Buffer, cuda::BufferView, and the synchronous resource concept (CUDA) #2251, merged); then convert the raw alloc/free onto the container — the "no raw allocation" cleanup — with a builder-coverage audit. The retrofit was originally scoped as a single PR B; a scoping pass found the three targets differ enough in risk that they land separately:

  • B1 — TopologyBuilder (NanoVDB: inject a resource into TopologyBuilder scratch, and align cuda::Buffer with cuda::buffer (CUDA) #2268): 8 of its 10 cuda::DeviceBuffer members are device-only (zero host .data() uses), as are 3 function-local buffers. Convert those 11 to Buffer<std::byte,R> and add a defaulted ResourceT parameter; only DilateGrid and MergeGrids instantiate TopologyBuilder, so existing callers are unaffected. mProcessedRoot and mData are genuinely dual-space and stay until Step 3. Carries the builder-coverage audit table. Correction: an earlier revision of this entry described B1 as fixing the pinned-host stall. It does not. DeviceBuffer::init allocates host memory or device memory, never both, and TopologyBuilder always passed a real device id, so no cudaMallocHost was ever on this path. Measured on dilate at 1k/20k/200k points: no difference beyond run-to-run noise. B1's value is injectability (the last builder without the resource seam) and scope-based ownership, not speed. The pinned-host stall, where it exists, is on GridHandle-side paths that construct host-side buffers, and belongs to Step 3.

  • B2 — resource ergonomics + the remaining seams (NanoVDB: SyncFromAsync, ResourceRef, and resource seams for MeshToGrid and TempPool (CUDA) #2269): SyncFromAsync<Derived> CRTP mixin (a custom resource is two methods rather than four, with the mandatory synchronize in one audited place — its first users were the two test resources in TestMemoryResource, which turned out never to have modelled the concept); a ResourceT seam for MeshToGrid, the last builder on a hard-wired DeviceResource; ResourceRef<R> per the revised ownership rule above; and TempPool's bytes onto Buffer<std::byte, ResourceRef<R>> — same pointer contract and stream retention, block freed by ownership (discard-on-growth via destroy(stream) + move-assignment; the pool keeps a size_t mirror because cub's two-pass API wants a mutable size_t&). Buffer::swap and the destroy/set_stream alignment landed in NanoVDB: inject a resource into TopologyBuilder scratch, and align cuda::Buffer with cuda::buffer (CUDA) #2268.

  • B3 — PointsToGrid: 48 sites, and the only target that is not mechanical. mData.* are device-visible raw pointers uploaded at two separate points; std::swap(d_indx, mData.d_indx) moves ownership between a local and one of those aliased fields after the first upload; a goto retry loop over voxel density makes lifetimes non-lexical; and allocations are freed across three exit paths ~500 lines apart. Wants a written ownership design plus a separate goto-to-while prep commit before the RAII change. Sequenced after NanoVDB: encode points for any resource in PointsToGrid (CUDA) #2244, which edits the same function.

  • B4 — builders on a synchronous resource (NanoVDB: run the builders on a synchronous memory resource (CUDA) #2272): MallocResource (synchronous cudaMalloc/cudaFree, works on pool-less devices) + AsyncFromSync<R> per the rule above. Closes the scratch half of the acceptance criterion as pure library code — PointsToGrid<BuildT, AsyncFromSync<MallocResource>>, no build flags. The grid handle's buffer still needs NANOVDB_USE_SYNC_CUDA_MALLOC until Step 3 delivers GridHandle<cuda::Buffer<std::byte,R>>. Tested by driving PointsToGrid end-to-end on an injected stateful synchronous resource with balanced accounting.

  Splitting matters more than usual here because NanoVDB: please run the CUDA unit tests on a GPU in CI #2264 means no CUDA test runs on a GPU in CI, so a mistake in the intricate conversion would land unverified by review. Additive throughout. Acceptance criterion (from Issue with DeviceResource (cudaMallocAsync) on vGPU without memory pool support #2255): NanoVDB builds and runs on a pool-less vGPU (cudaDevAttrMemoryPoolsSupported == 0, e.g. AWS g6f) via an injected synchronous cudaMalloc-backed resource; interim coverage via the NANOVDB_USE_SYNC_CUDA_MALLOC macro (the caller's explicit opt-in). The util::cuda wrappers deliberately do not silently fall back: on a pool-less device they fail with an actionable diagnostic (NanoVDB: fail with an actionable diagnostic when CUDA memory pools are unavailable #2256) rather than making an async resource misrepresent its semantics; CI detects the capability with a cudaDevAttrMemoryPoolsSupported probe and sets the macro.

• Step 3 — single-space grid storage, via deprecation (end state: GridHandle<cuda::Buffer<std::byte,R>> directly — one buffer per handle, no dual surface, cross-space via copyTo; GridHandle over BufferView for externally owned blobs):

  • Introduce: ship the single-space handle path; re-implement the legacy cuda::DeviceBuffer internally as a composition of two cuda::Buffers (transparent — same API, gains the pinned-host fix); migrate NanoVDB's own internal uses + tests/examples off the DeviceBuffer name so the later deprecation fires only externally.
  • Deprecate: using DeviceBuffer [[deprecated]] = <impl> + [[deprecated]] on the dual GridHandle/NodeManager methods (deviceUpload/deviceDownload/deviceGrid/deviceData). Both still compile; warnings external only. Soak one or two releases.
  • Remove: delete the dual buffer + dual surface + hasDeviceDual; flip entry-point defaults to single-space. The break lands here, after the window, only for code that didn't migrate.
  • Direction of adaptation (rule of record): cuda::Buffer is the type the legacy buffers are being replaced by, so it keeps the interface we want to live with — the cuda::buffer-aligned spelling — and GridHandle/NodeManager adapt to it. Not the reverse: legacy names are not accreted onto cuda::Buffer merely because HostBuffer/DeviceBuffer/UnifiedBuffer carry them, since those three are being deleted. Concretely, GridHandle should move to destroy() and empty() rather than cuda::Buffer gaining clear() and isEmpty() permanently. Where a shim is genuinely needed to survive the deprecation window it is marked transitional at the declaration, naming what replaces it and when it goes — as cuda::Buffer::clear is in NanoVDB: inject a resource into TopologyBuilder scratch, and align cuda::Buffer with cuda::buffer (CUDA) #2268. This applies to every spelling the window might otherwise drag across: isEmpty, deviceData, deviceUpload, deviceDownload, create.
  • Known gap: GridHandle::copy() calls mBuffer.isEmpty(), which cuda::Buffer and BufferView do not provide (they have empty()). It is latent today because copy() is only instantiated on use, but it blocks the end state. Per the rule above the fix is in GridHandle, not in cuda::Buffer — and it needs more than a rename regardless, since copy() also calls OtherBufferT::create(...) and performs a host-side std::memcpy over the buffer contents, neither of which is valid for device memory.

• Candidate — capacity-bounded, sync-free (graph-capturable) build path: graph capture prohibits host logic on device-computed values, and PointsToGrid reads count reductions back to size allocations and launch dimensions — so building cannot be captured regardless of allocator (cf. NVIDIA/warp Remove Boost UUID #1606, which reimplemented grid building privately for exactly this reason). Sketch: caller-supplied capacity bounds; one up-front allocation through the injected resource or into caller-owned memory via BufferView; launch dimensions from capacity; counts consumed on device; optional deferred readback. Requirements gathered from the Warp team: an overflow-clamped grid must remain safe to traverse from the root (orphaned leaves are acceptable — safety, not full well-formedness); point-mask support is required; a CPU counterpart is a plus (single-source maintenance); build performance must not regress; capacity-growth policy stays with applications. The memory seam is the prerequisite infrastructure; this is its own item.

• Step 4 — optional CCCL adapter (gated on availability): native cuda::mr / cuda::buffer interop, cuda::std::span conversions, and runtime (resource_ref) selection.

Migration note — custom ResourceT contract

Releases v12.1.0–v13.0.0 accepted a custom resource with static allocateAsync(bytes, alignment, stream) / deallocateAsync(...). Since #2231, builders call instance methods, and the concept now matches CCCL's refinement as described above. The static methods on cuda::DeviceResource are deprecated and will be removed after a deprecation window. Migrating a v13-era custom resource is mechanical: drop static, rename to the snake_case instance forms, add the two-line sync delegates (~8 lines total — see cuda/DeviceResource.h for the reference shape).

Downstream payoff (fvdb-core)

fvdb deletes its three forked headers and writes a small TorchAllocatorResource (forwarding to c10::cuda::CUDACachingAllocator), then uses PointsToGrid<…, TorchAllocatorResource> or GridHandle<cuda::Buffer<std::byte, TorchAllocatorResource>>; ONNX Runtime kernels wrap ORT-owned grid blobs zero-copy via GridHandle<BufferView<std::byte>>. No fork, no patch fragility.

[harrism]

Two follow-ups filed out of this effort: #2264 (CUDA unit tests are built but never executed in CI) and #2265 (cudaCheck calls exit(), including from destructors during shutdown). Both affect the injectable-resource work — #2264 because no device-side behaviour in DeviceResource/TempPool/cuda::Buffer is verified before merge, #2265 because DeviceResource::deallocate_async is on the teardown path that misreports cudaErrorCudartUnloading as fatal.

[harrism]

Step 4 note: cuda::mr has two live spellings, and we can satisfy both

Edit: an earlier revision of this comment described the split as "toolkit vs standalone CCCL". That was wrong — it is a CCCL version split. Corrected below, with the boundary pinned.

While reviewing the resource concept I checked our shape against CCCL and found that there are currently two incompatible cuda::mr spellings in the wild, depending on CCCL version. This affects the roadmap's premise that "method/type shapes match CCCL, so a resource_ref / cuda::buffer adapter is a thin shim later."

The boundary

The rename landed in CCCL commit dd218ad8 (2025-08-05), PR #5313 — "Rename memory resource concepts to indicate asynchronous allocations are the default ones" — and first shipped in CCCL v3.1.0 (2025-10-14). Verified by inspecting libcudacxx/include/cuda/__memory_resource/resource.h at each tag: v3.0.0 has no allocate_sync; v3.1.0 onward does. It is not behind an experimental define in v3.1.0.

	CCCL < 3.1.0	CCCL >= 3.1.0
synchronous concept	resource	synchronous_resource
synchronous methods	allocate(bytes, align)	allocate_sync(bytes, align)
stream-ordered concept	async_resource	resource
stream-ordered methods	allocate_async(bytes, align, stream) — stream last	allocate(stream, bytes, align) — stream first
refinement	async_resource requires resource	resource requires synchronous_resource
also required	equality_comparable<R>	equality_comparable<R>

Our current shape matches the pre-3.1.0 spelling exactly — allocate/allocate_async with stream last, is_resource/is_async_resource mirroring resource/async_resource, async refining sync.

For reference, CUDA 12.6 bundles CCCL 2.5.0 (CUB_VERSION/THRUST_VERSION = 200500), i.e. pre-rename. From /usr/local/cuda-12.6/include/cuda/__memory_resource/resource.h:

_LIBCUDACXX_CONCEPT_FRAGMENT(__async_resource_, ...
    requires(resource<_Resource>),
    __res.allocate_async(__bytes, __alignment, __stream),
    __res.deallocate_async(__ptr, __bytes, __alignment, __stream));

I have not established the full CUDA-Toolkit-to-bundled-CCCL map; CCCL's README documents the support policy (CCCL 2.x supports CTK 11.1-11.8 and 12.x; CCCL 3.x supports CTK 12.x and 13.x) but not a per-toolkit table, and 12.6 is the only toolkit I could inspect directly. Someone with a CUDA 13 install could settle it in one command:

grep -h "define CUB_VERSION" $CUDA_HOME/include/cub/version.cuh

Importantly, the toolkit version does not determine the answer anyway: CCCL explicitly supports upgrading independently of the CTK ("you can upgrade CCCL independently of the entire CUDA Toolkit"), so the same toolkit can present either spelling depending on what the user has on their include path. That argues for feature detection rather than any version check.

There is also no compatibility alias: in CCCL main, allocate_async survives only as __allocate_async(_Resource&, stream_ref, size_t, size_t), an internal double-underscore helper for type-erased dispatch in any_resource.h, with stream first. Code written against the old public names does not compile against CCCL >= 3.1.0.

One gap that is independent of naming

Both spellings require cuda::std::equality_comparable<Resource>. Our is_resource / is_async_resource check only the allocate/deallocate members. So a resource can satisfy our traits and still fail CCCL's concept for want of operator==. Worth closing whenever we touch the traits — operator== on a memory resource has real meaning ("memory allocated by x may be deallocated by y"), so it is not merely a formality.

Proposal: speak both dialects rather than pick one

The only name collision between the two spellings is allocate, and the two overloads differ in arity — allocate(bytes, align) vs allocate(stream, bytes, align). So a single type can expose all four method names with no ambiguity:

struct BothDialects {
    // pre-3.1.0 spelling
    void* allocate(size_t bytes, size_t align);
    void* allocate_async(size_t bytes, size_t align, cudaStream_t s);
    // >= 3.1.0 spelling
    void* allocate_sync(size_t bytes, size_t align);
    void* allocate(::cuda::stream_ref s, size_t bytes, size_t align);
};

r.allocate(1024, 256);          // 2 args -> resolves to the synchronous overload
r.allocate(s, 1024, 256);       // 3 args -> resolves to the stream-ordered overload

I compiled and ran this with each overload returning a distinct sentinel: the 2-argument call reaches the synchronous overload and the 3-argument call reaches the stream-ordered one, as intended. Concepts only require presence, so the extra members are free. That means no CCCL version detection is needed in the resources themselves. Three small pieces:

1. Add modern-dialect forwarders to our own resources, so DeviceResource/PinnedResource satisfy both spellings natively with no adapter:

   void* allocate_sync(size_t b, size_t a)                  { return allocate(b, a); }
   void  deallocate_sync(void* p, size_t b, size_t a)       { deallocate(p, b, a); }
   void* allocate(::cuda::stream_ref s, size_t b, size_t a) { return allocate_async(b, a, s.get()); }
   void  deallocate(::cuda::stream_ref s, void* p, size_t b, size_t a) { deallocate_async(p, b, a, s.get()); }

2. ResourceAdapter<R> that detects the wrapped type's dialect and re-exposes all of them, so a foreign resource (RMM, CCCL >= 3.1.0, Torch) can be injected into NanoVDB. This is the direction that matters most for the downstream story.

3. A SyncFromAsync<Derived> CRTP mixin, so a custom-resource author writes two methods rather than four. DeviceResource::allocate already contains exactly this logic — allocate on the null stream, then cudaStreamSynchronize. Factoring it out puts the synchronize in one audited place instead of leaving each author to rediscover it; omitting it yields memory that satisfies the concept but is not actually synchronous, which fails silently. The migration note currently says "add the two-line sync delegates" without mentioning the synchronize.

The only conditional compilation needed is around the members that mention cuda::stream_ref, since that needs a CCCL header — #if __has_include(<cuda/stream_ref>), i.e. feature detection, which as noted above is the only reliable approach here.

Not yet verified

• My overload test used a stand-in for cuda::stream_ref; the local toolkit ships pre-rename CCCL, so I could not compile against the new concept. Worth a scratch build asserting static_assert(cuda::mr::resource<DeviceResource>) against CCCL >= 3.1.0 before committing to this.
• The CTK-to-CCCL version map, as described above.

This is all Step 4 and independent of the Step 2 retrofit, so nothing here blocks that work.

[harrism]

Audit: cuda::Buffer / BufferView vs CCCL cuda::buffer

Following the resource-concept finding above, I did a member-by-member comparison of what #2251 shipped against CCCL's cuda::buffer (libcudacxx/include/cuda/__container/buffer.h, main). Summary: one semantic divergence, two naming mismatches, and a NanoVDB-internal inconsistency. Nothing blocking, but the cost of changing any of it rises with every new consumer.

1. setStream vs set_stream — documented opposite semantics

This is the one that matters most, because it is not a naming question.

	documented behaviour
NanoVDB setStream	"Replaces the retained stream without synchronizing; the caller is responsible for ordering stream after any in-flight work"
CCCL set_stream	"Always synchronizes with the old stream"

Same purpose, opposite contract. An adapter that maps one onto the other silently changes whether a synchronization occurs — a race, not a compile error.

Caveat: CCCL's implementation calls __buf_.set_stream_unsynchronized(__new_stream), which contradicts its own @note. Resolved: the doc is the stale half — NVIDIA/cccl#5697 removed the synchronization deliberately ("avoid implicit synchronization in fundamental primitives") and left the @note behind (reported as NVIDIA/cccl#10649). Our non-synchronizing set_stream therefore matches cuda::buffer in name and contract, and the semantic-divergence row above is closed.

2. Naming

NanoVDB	CCCL	note
clear()	destroy() and destroy(stream)	different name, and we lack the stream overload
setStream()	set_stream()	camelCase vs snake_case
stream(), data(), size(), empty()	same	match

On clear vs destroy — to answer the obvious question, this is not CCCL drift. The buffer type moved from cudax to libcu++ in #6627 (2025-12-01) and clear/reset have never appeared in that header. The names simply differ.

setStream is worth a second look against this issue's own rule:

Member names keep the standard spelling (data, size, size_bytes, allocate_async) because member matching is structural and cannot be aliased.

We applied that to the resource concept — deliberately keeping allocate_async in snake_case against house style — and then used setStream on the next type. The rule was applied to resources but not to Buffer.

3. Members in CCCL, not in ours

swap, memory_resource(), alignment(), subspan/first/last, get_unsynchronized(), plus iterators and element access (begin/end/at/front/back). The last group is arguably N/A — those serve host-accessible buffers, and ours are device-only.

swap is the notable omission: the generic std::swap already does the right thing on our Buffer (measured: 0 allocations, 0 frees, pointers and sizes exchanged, because the move operations are correct), but std::vector and rmm::device_buffer both provide a dedicated swap, and the B3 retrofit leans on swapping owners as its central idiom.

4. Members in ours, not in CCCL

size_bytes(), resize(), copy() — all zero occurrences in CCCL's buffer. Extras do not break concept satisfaction, so these are harmless in themselves.

resize() is worth watching: CCCL landed "Implement internal resizable buffer" (#10221) on 2026-07-29, so a public resize may be coming and may not match our signature.

5. A NanoVDB-internal inconsistency

BufferView::clear() detaches the view and frees nothing; Buffer::clear() frees. Same name, same header, opposite consequences, and std::span has no such method to anchor the meaning. Worth fixing regardless of what is decided about CCCL alignment — perhaps BufferView::reset(), or dropping it in favour of assignment from a default-constructed view.

Bearing on step 4

Taken with the resource-concept finding above, "the adapter is a thin shim" is optimistic: it has to bridge member names, a missing overload, and a documented semantic difference, in addition to the two cuda::mr spellings. None of that is hard, but it is more than forwarding, and it argues for deciding the naming questions before more code depends on the current spellings — #2268 is the first consumer of clear().