Skip to content

[SYCL][DOC] Initial commit of oneapi extension proposal for adding P2P #6104

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

Merged
merged 14 commits into from
Mar 3, 2023
Merged
Changes from 4 commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
158 changes: 158 additions & 0 deletions sycl/doc/extensions/proposed/sycl_ext_oneapi_peer_access.asciidoc
Original file line number Diff line number Diff line change
@@ -0,0 +1,158 @@
= 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-2022 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 5 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.
Copy link
Contributor

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?

Copy link
Contributor

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.

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,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

access_enabled was removed below, but not here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The 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::access_enabled`: Returns true only if peer access is
currently enabled from this device to the `peer` device.

* `ext::oneapi::peer_access::atomics_supported`: When this query returns true,
it indicates that this device may perform atomic operations on USM device memory
allocations located on the `peer` device when peer access is enabled to that
device. If the query returns false, attempting to perform atomic operations on
`peer` memory will have undefined behavior.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The core SYCL spec makes a distinction between "atomic operations" and "concurrent access". The Level Zero driver has separate queries for these two concepts. We need to clarify what atomics_supported means. I think it should mean that both atomic operations and concurrent access is supported, which is consistent with the current wording in the SYCL spec for the usm_atomic_shared_allocations aspect.

This is an area we are debating in general, though, so we may end up making two different queries for these concepts.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think concurrent access comes into play here - I think it's only (pseudocode) atomicAdd(ptr, val)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Atomic operations only make sense if two things can access the memory concurrently. I guess there are two possible interpretations for what atomics_supported means:

  1. This device and peer device can concurrently access the device USM and do atomic operations on that memory. These operations are atomic w.r.t. code running on the two devices.

  2. This device can access device USM from peer, but it cannot access it concurrently with peer. Atomic operations are supported, but only between work-items running on this device.

I was originally thinking the query meant (1), but your comment makes me think that maybe you intend (2)?

Copy link
Contributor

@Pennycook Pennycook Sep 9, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Another thing that we should pay attention to here is the concept of memory scope.

If the device and peer can use atomics to concurrently update the same memory, then both devices will need to list memory_scope::system in info::device::atomic_memory_scope_capabilities. Both devices will need to use atomics with memory_scope::system when concurrently accessing the memory to avoid a data race.

If the device is only accessing peer's memory atomically but not concurrently with peer, it can use atomics with memory_scope::device. If peer accesses the same memory concurrently, that's a data race.

I don't know whether it's better to use the atomics & concurrent distinction or to work in some concept of scope, but I agree with Greg that this needs to clarify exactly what is guaranteed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would it help to add a new extended memory scope like memory_scope::ext_oneapi_peer_devices?


|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.
This device must be in the same context as the allocations being accessed.
Throws an exception if access cannot be enabled or if access is already
enabled.

|void disable_peer_access(const device &peer)
|Disables access to the peer device's memory from this device. Throws an
exception if access cannot be disabled or if access is not enabled.

|===