Handler-less kernel submit API #19294
Conversation
slawekptak
had a problem deploying
to
WindowsCILock
GitHub Actions
Failure
slawekptak
had a problem deploying
to
WindowsCILock
GitHub Actions
Failure
| @@ -149,6 +149,37 @@ class __SYCL_EXPORT SubmissionInfo { | |||
| ext::oneapi::experimental::event_mode_enum::none; | |||
| }; | |||
|
|
|||
| using KernelParamDescGetterFuncPtr = detail::kernel_param_desc_t (*)(int); | |||
|
|
|||
| class __SYCL_EXPORT ExtendedSubmissionInfo : public SubmissionInfo { | |||
There was a problem hiding this comment.
While technically it might work, I am not sure that logically it should be part of the SubmissionInfo. I would say it should be a separate class called KernelInfo or something like that.
There was a problem hiding this comment.
Actually, I've considered both: KernelInfo or extended SubmissionInfo, and since we already have the KernelInfo type, I've combined all of it into the ExtendedSubmissionInfo, but I think your suggestion makes sense - these are more like attributes of the kernel and not the submission. I will change this to something similar to KernelInfo.
There was a problem hiding this comment.
Yeah, choosing the right name is the hardest task :)
| @@ -3680,6 +3743,21 @@ class __SYCL_EXPORT queue : public detail::OwnerLessBase<queue> { | |||
| const detail::code_location &CodeLoc, | |||
| bool IsTopCodeLoc) const; | |||
|
|
|||
| event submit_with_event_impl( | |||
There was a problem hiding this comment.
What about eventless? It is not done yet, right?
There was a problem hiding this comment.
Yes, I think it would be similar, so I've skipped it for now.
There was a problem hiding this comment.
What is the disadvantage of returning optional<event> and having somewhere (probably, in SubmissionInfo, as this is mode of submission) a flag, pointing out is it event or eventless mode? I think about bunch of functions that pass arguments by chain and about duplicating them (for event and for eventless) and this is not looks good. What do you think?
There was a problem hiding this comment.
I am not sure if returning std::optional<event> is a good idea because of ABI concerns. It might not have a stable ABI across compiler versions or even different standard libraries (libstdc++ vs libc++).
There was a problem hiding this comment.
I am not sure if returning
std::optional<event>is a good idea because of ABI concerns. It might not have a stable ABI across compiler versions or even different standard libraries (libstdc++ vs libc++).
Yes, good point.
There was a problem hiding this comment.
Probably, sycl::detail::optional might be considered.
|
|
||
| // TODO UseFallbackAssert | ||
|
|
||
| return submit_with_event_impl(Range, SI, TlsCodeLocCapture.query(), |
There was a problem hiding this comment.
This call library interface that performs submit without internal handler creation and calling user callback, right? How can it be named, to differentiate from generic submit()? Probably _no_handler from your POC is not the best name, as it describe what the function not do, not what it do.
No description provided.