[
https://issues.apache.org/jira/browse/ARROW-2447?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16801755#comment-16801755
]
Antoine Pitrou commented on ARROW-2447:
---------------------------------------
bq. For instance, `pa.allocate_buffer(512, memory_pool=<CudaMemoryPool
instance>)` creates an arrow Buffer with device pointers.
I'm not sure that's the right approach, API-wise. What if allocating a given
buffer type requires more than just getting a pointer from the underlying
memory pool? So, rather than pass a CUDA memory pool to `pa.allocate`, it
sounds more future proof to have a dedicated `pa.cuda.allocate_buffer` (or
something).
bq. So, perhaps we should be attaching MemoryPool to the Buffer (instead of
introducing Device class) so that the accessibility of memory pointer is
determined by the MemoryPool instance which contains also the process
information.
I don't know. Getting device information in itself may be useful. Inspecting a
MemoryPool doesn't sound sufficient. Of course, perhaps the device could be
attached to the MemoryPool rather than to the Buffer itself?
You're right about accessibility information: it seems more fine-grained than I
initially assumed. It would still be worthwhile to find a solution to make uses
of Buffer are less error-prone, though. Right now the only thing that protects
the user is that CUDA buffers are hardly ever used, so you don't risk
encountering them ;-)
> [C++] Create a device abstraction
> ---------------------------------
>
> Key: ARROW-2447
> URL: https://issues.apache.org/jira/browse/ARROW-2447
> Project: Apache Arrow
> Issue Type: Improvement
> Components: C++, GPU
> Affects Versions: 0.9.0
> Reporter: Antoine Pitrou
> Assignee: Pearu Peterson
> Priority: Major
> Fix For: 0.14.0
>
>
> Right now, a plain Buffer doesn't carry information about where it actually
> lies. That information also cannot be passed around, so you get APIs like
> {{PlasmaClient}} which take or return device number integers, and have
> implementations which hardcode operations on CUDA buffers. Also, unsuspecting
> receivers of a {{Buffer}} pointer may try to act on the underlying memory
> without knowing whether it's CPU-reachable or not.
> Here is a sketch for a proposed Device abstraction:
> {code}
> class Device {
> enum DeviceKind { KIND_CPU, KIND_CUDA };
> virtual DeviceKind kind() const;
> //MemoryPool* default_memory_pool() const;
> //std::shared_ptr<Buffer> Allocate(...);
> };
> class CpuDevice : public Device {};
> class CudaDevice : public Device {
> int device_num() const;
> };
> class Buffer {
> virtual DeviceKind device_kind() const;
> virtual std::shared_ptr<Device> device() const;
> virtual bool on_cpu() const {
> return true;
> }
> const uint8_t* cpu_data() const {
> return on_cpu() ? data() : nullptr;
> }
> uint8_t* cpu_mutable_data() {
> return on_cpu() ? mutable_data() : nullptr;
> }
> virtual CopyToCpu(std::shared_ptr<Buffer> dest) const;
> virtual CopyFromCpu(std::shared_ptr<Buffer> src);
> };
> class CudaBuffer : public Buffer {
> virtual bool on_cpu() const {
> return false;
> }
> };
> CopyBuffer(std::shared_ptr<Buffer> dest, const std::shared_ptr<Buffer> src);
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
