Skip to content

Commit 99b157e

Browse files
committed
Add data interchange section, using DLPack
This is incomplete, but there seems to be agreement that DLPack is the best candidate for an interchange mechanism. So let's document that, and improve the content as we go. See data-apis/consortium-feedback#1 for the RFC about standardizing on DLPack. Design discussion should be picked up there.
1 parent f801759 commit 99b157e

File tree

2 files changed

+36
-0
lines changed

2 files changed

+36
-0
lines changed

spec/assumptions.md

Lines changed: 2 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -18,6 +18,8 @@ made in the API standard. For example, JIT compilers may require output dtypes
1818
of functions to be predictable from input dtypes only rather than input values.
1919

2020

21+
.. _assumptions-dependencies:
22+
2123
## Dependencies
2224

2325
The only dependency that's assumed in this standard is that on Python itself.
Lines changed: 34 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1 +1,35 @@
11
# 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

Comments
 (0)