-
Notifications
You must be signed in to change notification settings - Fork 795
[SYCL][ABI Break] Add support for per-kernel auto GRF mode specification, and reimplement feature using kernel properties #9258
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
Conversation
@AlexeySachkov I've reimplemented this using kernel properties and did the ABI-breaking device binary property rename. Please take a look when you get a chance, thanks. |
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.
It is always good to see the code removed! However, I'm concerned that lowering of the property is done by sycl-post-link
and not by a dedicated pass
fixed in latest commit, thx |
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.
sycl-post-link
and SYCLLowerIR
parts LGTM. Thanks for the refactoring and unification!
llvm/test/SYCLLowerIR/CompileTimePropertiesPass/kernel-attributes/register-alloc-mode.ll
Show resolved
Hide resolved
@intel/llvm-reviewers-runtime @intel/dpcpp-esimd-reviewers This one is ready for review now, the major feedback has been addressed. Thanks! |
sorry for the force push, the e2e test changes made rebasing preserving commits difficult |
@intel/llvm-reviewers-runtime ping on this one, thanks |
@bso-intel ping, thanks. |
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.
Since this is marked as an ABI break, we need a bump to SYCL_DEV_ABI_VERSION
in accordance with the ABI policy.
Also, I feel like I got the answer with the previous implementation of GRF mode handling, but is this new property intended for users? If yes, I think we need an extension documenting it. If not, we should consider placing it in another namespace to avoid confusion.
…implement feature using kernel properties This works extends the existing support we have for large GRF mode specification. I introduce a new argument to set_kernel_properties, kernel_properties::use_auto_grf. Then, we update LowerKernelProps to lower this new attribute and do sanity checks. Next, we update sycl-post-link to split and add an image property based on this property. Finally, we update program manager to check the image property and pass the correct flag for JIT. For AOT, this works through the RegisterAllocMode metadata that we add during LowerKernelProps and is kept through llvm-spirv. Note that ESIMD does not work at all yet, not for JIT nor AOT. This is because the VC backend does not support auto GRF. I have made a feature request for the VC team to add this. Signed-off-by: Sarnie, Nick <[email protected]>
Signed-off-by: Sarnie, Nick <[email protected]>
Signed-off-by: Sarnie, Nick <[email protected]>
Signed-off-by: Sarnie, Nick <[email protected]>
sorry for rebase, there was a conflict @steffenlarsen @dm-vodopyanov all feedback should be addressed (hopefully) |
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.
Runtime changes LGTM!
Signed-off-by: Sarnie, Nick <[email protected]>
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.
Thanks, RT part LGTM
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.
Ok for ESIMD. The changes look great. Thank you.
The fix is ABI Breaking and thus may need special approval at PXT meeting.
We are in ABI breaking window. |
@aelovikov-intel we think we may still need approval even within the window. are you sure that we do not? |
@aelovikov-intel We confirmed internally we do NOT need approval, it was a false alarm. @intel/llvm-gatekeepers This one is ready for merge. Thanks! |
#include <sycl/sycl.hpp> | ||
|
||
using namespace sycl; | ||
using namespace sycl::detail; |
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.
sycl::detail::register_alloc_mode ?!
Sorry for the late comment, but I just did not realize this issue during code-review phase and discovered it only now when tried to use the new API.
I believe we must never inspire users to use 'detail' namespace, and ask include files from "*/detail/*" - it is only for SYCL internal needs. Only SYCL implementation should use detail namespace, not user.
The enum must have been defined not as "sycl::detail::register_alloc_mode", but as "sycl::ext::oneapi::experimental::register_alloc_mode".
The file kernel_properties.hpp also needed to be placed at ext/oneapi/experimental/kernel_properties.hpp.
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.
Maybe the file needs to be placed in ext/intel/experimental/kernel_properties.cpp (where it was), which seems more correct than where it is now (sycl/detail).
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.
The detail namespace was picked after the discussion in #9258 (comment) as it was believed to be an internal-only property. If it is meant to be used externally we would normally require documentation of the feature prior to implementation. When we have that, I see no problem in moving it out of the detail namespace.
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.
The previous "experimental" extension should not have been removed while there is no new equivalent "experimental" feature. This means that we need to switch from the old "experimental" to new "detail" (code breaks), then we need to switch from "detail" to "experimental" (another code break), and then finally from "experimental" to final (3rd code break). Is there any reason apart from the lack of documentation to add this to "detail" first?
This change reimplements the GRF mode specification using native SYCL kernel properties, does an ABI break, and adds the
automatic
option.We add a new property named
sycl::detail::register_alloc_mode
, and it takes in an enumsycl::detail::register_alloc_mode_enum
which currently has two values:automatic
andlarge
.This can be applied to kernels as below:
We do some
register_alloc_mode
specific work inCompileTimePropertiesPass
, we add function metadata namedRegisterAllocMode
based on the function attributesycl-register-alloc-mode
. This is because llvm-spirv looks for the metadata. This metadata is how AOT works.We also do some
register_alloc_mode
specific work insycl-post-link
:sycl-register-alloc-mode
function attribute added in the front endsycl-register-alloc-mode
used in the SYCL runtime.Note that ESIMD does not work at all yet for
automatic
yet, not for JIT nor AOT. This is because the VC backend does not support auto GRF. I have made a feature request for the VC team to add this.large
continues to work for JIT only.