As part of the cuda::mr refactoring, eventually there will be no device_memory_resource base class on the C++ side, instead everything will use the relevant type-erased concepts.
In cython, we currently map device_memory_resource onto a cdef DeviceMemoryResource base class that is responsible for keeping the C++ mr alive:
cdef class DeviceMemoryResource:
shared_ptr[device_memory_resource] mr
cdef device_memory_resource *get_mr(self)
The get_mr function is used when we need to pass the mr pointer into a C++ API.
There is, in addition, a class hierarchy that builds the various adaptor mrs on top of this (pool, logging, etc...). But this doesn't rely particularly on the existing C++ class hierarchy except that every C++ adaptor mr is-a device_memory_resource (and so can be stored in the same shared_ptr struct slot). This ability goes away once the inheritance disappears on the C++ side.
Tasks
As part of the
cuda::mrrefactoring, eventually there will be nodevice_memory_resourcebase class on the C++ side, instead everything will use the relevant type-erased concepts.In cython, we currently map
device_memory_resourceonto a cdefDeviceMemoryResourcebase class that is responsible for keeping the C++ mr alive:The
get_mrfunction is used when we need to pass the mr pointer into a C++ API.There is, in addition, a class hierarchy that builds the various adaptor mrs on top of this (pool, logging, etc...). But this doesn't rely particularly on the existing C++ class hierarchy except that every C++ adaptor mr
is-adevice_memory_resource(and so can be stored in the sameshared_ptrstruct slot). This ability goes away once the inheritance disappears on the C++ side.Tasks