Skip to content

[SYCL][NFC] Move kernel launch property parsing out of sycl::handler #19589

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

Closed
wants to merge 30 commits into from

Conversation

uditagarwal97
Copy link
Contributor

@uditagarwal97 uditagarwal97 commented Jul 24, 2025

Motivation is to decouple kernel launch property parsing from sycl::handler so that we can reuse this code for no-handler submission path.

@uditagarwal97 uditagarwal97 marked this pull request as ready for review July 27, 2025 01:49
@uditagarwal97 uditagarwal97 requested a review from a team as a code owner July 27, 2025 01:49
@uditagarwal97 uditagarwal97 requested a review from Copilot July 27, 2025 01:55
Copy link
Contributor

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR refactors kernel launch property parsing to move it out of the sycl::handler class into a separate helper structure for better code organization and reusability. The motivation is to enable reuse of kernel launch property parsing code in no-handler submission paths.

Key Changes:

  • Creates KernelLaunchPropertyWrapper struct to encapsulate property parsing logic
  • Converts kernel launch properties to use std::optional to track if properties have been set
  • Updates all references to kernel properties to use the new structure with dereferencing

Reviewed Changes

Copilot reviewed 10 out of 10 changed files in this pull request and generated 3 comments.

Show a summary per file
File Description
sycl/include/sycl/detail/kernel_launch_helper.hpp Implements new KernelLaunchPropertyWrapper with property parsing methods
sycl/include/sycl/handler.hpp Updates handler to use new property wrapper and adds helper methods
sycl/source/detail/handler_impl.hpp Makes handler_impl inherit from KernelLaunchPropertyWrapper
sycl/source/handler.cpp Updates property handling to use new structure and adds property setter method
sycl/unittests/scheduler/*.cpp Updates mock handlers to dereference optional kernel properties
sycl/test/virtual-functions/properties-negative.cpp Updates expected error location from handler.hpp to kernel_launch_helper.hpp
sycl/test/extensions/properties/non_esimd_kernel_fp_control.cpp Updates expected error location
sycl/test/include_deps/sycl_detail_core.hpp.cpp Adjusts include dependency ordering
sycl/unittests/program_manager/arg_mask/EliminatedArgMask.cpp Updates mock handler to use dereferenced properties

MKernelClusterSize.fill(0);
}

KernelLaunchPropertiesT &operator=(const KernelLaunchPropertiesT &Other) {
Copy link
Preview

Copilot AI Jul 27, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The custom assignment operator should have a corresponding custom copy constructor, destructor, and move operations following the Rule of Five, or use the default implementations if possible.

Copilot uses AI. Check for mistakes.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, why not = default;?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In hindsight, overriding the assignment operator wasn't the best choice as what I instead wanted is to have a method for taking union of two properties. This method is required as on some code paths we parse multiple property sets for the same kernel. So, I've instead added another method takeUnionOfProperties for the same.

Co-authored-by: Andrei Elovikov <andrei.elovikov@intel.com>
@@ -2076,10 +2076,12 @@ static bool checkContextSupports(detail::context_impl &ContextImpl,
return SupportsOp;
}

#ifndef __INTEL_PREVIEW_BREAKING_CHANGES
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we call "new" functions from here as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done in ed746be

if (KernelLaunchProperties.MClusterDims == 1) {
sycl::range<1> ClusterSizeTrimmed = {
KernelLaunchProperties.MClusterSize[0]};
impl->MNDRDesc.setClusterDimensions(ClusterSizeTrimmed);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't we just use KLProps directly in place of MNDRDes (wherever it's used)? Duplicating the same information in two different data members looks very weird...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IIUC, KLProps and MNDRDes are not interchangeable. The only information common between them is the cluster range and MNDRDes contains other info as well, like local and global size, which KLProps doesn't.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"Doesn't" doesn't mean "shouldn't", does it? Before the patch there was only MNDRDes, after this patch there is at least some duplication of data. That doesn't look good.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm.. looking at the usage of MNDRDes, it's usually set alongside with other kernel launch properties, so it makes sense to also have MNDRDes within KLProps. Let me try that out.

Co-authored-by: Andrei Elovikov <andrei.elovikov@intel.com>
@uditagarwal97
Copy link
Contributor Author

@aelovikov-intel would like to review the entire no-handler design first before moving ahead with this PR. Closing this PR for the time being then.

@bader bader deleted the private/udit/property_refactor branch August 2, 2025 00:46
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants