-
Notifications
You must be signed in to change notification settings - Fork 30
Support peer access DPC++ extension #2077
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
base: master
Are you sure you want to change the base?
Conversation
da9f596
to
20e80f1
Compare
View rendered docs @ https://intelpython.github.io/dpctl/pulls/2077/index.html |
Array API standard conformance tests for dpctl=0.20.0dev0=py310h93fe807_194 ran successfully. |
Array API standard conformance tests for dpctl=0.20.0dev0=py310h93fe807_194 ran successfully. |
libsyclinterface/include/syclinterface/dpctl_sycl_device_interface.h
Outdated
Show resolved
Hide resolved
libsyclinterface/include/syclinterface/dpctl_sycl_device_interface.h
Outdated
Show resolved
Hide resolved
only implemented for backends HIP, CUDA, Level Zero. Validation prevents crashes
Peer device docstrings link to related methods and docs on peer access extension Slips in fixes to other docstrings for SyclDevice methods
More user-readable
20e80f1
to
a21d585
Compare
Array API standard conformance tests for dpctl=0.20.0dev0=py310h93fe807_199 ran successfully. |
Array API standard conformance tests for dpctl=0.20.0dev0=py310h93fe807_200 ran successfully. |
Array API standard conformance tests for dpctl=0.20.0dev0=py310h93fe807_201 ran successfully. |
Noting here that for future reference, we will probably need to document how this extension interacts with sub-devices and composite devices. For example, per composite device documentation
this means that while the peer access methods will work between composite device and its component devices, and vice versa, to actually leverage it, the user needs to explicitly construct a context containing component and composite devices. |
also make peer access invalid when the device and peer device are the same
Array API standard conformance tests for dpctl=0.20.0dev0=py310h93fe807_203 ran successfully. |
04c424b
to
5a92522
Compare
Array API standard conformance tests for dpctl=0.20.0dev0=py310h93fe807_205 ran successfully. |
1 similar comment
Array API standard conformance tests for dpctl=0.20.0dev0=py310h93fe807_205 ran successfully. |
Array API standard conformance tests for dpctl=0.20.0dev0=py310h93fe807_206 ran successfully. |
c8a6345
to
b3ead6f
Compare
Array API standard conformance tests for dpctl=0.20.0dev0=py310h93fe807_206 ran successfully. |
b3ead6f
to
3e81777
Compare
Array API standard conformance tests for dpctl=0.20.0dev0=py310h93fe807_206 ran successfully. |
3e81777
to
ba7222f
Compare
Array API standard conformance tests for dpctl=0.20.0dev0=py310h93fe807_206 ran successfully. |
Discard unused header for sstream
Array API standard conformance tests for dpctl=0.20.0dev0=py310h93fe807_211 ran successfully. |
Array API standard conformance tests for dpctl=0.20.0dev0=py310h93fe807_213 ran successfully. |
with pytest.raises(ValueError): | ||
dev.enable_peer_access(dev) | ||
with pytest.raises(ValueError): | ||
dev.enable_peer_access(dev) |
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.
dev.enable_peer_access(dev) | |
dev.disable_peer_access(dev) |
if (D && PD) { | ||
if (_CallPeerAccess(*D, *PD)) { | ||
try { | ||
throw std::invalid_argument("test"); |
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.
seems debug leftover
throw std::invalid_argument("test"); |
auto D0 = DPCTLDeviceVector_GetAt(DV, 0); | ||
ASSERT_TRUE(D1 != nullptr); | ||
bool canEnable = false; | ||
EXPECT_NO_FATAL_FAILURE(canEnable = DPCTLDevice_CanAccessPeer( |
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.
Do we need to add ASSERT_FALSE(canEnable)
after that?
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.
and probably initial value has to be true
then:
bool canEnable = true;
ASSERT_TRUE(D1 != nullptr); | ||
bool canEnable = false; | ||
EXPECT_NO_FATAL_FAILURE(canEnable = DPCTLDevice_CanAccessPeer( | ||
D0, D0, DPCTLPeerAccessType::access_supported)); |
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.
Do we need to repeat the call and check with DPCTLPeerAccessType::atomics_supported
?
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.
In general it seems access type can be also parametrized to reduce duplication, but not sure if it is easy to implement with gtest f/w.
TEST_P(TestDPCTLPeerAccess, ChkPeerAccessToSelf) | ||
{ | ||
auto D0 = DPCTLDeviceVector_GetAt(DV, 0); | ||
ASSERT_TRUE(D1 != nullptr); |
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.
ASSERT_TRUE(D1 != nullptr); | |
ASSERT_TRUE(D0 != nullptr); |
This PR adds full support for the DPC++
sycl_ext_oneapi_peer_access
extensionThis adds a Python interface to calls that check if a
dpctl.SyclDevice
can enable peer access to anotherdpctl.SyclDevice
and, if so, to enable or disable it.