alpaka
alpaka copied to clipboard
alpaka-group
std::mdspan
std::mdspan in its 14th revision passed the LEWG review last Monday, meaning its design has converged and seems to be finished for now. The paper still has to go through several votes, but I expect it to pass them, so it has a good chance of making it into C++23.
I would really like to see it in alpaka as well, maybe even with some glue code, like having a getMdspan(view) function in addition to getNativePointer(view). That would elegantly solve all the multidim buffer issues, pitches etc. std::mdspan supports various memory layouts, accessors (different from alpaka's current Accessor), slices (subspans), and works with SYCL (I asked). It is not as powerful as LLAMA, but provides a nice middle ground for many use cases.
Now I am wondering how we could include it. Kokkos has the reference implementation, which is licensed under BSD-3. The implementation has 5KLOCs. We could include it similar to TinyMT (also BSD-3) or STLTuple (Apache). We could also have it as an optional third-party dependency and enable alpaka functionality depending on whether the user has mdspan.
P.S.: I wanted to have mdspan in Alpaka the first time I read about it. Except for free index maps it is the best existing indexing solution.
I would go the dependency way.
I agree with @bussmann and would add this as a dependency instead of reimplementing it.
I agree with @bussmann and would add this as a dependency instead of reimplementing it.
The options are vendoring the library inside the alpaka source tree or putting the burden on the user to install it themselves. I did not mention reimplementing it myself as an option.
So far it looks like the big showstopper is that mdspan does not support pitched allocations. Or at least I have not yet found a way to make them work efficiently. I opened an issue at their repository and I am now waiting for their recommendations: https://github.com/kokkos/mdspan/issues/117.
Here is a different approach: Just because a user needs an n-dimensional buffer does not mean they need to allocate one. They could just as well create a 1D buffer and wrap an n-dimensional mdspan around it. That would leave both options in alpaka: using mdspan for its great API and having ND pitched buffers for special cases.