Handler-less kernel submit API #19294

slawekptak · 2025-07-03T15:23:20Z

No description provided.

vinser52 · 2025-07-04T13:28:42Z

sycl/include/sycl/queue.hpp

@@ -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 {


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.

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.

Yeah, choosing the right name is the hardest task :)

vinser52 · 2025-07-04T13:30:28Z

sycl/include/sycl/queue.hpp

@@ -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(


What about eventless? It is not done yet, right?

Yes, I think it would be similar, so I've skipped it for now.

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?

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++).

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.

Probably, sycl::detail::optional might be considered.

sycl::detail::optional might work, good idea

But still we need to care about the stable layout of the sycl::detail::optional. I am not sure that we are doing it today.

I think having two versions (that return sycl::event and return void) might be a good alternative.

vinser52

In this PR, I would like to see at least one public interface implementation that utilizes this approach, just to ensure it works.

Alexandr-Konovalov · 2025-07-04T17:21:42Z

sycl/include/sycl/queue.hpp

+
+    // TODO UseFallbackAssert
+
+    return submit_with_event_impl(Range, SI, TlsCodeLocCapture.query(),


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.

I was thinking about overloading the submit_with_event and submit_without_event private functions, and then calling them in the Enqueue Functions extension. We can also change the internal implementation of the queue shortcut functions. This way, we don't expose any new public functions in the queue.

I had a similar concern about naming of "no_handler" path APIs. I don't think simply overloading functions from handler and no_handler path is a good idea as they follow completely different submission paths (and design philosophy) and have significant performance differences. Since the USP of no-handler path is an eager submission, how about we use eager in the API name, like submit_eager_with_event/submit_eager_eventless (something like that)?

as they follow completely different submission paths

But it is implementation details, right? If so, why should we expose implementation details in the API name?

slawekptak · 2025-07-07T11:54:38Z

In this PR, I would like to see at least one public interface implementation that utilizes this approach, just to ensure it works.

In the latest update, there are two public interfaces: The enqueue functions extension, and queue.parallel_for. Both are enabled only if __DPCPP_ENABLE_UNFINISHED_NO_CGH_SUBMIT is defined.

expose the new APIs as public under a new define

vinser52 · 2025-07-07T13:22:46Z

sycl/include/sycl/queue.hpp

+  KernelRuntimeInfo() {}
+
+  std::string_view &KernelName() { return MKernelName; }
+  std::unique_ptr<detail::HostKernelBase> &HostKernel() { return MHostKernel; }


Should it be a raw pointer as a return type?

vinser52 · 2025-07-07T13:25:47Z

sycl/include/sycl/queue.hpp

+
+// This class is intended to store the kernel runtime information,
+// extracted from the compile time kernel structures.
+class __SYCL_EXPORT KernelRuntimeInfo {


please define copy/move ctor and assignment operator. I guess they can be declared as deleted, right?

slawekptak had a problem deploying to WindowsCILock July 3, 2025 15:23 — with GitHub Actions Failure

slawekptak temporarily deployed to WindowsCILock July 3, 2025 15:51 — with GitHub Actions Inactive

slawekptak added 2 commits July 3, 2025 16:17

[SYCL] Handler-less kernel submit API

3223842

Fix formatting

fde19ca

slawekptak had a problem deploying to WindowsCILock July 4, 2025 08:17 — with GitHub Actions Failure

slawekptak temporarily deployed to WindowsCILock July 4, 2025 08:42 — with GitHub Actions Inactive

Fix formatting

13424de

vinser52 reviewed Jul 4, 2025

View reviewed changes

Alexandr-Konovalov reviewed Jul 4, 2025

View reviewed changes

slawekptak had a problem deploying to WindowsCILock July 7, 2025 11:49 — with GitHub Actions Failure

slawekptak requested review from uditagarwal97 and Pennycook July 7, 2025 11:57

slawekptak temporarily deployed to WindowsCILock July 7, 2025 12:22 — with GitHub Actions Inactive

Change the ExtendedSubmissionInfo to KernelRuntimeInfo,

fbc789d

expose the new APIs as public under a new define

vinser52 reviewed Jul 7, 2025

View reviewed changes


		// TODO UseFallbackAssert

		return submit_with_event_impl(Range, SI, TlsCodeLocCapture.query(),

Handler-less kernel submit API #19294

Are you sure you want to change the base?

Handler-less kernel submit API #19294

Conversation

slawekptak commented Jul 3, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

vinser52 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

slawekptak commented Jul 7, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!