Open wdamon-intel opened 9 months ago
@wdamon-intel : we have this table in the Memory section https://spec.oneapi.io/level-zero/latest/core/PROG.html#memory
Name | Initial Location | Accessible By | | Migratable To | -- | -- | -- | -- | -- | -- Host | Host | Host | Yes | Host | N/A |||Any Device | Yes (perhaps over PCIe) | Device | No Device | Specific Device | Host | No | Host | No |||Specific Device | Yes | Device | N/A |||Another Device | Optional (may require p2p) | Another Device | No Shared | Host, Specific Device, or Unspecified | Host | Yes | Host | Yes |||Specific Device | Yes | Device | Yes |||Another Device | Optional (may require p2p) | Another Device | Optional Shared System | Host | Host | Yes | Host | Yes |||Device | Yes | Device | YesA
This table defines what accessible means, including P2P access. If there's any need to clarify the behavior of zeCopy operations, then either a link to the table can be posted on each of those interfaces, or a section in programming guide needs to make clearer.
Currently, the spec reads:
However, it is easy to misunderstand "accessible" to have a more-narrow-than-intended meaning, especially when coming from the perspective of another popular compute API.
The suggestion here is to modify the spec language to clarify that the device which will be doing the transfer understands both the source and destination pointers, including in peer-to-peer access scenarios. For example,
This might also be something to clarify for the other APIs that accept a source and destination pointer that uses similar language in the spec.