-
Notifications
You must be signed in to change notification settings - Fork 795
[SYCL] Implement SYCL2020 sub_group class #3765
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
Changes from all commits
Commits
Show all changes
7 commits
Select commit
Hold shift + click to select a range
b8ea144
[SYCL] Implement SYCL2020 sub_group class
2d386e9
Revert some changes to avoid ABI breakage
85c3c55
fix build
b1a8a11
Address some feedback, implement barrier
54e68a5
clang-format
3507d53
address feedback
9d3fbdf
Update comment
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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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
This file contains hidden or 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,25 @@ | ||
//==-------------- memory_enums.hpp --- SYCL enums -------------------------==// | ||
// | ||
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. | ||
// See https://llvm.org/LICENSE.txt for license information. | ||
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception | ||
// | ||
//===----------------------------------------------------------------------===// | ||
|
||
#pragma once | ||
|
||
#include <CL/sycl/ONEAPI/atomic_enums.hpp> | ||
|
||
__SYCL_INLINE_NAMESPACE(cl) { | ||
namespace sycl { | ||
using ONEAPI::memory_scope; | ||
|
||
#if __cplusplus >= 201703L | ||
inline constexpr auto memory_scope_work_item = memory_scope::work_item; | ||
inline constexpr auto memory_scope_sub_group = memory_scope::sub_group; | ||
inline constexpr auto memory_scope_work_group = memory_scope::work_group; | ||
inline constexpr auto memory_scope_device = memory_scope::device; | ||
inline constexpr auto memory_scope_system = memory_scope::system; | ||
#endif | ||
} // namespace sycl | ||
} // __SYCL_INLINE_NAMESPACE(cl) |
This file contains hidden or 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
This file contains hidden or 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,37 @@ | ||
//==----------- sub_group.hpp --- SYCL sub-group ---------------------------==// | ||
// | ||
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. | ||
// See https://llvm.org/LICENSE.txt for license information. | ||
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception | ||
// | ||
//===----------------------------------------------------------------------===// | ||
|
||
#pragma once | ||
|
||
#include <CL/sycl/ONEAPI/sub_group.hpp> | ||
#include <CL/sycl/group.hpp> | ||
|
||
__SYCL_INLINE_NAMESPACE(cl) { | ||
namespace sycl { | ||
using ONEAPI::sub_group; | ||
// TODO move the entire sub_group class implementation to this file once | ||
// breaking changes are allowed. | ||
|
||
template <> | ||
inline void group_barrier<sub_group>(sub_group Group, memory_scope FenceScope) { | ||
(void)Group; | ||
(void)FenceScope; | ||
#ifdef __SYCL_DEVICE_ONLY__ | ||
__spirv_ControlBarrier(__spv::Scope::Subgroup, | ||
detail::spirv::getScope(FenceScope), | ||
__spv::MemorySemanticsMask::AcquireRelease | | ||
__spv::MemorySemanticsMask::SubgroupMemory | | ||
__spv::MemorySemanticsMask::WorkgroupMemory | | ||
__spv::MemorySemanticsMask::CrossWorkgroupMemory); | ||
#else | ||
throw runtime_error("Sub-groups are not supported on host device.", | ||
PI_INVALID_DEVICE); | ||
#endif | ||
} | ||
} // namespace sycl | ||
} // __SYCL_INLINE_NAMESPACE(cl) |
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.
I was planning on moving the sub_group stuff out of ONEAPI namespace for the SYCL2020 sub-group support where I'm renaming the routines. Does the existing ONEAPI/sub_group API have to be left intact?
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.
Apparently yes. No problem.
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.
That's right. nd_item returns
ONEAPI::sub_group
. To comply with the spec we'd need to either change the return type (which is a breaking change), or leave it as is and just add new members.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.
Apologies for commenting on a merged PR, but @Pennycook and I have a concern about adding an alias from
ONEAPI::sub_group
into thesycl::
namespace. There are two problems we see:We will probably want to deprecate the
ONEAPI
version of the this API at some point by adding the[[deprecated]]
attribute. However, it's not clear how we can do this ifsycl::sub_group
is an alias. By adding[[deprecated]]
to theONEAPI
version we would also deprecate thesycl
version.The
ONEAPI::sub_group
contains many member functions that are not part of the standardsycl::sub_group
type. By adding an alias, we silently add all of these non-standard member functions into the standard type. This is a violation of the extension policy.Point (2) is a big concern to us because we do not want applications to mistakenly use non-standard APIs. The extension convention was created, in part, to make it obvious when an application uses an extended API. For example, consider the following code:
Application code like that above may not realize that
sg.load()
is non-standard, and they will be surprised when it doesn't work on another SYCL implementation. We had customer feedback during the design of the extension policy that customers want extensions to be named in way that makes it clear that they are extensions.I think the right way to add support for SYCL 2020
sub_group
would be to add a new classsycl::sub_group
that is not an alias to theONEAPI
version. The new class would either:ext_oneapi_
).Can we reconsider the way this is implemented?
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.
@gmlueck I see one big problem with that code. Consider I'm a big fan of always
auto
. If I write code like this:auto sg = it.get_sub_group();
What kind of behavior should I expect? If I previously used ONEAPI extension, and we update the return type, my code is broken. If I write new code and we do not update the return type, it will also be broken (although in a slightly less painful way). Either way, the fact that
nd_item::get_sub_group()
must return different types breaks some use cases.We can add more warnings for this case.
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.
I acknowledge that whatever we do here we'll probably break somebody's code. Unfortunately I think it's unavoidable, and it's a side-effect of the
sub_group
class predating the extension mechanism.If we'd had the forethought to use
it.ext_oneapi_get_sub_group()
we'd have no problems. Instead, we're in a situation where SYCL 1.2.1 + SYCL_INTEL_sub_group defines a function with the same name as SYCL 2020.Can we guard things based on SYCL language version, maybe? If somebody compiles with SYCL 1.2.1 + DPC++ extensions,
it.get_sub_group()
could continue to returnsycl::ONEAPI::sub_group
as before. But if somebody opts-in to compiling with SYCL 2020, the only reasonable expectation is thatit.get_sub_group()
returns asycl::sub_group
.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.
Yes, I agree that things would be better if we had named this
it.ext_oneapi_get_sub_group()
. Actually, this is a good illustration of the problems that can occur when we don't follow the extension mechanism!I like @Pennycook's suggestion about defining
it.get_sub_group()
differently depending on whether the compiler is in SYCL 1.2.1 mode or SYCL 2020 mode. In addition, I'd suggest adding a new member functionit.ext_intel_get_sub_group()
. That member function would always return theONEAPI::sub_group
type. This provides a quick fix for any applications that use the old sub-group extension; they can just change their call fromit.get_sub_group()
toit.ext_intel_get_sub_group()
.