|
1 | 1 | # Data interchange mechanisms
|
| 2 | + |
| 3 | +This section discusses the mechanism to convert one type of array into another. |
| 4 | +As discussed in the :ref:`assumptions-dependencies <Assumptions>` section, |
| 5 | +_functions_ provided by an array library are not expected to operate on |
| 6 | +_array types_ implemented by another library. Instead, the array can be |
| 7 | +converted to a "native" array type. |
| 8 | + |
| 9 | +The interchange mechanism must offer the following: |
| 10 | + |
| 11 | +1. Device support. It must be possible to determine on what device the array |
| 12 | + that is to be converted lives. |
| 13 | + _Rationale: there are CPU-only, GPU-only, and multi-device array types; |
| 14 | + it's best to support these with a single protocol (with separate |
| 15 | + per-device protocols it's hard to figure out unambiguous rules for which |
| 16 | + protocol gets used, and the situation will get more complex over time |
| 17 | + as TPU's and other accelerators become more widely available)._ |
| 18 | +2. Moving data from one device to another must raise by default, and be |
| 19 | + explicitly enabled by the user. |
| 20 | + _Rationale: data transfer is typically very expensive, and hence must not |
| 21 | + happen silently._ |
| 22 | +3. Zero-copy semantics where possible, making a copy only if needed (e.g. |
| 23 | + when data is not contiguous in memory). |
| 24 | +4. A stable C ABI. |
| 25 | + _Rationale: all prominent existing array libraries are implemented in |
| 26 | + C/C++, and are released independently from each other. Hence a stable C |
| 27 | + ABI is required for packages to work well together._ |
| 28 | + |
| 29 | +The best candidate for this protocol is DLPack. See the |
| 30 | +[RFC to adopt DLPack](https://github.com/data-apis/consortium-feedback/issues/1) |
| 31 | +for details. |
| 32 | + |
| 33 | +TODO: design an appropriate Python API for DLPACK (`to_dlpack` followed by `from_dlpack` is a little clunky, we'd like it to work more like the buffer protocol does on CPU, with a single constructor function). |
| 34 | + |
| 35 | +TODO: specify the expected behaviour with copy/view/move/shared-memory semantics in detail. |
0 commit comments