-
Notifications
You must be signed in to change notification settings - Fork 786
[SYCL][ESIMD][EMU] single_task support, v.2 #5671
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
lsatanov
commented
Feb 25, 2022
- ESIMD EMU: single_task() support.
- ESIMD plugin: misc clarifying refactoring.
7023689
to
b9acc83
Compare
@@ -16,6 +16,7 @@ | |||
|
|||
#include <CL/sycl/backend_types.hpp> | |||
#include <CL/sycl/detail/accessor_impl.hpp> | |||
#include <CL/sycl/detail/cg_types.hpp> // for HostKernelBase |
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.
Remnant from variant 1. Will eliminate after testing completes
@@ -142,38 +143,21 @@ static char ESimdEmuVersionString[32]; | |||
|
|||
using IDBuilder = sycl::detail::Builder; | |||
|
|||
using HostKernelBase = cl::sycl::detail::HostKernelBase; |
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.
Remnant from variant 1. Will eliminate after testing completes
d2fbf16
to
b206c79
Compare
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.
@romanovvlad, @smaslov-intel - please take a look as well.
*/ | ||
// For 'void' and 'sycl::group<Dims>' kernel argument | ||
// For 'sycl::group<Dims>' kernel argument |
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.
please use single comment style - '//'
@@ -246,6 +246,7 @@ template <class KernelType, class KernelArgType, int Dims> | |||
class HostKernel : public HostKernelBase { | |||
using IDBuilder = sycl::detail::Builder; | |||
KernelType MKernel; | |||
|
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.
here and in other places - please avoid unrelated changes like adding empty lines
sycl/include/CL/sycl/handler.hpp
Outdated
|
||
/* 'wrapper'-based approach using 'NormalizedKernelType' struct is not used | ||
* for 'void(sycl::group<Dims>)' since 'void(sycl::group<Dims>)' is not | ||
* supported in ESIMD. |
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.
Is sycl::group<Dims>
kernel supported at all (non-ESIMD case)? If not, then RT error would be better.
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.
My current understanding is the following: it's a "won't happen" case for ESIMD, hence no error.
Shall review this.
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.
Assuming something won't happen and just ignoring the possibility is not safe. Please add error reporting.
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 true. This code was introduced previously and results in runtime failure in case of using esimd emu backend without marking kernel as ESIMD kernel. If kernel is marked as ESIMD kernel - the compiler crashes without a human-friendly error report, which is also to be fixed.
All of it is to be addressed in the following changes.
template <int NDims> struct LambdaWrapper { | ||
// kernel execution. Function instances of 'KernelWrapper' un-wrap | ||
// this struct instance and invoke lambda function ('Func') | ||
template <int NDims> struct KernelWrapperData { |
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 don't see how KernelWrapper is better than InvokeLambda. If Lambda does not cover all kernel cases then InvokeKernel or KernelInvoker?
Then KernelWrapperData -> KernelInvocationContext.
If this all is only supposed to be used on a host device (and/or esimd emulator), then I'd add 'Host' prefix as well.
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.
Warning: naming discussion.
Ok, the point was to make more sense (and less code). Yes, kernel is not always lambda.
There are many ways to do it. I consider KernelWrapper and KernelWrapperData clear enough and find adding "Host" prefix for things used inside esimd_emulator only an overkill and not bringing more sense.
If inevitable, the naming can be changed to the required liking.
e.g.,
InvokeKernel
KernelInvocationContext
would be totally clear.
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.
Classes should not be named with verbs, but adhjectives. KernelCaller, KernelInvoker
Warning: naming discussion.
Not sure I understand the warning. You started changing names, so I commented.
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.
Konstantin, I understand your point, but InvokeKernel is a function (template), not a class.
P.S. regarding classes, how they should be named (verbs/adjectives/nouns) is debatable taking into account that they can be callable in C++ (as we all know). In other languages, e.g. JavaScript, everything is an object (including functions). Should we name everything in JavaScript not using verbs? I doubt that.
edd7398
to
a538630
Compare
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.
LGTM
970344d
a538630
to
970344d
Compare
[SYCL][ESIMD][EMU] misc clarifying plugin refactoring.
970344d
to
b7e60c1
Compare
@romanovvlad, @kbobrovs hi. Merging? |
@lsatanov, this patch break the build due to
Could you fix this issue, please? |
Sure! #5779 Interesting, how the pre-commit checks have passed (or compilation options have changed meanwhile this has been reviewed?) |
Post-commit has wider coverage. Thanks for fixing it! |