Proposal: Replace `mdspan::data_handle()` usage to enable SCADA/BAM integration

Hello,
I have a question about potential integration between cuVS and Nvidia’s BAM.
Currently, the CAGRA implementation assumes that the entire dataset fits into DRAM. Even with CAGRA-Q, which uses quantized vectors, the scale of the dataset is limited. Therefore, I’m interested in integration between cuVS and Nvidia’s SCADA (SCaled Accelerated Data Access) programming model, and specifically the current implementation of BAM [1]. Such integration would enable building CAGRA indexes and serving queries for datasets that don’t fit into memory, utilizing SSDs.

As explained in cuVS documentation [2], the CAGRA build() function takes an argument ‘dataset’ of type 'raft::device_matrix_view'.

In raft source code [3] I can see that device_matrix_view is a template alias of mdspan<T, Extents, LayoutPolicy, AccessorPolicy>, with the last three template parameters fixed to represent a specific layout and a device memory accessor.

According to cppreference [4]: “std::mdspan is a multidimensional array view that maps a multidimensional index to an element of the array. The mapping and element access policies are configurable, and the underlying array need not be contiguous or even exist in memory at all.”

I was mostly intrigued by the part that says the underlying array doesn't have to exist in memory. It sounds like a great opportunity to incorporate Nvidia's SCADA (for example, BAM).

Such integration would be possible via smart AccessorPolicy [5], which would hide the complex logic under its access() method.

However, I can see in the current implementation of CAGRA, the mdspan accessor is never called, since the dataset is accessed via a raw pointer and pointer arithmetic.
For example, in cagra.cuh, build_knn_graph() takes an argument of dataset with type mdspan [6]. Then, build_knn_graph() iterates over the dataset vectors, but instead of accessing them directly with operator[], it calls dataset.data_handle() to get a raw pointer of the underlying in-memory array, and uses it to construct a batch_load_iterator. batch_load_iterator uses pointer arithmetic to access the vectors [7].
Calling mdspan::data_handle() degenerates the mdspan into a raw pointer, suitable for in-memory access only, and doesn't allow future optimizations like using SCADA (for example, BAM).

I have three questions:

1. General correctness: Is there an inherent issue with accessing dataset vectors via operator[] (i.e., using the AccessorPolicy’s access() method) instead of raw pointer arithmetic?
2. Performance considerations: Does invoking AccessorPolicy::access() on each element introduce a measurable overhead compared to the current data_handle() + pointer arithmetic approach on modern GPUs?
3. Roadmap and refactoring: Are there plans to refactor raft and cuVS to avoid mdspan::data_handle() and allow such integration? I’d be happy to help move such an effort forward.

Thanks,
Ron

[1] https://github.com/ZaidQureshi/bam
[2] https://docs.rapids.ai/api/cuvs/stable/working_with_ann_indexes_cpp/
[3] https://github.com/rapidsai/raft/blob/branch-25.08/cpp/include/raft/core/device_mdspan.hpp#L108 ,#L37
[4] https://en.cppreference.com/w/cpp/container/mdspan.html
[5] https://en.cppreference.com/w/cpp/named_req/AccessorPolicy.html
[6] https://github.com/rapidsai/raft/blob/branch-25.08/cpp/include/raft/neighbors/cagra.cuh#L82
[7] https://github.com/rapidsai/raft/blob/branch-25.08/cpp/include/raft/spatial/knn/detail/ann_utils.cuh#L472

Start by reading the cited dataset handling in cpp/include/raft/neighbors/cagra.cuh and cpp/include/raft/spatial/knn/detail/ann_utils.cuh, then compare it with raft’s device_mdspan.hpp and the mdspan AccessorPolicy references. The issue is a proposal rather than a scoped change; done would require answering the correctness and performance questions and agreeing on a concrete refactoring roadmap for SCADA/BAM integration.