-
Notifications
You must be signed in to change notification settings - Fork 734
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[SYCL][DOC] Initial commit of oneapi extension proposal for adding P2P #6104
Merged
Merged
Changes from all commits
Commits
Show all changes
14 commits
Select commit
Hold shift + click to select a range
19bc35a
Initial commit of oneapi extension proposal for adding Peer-to-Peer m…
jbrodman 96ff0cc
Update based on feedback
jbrodman 164f462
Updates based on feedback, round 2
jbrodman 2eb8ff8
Update sycl/doc/extensions/proposed/sycl_ext_oneapi_peer_access.asciidoc
jbrodman e3b12fc
Feedback vol 3
jbrodman 15e306d
Merge branch 'sycl' of github.com:intel/llvm into ext_p2p
jbrodman 410d806
fix merge
jbrodman d28af85
Update sycl/doc/extensions/proposed/sycl_ext_oneapi_peer_access.asciidoc
jbrodman 0c4d39d
Update sycl/doc/extensions/proposed/sycl_ext_oneapi_peer_access.asciidoc
jbrodman ab8625e
Update sycl/doc/extensions/proposed/sycl_ext_oneapi_peer_access.asciidoc
jbrodman 006dd20
Adjust wording based on feedback and bump SYCL spec rev
jbrodman 2329d71
Update sycl/doc/extensions/proposed/sycl_ext_oneapi_peer_access.asciidoc
jbrodman 232ce60
Update sycl/doc/extensions/proposed/sycl_ext_oneapi_peer_access.asciidoc
jbrodman 549ce0d
Remove enabled query as it's uncclear any backend really supports it
jbrodman File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
163 changes: 163 additions & 0 deletions
163
sycl/doc/extensions/proposed/sycl_ext_oneapi_peer_access.asciidoc
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,163 @@ | ||
= sycl_ext_oneapi_peer_access | ||
|
||
:source-highlighter: coderay | ||
:coderay-linenums-mode: table | ||
|
||
// This section needs to be after the document title. | ||
:doctype: book | ||
:toc2: | ||
:toc: left | ||
:encoding: utf-8 | ||
:lang: en | ||
:dpcpp: pass:[DPC++] | ||
|
||
// Set the default source code type in this document to C++, | ||
// for syntax highlighting purposes. This is needed because | ||
// docbook uses c++ and html5 uses cpp. | ||
:language: {basebackend@docbook:c++:cpp} | ||
|
||
|
||
== Notice | ||
|
||
[%hardbreaks] | ||
Copyright (C) 2022-2023 Intel Corporation. All rights reserved. | ||
|
||
Khronos(R) is a registered trademark and SYCL(TM) and SPIR(TM) are trademarks | ||
of The Khronos Group Inc. OpenCL(TM) is a trademark of Apple Inc. used by | ||
permission by Khronos. | ||
|
||
|
||
== Contact | ||
|
||
To report problems with this extension, please open a new issue at: | ||
|
||
https://github.com/intel/llvm/issues | ||
|
||
|
||
== Dependencies | ||
|
||
This extension is written against the SYCL 2020 revision 6 specification. All | ||
references below to the "core SYCL specification" or to section numbers in the | ||
SYCL specification refer to that revision. | ||
|
||
== Status | ||
|
||
This is a proposed extension specification, intended to gather community | ||
feedback. Interfaces defined in this specification may not be implemented yet | ||
or may be in a preliminary state. The specification itself may also change in | ||
incompatible ways before it is finalized. *Shipping software products should | ||
not rely on APIs defined in this specification.* | ||
|
||
|
||
== Overview | ||
|
||
This extension adds support for mechanisms to query and enable support for | ||
memory access between peer devices in a system. | ||
In particular, this allows one device to access USM Device allocations | ||
for a peer device. This extension does not apply to USM Shared allocations. | ||
Peer to peer capabilities are useful as they can provide | ||
access to a peer device's memory inside a compute kernel and optimized memory | ||
copies between peer devices. | ||
|
||
== Specification | ||
|
||
=== Feature test macro | ||
|
||
This extension provides a feature-test macro as described in the core SYCL | ||
specification. An implementation supporting this extension must predefine the | ||
macro `SYCL_EXT_ONEAPI_PEER_ACCESS` to one of the values defined in the table | ||
below. Applications can test for the existence of this macro to determine if | ||
the implementation supports this feature, or applications can test the macro's | ||
value to determine which of the extension's features the implementation | ||
supports. | ||
|
||
[%header,cols="1,5"] | ||
|=== | ||
|Value | ||
|Description | ||
|
||
|1 | ||
|Initial version of this extension. | ||
|=== | ||
|
||
|
||
=== Peer to Peer (P2P) Memory Access APIs | ||
|
||
This extension adds support for mechanisms to query and enable support for | ||
direct memory access between peer devices in a system. | ||
In particular, this allows one device to directly access USM Device | ||
allocations for a peer device in the same context. | ||
Peer to peer capabilities are useful as they can provide access to a peer | ||
device's memory inside a compute kernel and also optimized memory copies between | ||
peer devices. | ||
|
||
This extension adds the following new member functions to the device class, as described | ||
below. | ||
|
||
[source,c++] | ||
---- | ||
namespace sycl { | ||
namespace ext { | ||
namespace oneapi { | ||
enum class peer_access { | ||
access_supported, | ||
access_enabled, | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Oops! |
||
atomics_supported, | ||
}; | ||
} // namespace oneapi | ||
} // namespace ext | ||
|
||
class device { | ||
public: | ||
bool ext_oneapi_can_access_peer(const device &peer, | ||
ext::oneapi::peer_access value = | ||
ext::oneapi::peer_access::access_supported); | ||
void ext_oneapi_enable_peer_access(const device &peer); | ||
void ext_oneapi_disable_peer_access(const device &peer); | ||
}; | ||
|
||
} // namespace sycl | ||
---- | ||
|
||
The semantics of the new functions are: | ||
|
||
|=== | ||
|Member Function |Description | ||
|
||
|bool ext_oneapi_can_access_peer(const device &peer, | ||
ext::oneapi::peer_access value = | ||
ext::oneapi::peer_access::access_supported) | ||
a|Queries the peer access status between this device and `peer` according to | ||
the query `value`: | ||
|
||
* `ext::oneapi::peer_access::access_supported`: Returns true only if it is | ||
possible for this device to enable peer access to USM device memory allocations | ||
located on the `peer` device. | ||
|
||
* `ext::oneapi::peer_access::atomics_supported`: When this query returns true, | ||
it indicates that this device may concurrently access and atomically modify USM | ||
device memory allocations located on the `peer` device when peer access is enabled | ||
to that device. Atomics performed on a peer device's memory must have | ||
`memory_scope::system` scope. | ||
If the query returns false, attempting to concurrently access or atomically | ||
modify USM device memory located on the `peer` device results in undefined | ||
behavior. | ||
|
||
|void enable_peer_access(const device &peer) | ||
|Enables this device to access USM device allocations located on the peer | ||
device. This does not permit the peer device to access this device's memory. | ||
Once this access is enabled, SYCL kernel functions and the explicit memory | ||
functions may access USM device allocations on the peer device subject to the | ||
normal rules about context as described in the core SYCL specification. | ||
If this device does not support peer access (as defined by | ||
`peer_access::access_supported`), throws an `exception` with the | ||
`errc::feature_not_supported` error code. If access is already enabled, | ||
throws an exception with the `errc::invalid` error code. | ||
|
||
|
||
|void disable_peer_access(const device &peer) | ||
|Disables access to the peer device's memory from this device. If peer access | ||
is not enabled, throws an `exception` with the `errc::invalid` error code. | ||
|
||
|=== | ||
|
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If two devices with P2P capabilities are placed in the same context, shouldn't this be implicitly enabled?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There has been a lot of discussion about what a context means. I think our current consensus is that it does not provide any guarantee about P2P access between devices. Therefore, placing two devices in the same context does not provide any guarantee that USM memory allocated for one of those devices is accessible from another device in that same context.
See the discussion in internal Khronos issue 563.