Clarify what accessible means for zeCommandListAppendMemoryCopy

[wdamon-intel]

Currently, the spec reads:

The application must ensure the memory pointed to by dstptr and srcptr is accessible by the device on which the command list was created.

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,

The application must ensure the memory pointed to by dstptr and srcptr is accessible by the device on which the command list was created. This may include peer-to-peer access where available.

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.

[jandres742]

@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	Yes

A

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.