numba: __cuda_array_interface__ is not compliant with the standard

UPDATE: reporting two issues on __cuda_array_interface__

First, currently it’s impossible for 'strides' to be None, and it is always there instead of being optional:

https://github.com/numba/numba/blob/a97dc18f3e5d69429949e557bc98ec513f81b04c/numba/cuda/cudadrv/devicearray.py#L120

If the array is C contiguous, as in most cases, this is not complying with the standard:

The following are optional entries:

  • strides: None or (integer, …) A tuple of int (or long) representing the number of bytes to skip to access the next element at each dimension. If it is None, the array is assumed to be in C-contiguous layout.

Second, if the input is a 0-size array, the device pointer given by Numba’s __cuda_array_interface__['data'][0] is None. But this leads to an error when accessing the pointer on the C/Cython side. For example, PyLong_AsVoidPtr(None) fails, and so it requires extra logic to handle this special case. In fact, this again breaks the spec, which requires an int or long:

  • data: (integer, boolean) The data is a 2-tuple. The first element data pointer as a Python int (or long). The data must be device-accessible. The second element is the read-only flag as a Python bool.

I suggest to revise the standard, as currently this edge case is not clearly defined. Relevant to #4140. By the way, CuPy uses 0 for this case (cupy/cupy#2104), which makes perfect sense at the C level.

About this issue

  • Original URL
  • State: closed
  • Created 5 years ago
  • Comments: 23 (18 by maintainers)

Commits related to this issue

Most upvoted comments

@leofang thanks a lot for working on that!

Yes indeed @leofang, thanks for your efforts on this, much appreciated.

Sorry for not replying earlier. Yes, I agree the patch looks good, I think this addresses our previous discussion.

@leofang thanks a lot for working on that!

I agree with @leofang suggestion to revise the standard. I think the missing information on contiguity makes it unnecessarily harder and more error prone for developers to parse that information correctly. In that sense, I would suggest that strides becomes a mandatory field, as well as a new field on contiguity (or two field c_contiguous and f_contiguous, as NumPy implements it).

I haven’t myself dealt the None pointer issue, but also agree to @leofang’s comments on revising that.