[SYCL] Port to event free APIs for kernel submission

[KepingYan]

No description provided.

[Copilot]

Pull Request Overview

This PR updates the SYCLHelpers utility to use the event-free experimental APIs (parallel_for, nd_launch, submit) instead of the older handler.parallel_for and queue.submit calls.

• Replaced cgh.parallel_for<ker_t>(…) with ::sycl::ext::oneapi::experimental::parallel_for<ker_t>(…).
• Swapped q.submit(cgf) for ::sycl::ext::oneapi::experimental::submit(q, cgf).
• Updated all overloads to invoke nd_launch<ker_t> for nd_range‐based kernel launches.

Comments suppressed due to low confidence (2)

src/comm/SYCLHelpers.h:56

• This new call to the experimental submit API introduces a different execution path. We should add or update unit/integration tests to cover the event-free submission semantics and ensure behavior remains correct.

  ::sycl::ext::oneapi::experimental::submit(q, cgf);

src/comm/SYCLHelpers.h:49

• [nitpick] The function comment above this declaration still refers to the old submission model. Please update the doc comment to mention that it now uses the experimental event-free APIs (parallel_for, nd_launch, submit).

static inline void sycl_kernel_submit(

[Copilot]

[nitpick] The fully qualified namespace ::sycl::ext::oneapi::experimental is repeated multiple times. Consider introducing a namespace alias (e.g., namespace sycl_exp = ::sycl::ext::oneapi::experimental;) to reduce verbosity and improve readability.

Suggested change

	::sycl::ext::oneapi::experimental::parallel_for<ker_t>(cgh, range, ker);
	};
	::sycl::ext::oneapi::experimental::submit(q, cgf);
	sycl_exp::parallel_for<ker_t>(cgh, range, ker);
	};
	sycl_exp::submit(q, cgf);

[gujinghui]

Should we add build assertion to check SYCL_EXT_ONEAPI_ENQUEUE_FUNCTIONS first?

[KepingYan]

Should we add build assertion to check SYCL_EXT_ONEAPI_ENQUEUE_FUNCTIONS first?

Do we need to keep the original code path? If SYCL_EXT_ONEAPI_ENQUEUE_FUNCTIONS is defined and set to 1, run the modified code; otherwise, use the original code. Or just add an assertion?

[gujinghui]

Should we add build assertion to check SYCL_EXT_ONEAPI_ENQUEUE_FUNCTIONS first?

Do we need to keep the original code path? If SYCL_EXT_ONEAPI_ENQUEUE_FUNCTIONS is defined and set to 1, run the modified code; otherwise, use the original code. Or just add an assertion?

Should be no. According to previous discussion, we have to go to the event-less path, anyway.

[KepingYan]

Gentle ping @fengyuan14 .

[guangyey]

Hi @chuanqi129, could you help assign the right person to validate whether this change may introduce any unintended performance regressions?

[gujinghui]

ifdef SYCL_EXT_ONEAPI_ENQUEUE_FUNCTIONS is good enough, as the only value is 1 when defined.

BTW, can we provide more readable error message? For example,
FATAL ERROR: The SYCL_EXT_ONEAPI_ENQUEUE_FUNCTIONS is excepted to be defined to enqueue kernel without returning event. But the undef is detected!