You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When reading the section regarding devices, I stumbled upon the following note:
The only way to obtain a Device object is from the .device property on the array object, hence there is no Device object in the array API itself that can be instantiated to point to a specific physical or logical device.
I understood this, as users can never instantiate a Device object themselves.
But in the paragraph inmediately above there are sentences like:
A device=None keyword for array creation functions, which takes an instance of a Device object.
A .to_device(device) method on the array object, with device again being a Device object, to move an array to a different device.
And both require a Device object, that according to the note, can't be directly instantiated, or be obtained from elsewhere than a created array.
That's right. AFAIK the intention is to use device=a.device, i.e. when you already have a compliant array a and so you can use its device attribute. As for how to determine the device for the very first array, it is currently listed as out of scope, and each library will use its existing strategy for the choice of the default device, performing device management, etc.
We first had a separate Device object, but after discussion found that there were too many differences between libraries to make it straightforward/sensible to standardize.
For library code, typically what you want to do is:
def somefunc(x, y, ...):
device = x.device
new_array = xp.array([...], device=device)
if not x.device == y.device:
# either raise exception, or
y = y.to_device(device)
rather than using an explicit device = Device('cuda:0') or some such thing. The use of explicit devices is more appropriate for end user code, and there each library already has its own way of creating new arrays on a specific device.
As for how to determine the device for the very first array, it is currently listed as out of scope, and each library will use its existing strategy for the choice of the default device, performing device management, etc.
The use of explicit devices is more appropriate for end user code, and there each library already has its own way of creating new arrays on a specific device.
I think we should keep this issue open until we revise the description in question
The only way to obtain a `Device` object is from the `.device` property on
the array object, hence there is no `Device` object in the array API itself
that can be instantiated to point to a specific physical or logical device.
as it wasn't clear to either library developers nor end users what to do. In particular, for CuPy this implies the Device object needs to have a cpu flavor so that we can facilitate host-device transfer, a point I overlooked.
Activity
leofang commentedon Mar 30, 2021
That's right. AFAIK the intention is to use
device=a.device, i.e. when you already have a compliant arrayaand so you can use itsdeviceattribute. As for how to determine the device for the very first array, it is currently listed as out of scope, and each library will use its existing strategy for the choice of the default device, performing device management, etc.rgommers commentedon Mar 30, 2021
We first had a separate Device object, but after discussion found that there were too many differences between libraries to make it straightforward/sensible to standardize.
For library code, typically what you want to do is:
rather than using an explicit
device = Device('cuda:0')or some such thing. The use of explicit devices is more appropriate for end user code, and there each library already has its own way of creating new arrays on a specific device.rgommers commentedon Mar 30, 2021
Discussion on this API is in gh-96
emcastillo commentedon Mar 30, 2021
Crystal clear!
Thanks😄
leofang commentedon Apr 3, 2021
Feel free to reopen if you have further questions on the device aspect, @emcastillo!
leofang commentedon Sep 13, 2021
I think we should keep this issue open until we revise the description in question
array-api/spec/design_topics/device_support.md
Lines 52 to 54 in 0941067
as it wasn't clear to either library developers nor end users what to do. In particular, for CuPy this implies the
Deviceobject needs to have acpuflavor so that we can facilitate host-device transfer, a point I overlooked.