[FEA] Method to copy device_buffer to host

[jakirkham]

Is your feature request related to a problem? Please describe.

Currently device_buffer is able to construct itself using memory on the host. It would be useful to do the opposite. Namely have a method to copy data back to the host in some buffer.

Describe the solution you'd like

A method like copy_to_host that returns something (maybe std::string?) that has a copy of the data from the device_buffer now on the host.

Describe alternatives you've considered

Users could probably do this themselves using device_buffer directly.

Additional context

This would be helpful not only at the C++ level, but also in Python where we would want an analogous feature (maybe tobytes?).

cc @kkraus14 @shwina

[jrhemstad]

The biggest impediment to this would be what would this return? std::string isn't really appropriate. Neither is std::vector<char>. So it probably requires creating a new class in RMM like host_buffer, which opens a sizable can of worms, similar to the issues I described here: #141 (comment)

rmm::host_buffer is certainly possible, it would just require quite a bit of new supporting infrastructure, which would likely require redesign/refactoring of existing infrastructure.

[harrism]

Well, the expedient thing would be to add a method like:

device_buffer::copy_to_host( void* host_buffer);

It's a kind of halfway-between-C-and-C++ solution that basically is just a wrapper around cudaMemcpy. The user is responsible for allocating and owning host_buffer to the size returned by device_buffer::size().

[jakirkham]

If it's non-trivial to add in the C++ layer, we can workaround its absence in the Python layer. Just would be nice to have a plan for alignment so they don't get too far apart.

[harrism]

Look, I'm OK with adding my suggested API (which is trivial) because it is congruent with the constructor that takes a void pointer (as you mentioned in the initial request, @jakirkham ). But I want to give @jrhemstad the opportunity to oppose that approach if he has a strong opinion.

[jrhemstad]

Look, I'm OK with adding my suggested API (which is trivial) because it is congruent with the constructor that takes a void pointer (as you mentioned in the initial request, @jakirkham ). But I want to give @jrhemstad the opportunity to oppose that approach if he has a strong opinion.

I have no problem with a free function that looks like:

void to_host(rmm::device_buffer const& b, void * host_buffer);

It would be a pretty minimal wrapper around cudaMemcpy, but if people think that's useful, then I've no quarrel with that.

[jakirkham]

That would be great. Would it be possible for it to perform error handling as well?

[jrhemstad]

That would be great. Would it be possible for it to perform error handling as well?

Yes, it can throw an exception if host_buffer is null or if the cudaMemcpy fails.

[harrism]

@jakirkham how about submitting a PR? :)

[jakirkham]

Happy to. Submitted PR ( #219 ) to start the conversation.

Am a bit rusty on my C++, so advice welcome there. In particular could use some help on figuring out where tests should go.