cuda-api-wrappers

cuda-api-wrappers copied to clipboard

We currently have more than a few wrappers taking a void* and a num_bytes or size_in_bytes etc. Instead, why not use spans?

And if we do that, perhaps we could/should use spans elsewhere, where we now just use pointers.

The GSL implementation here https://github.com/microsoft/GSL does not consider to be CUDA compatible (https://github.com/microsoft/GSL/issues/544). But the GSL-Lite https://github.com/martinmoene/gsl-lite is currently open for changes and development and fully CUDA compatible. So if you plan to use spans I recommend using GSL-Lite. Nevertheless I would really think about if this project should have this dependency.

@codecircuit : I think I got the gsl-lite guy to make it CUDA-compatible, actually. But I vaguely recall there was some issue with it. At the very least, it's a single huge header file one would need to include.

If we were to do this, it would probably be with a sort of a back-porting of C++20 spans to be CUDA C++11-compatible...

Me and my collegue work on the gsl-lite. I use it in every project and it should be fully CUDA compatible right now. No porting of any kind should be necessary.

I would not include the complete header of the gsl-lite into this project, but rather write it down as a CMake dependency:

find_package(gsl-lite REQUIRED)
target_link_libraries(cuda-api-wrappers PUBLIC gsl::gsl-lite)

see here https://github.com/martinmoene/gsl-lite#as-cmake-package

Is gsl-lite's span, as of right now, a conformant implementation of C++20's std::span ?

It isn't: it doesn't yet support fixed-size spans, it has operations that were deliberately left out for std::span<> (e.g. comparison), and some small things are missing or named differently.

I plan to make it conformant, but that will be an ABI-breaking change (because we need a second template parameter), and hence something that will probably happen in the next major-version release.