[dpnp.array] Attributes `.data` and `.data.ptr` for dpnp array

[abagusetty]

Hi, I've encountered a use case from porting a CuPy-based project on ALCF Aurora and was wondering if we can support a similar in functionality to access a dpnp.array with attributes data and .data.ptr.

import dpnp
a = dpnp.array([1, 2, 3])
print(type(a))
print(hasattr(a, 'data'))  # True for cupy
print(hasattr(a.data, 'ptr'))  # True for cupy, False for numpy
print(a.data.ptr)  # Integer (CUDA memory address)

[vtavana]

You can get the pointer of an array using get_array()._pointer.
get_array() returns the usm_ndarray and _pointer returns its memory address.

For example,

import dpnp
a = dpnp.array([1, 2, 3])
a.get_array()._pointer
# 18446664917462351872

[abagusetty]

Thanks that worked. Just wondering, if would consider to support the above attributes to have similar semantics with cupy. Usually in an application code we can map a lot of usage like these quite easily without source code modifications.

[antonwolfy]

The point is that the data attribute is a highly implementation-dependent entity. It doesn't seem to be an unified interface.
NumPy returns memoryview here, while CuPy returns cupy.cuda.MemoryPointer object. And both has the different set of attributes.

We can consider adding data attribute for dpnp ndarray where dpnp will return an object with USM memory allocation instead.
It will have a bit different set of attributes then:

a.data
# Out: <SYCL(TM) USM-device allocation of 24 bytes at 0x5843332a0a00>

dir(a.data)
# Out:
# ['__bytes__',
#  '__class__',
#  '__delattr__',
#  '__dir__',
#  '__doc__',
#  '__eq__',
#  '__format__',
#  '__ge__',
#  '__getattribute__',
#  '__getstate__',
#  '__gt__',
#  '__hash__',
#  '__init__',
#  '__init_subclass__',
#  '__le__',
#  '__len__',
#  '__lt__',
#  '__ne__',
#  '__new__',
#  '__pyx_vtable__',
#  '__reduce__',
#  '__reduce_ex__',
#  '__repr__',
#  '__setattr__',
#  '__sizeof__',
#  '__str__',
#  '__subclasshook__',
#  '__sycl_usm_array_interface__',
#  '_context',
#  '_pointer',
#  '_queue',
#  'copy_from_device',
#  'copy_from_host',
#  'copy_to_host',
#  'get_usm_type',
#  'get_usm_type_enum',
#  'memset',
#  'nbytes',
#  'reference_obj',
#  'size',
#  'sycl_context',
#  'sycl_device',
#  'sycl_queue',
#  'tobytes']

In general, we can also consider extending USM memory class with a.data.ptr attribute which will return the same value as already existing a.data._pointer attribute, i.e. an integer with USM memory address, if it works for you.

[abagusetty]

@antonwolfy Thanks for taking into consideration. Yes, it would absolutely be a better option. IMO, specifically the apps for Intel PVCs on Aurora with porting from CUPY might find it a better solution more than the users from numpy to dpnp.

Are these mappings still converge to the same underlying pointer a.data.ptr , a.data._pointer and a.get_array()._pointer (i.e. an integer with USM memory address). Just curious if any attribute needs to be deprecated for removal with this consideration

[antonwolfy]

The proposal is that all of these attributes a.data.ptr , a.data._pointer and a.get_array()._pointer will hold the same value (an integer with USM memory address).
The reason is that _pointer attributes are already present and provided by dpctl. dpnp will leverage on that and the new ptr attribute will be added only to simplify the migration from the CuPy.