RFC for "Passed Directly" Customization Point

[danhoeflinger]

Provides a proposal for a public customization point for users to define to indicate if their types are passed directly to sycl kernels.

This RFC is intended to address and resolve #1939.

Here is a working proof of concept to play with: https://godbolt.org/z/jvo1esoeb (updated)

[danhoeflinger]

I have a working proof of concept for this in godbolt, but needs some cleanup before sharing. Let me know if that would be useful to provide here, but likely any needed details can and should be provided in the text.

[masterleinad]

Apart from the name, the approach looks pretty reasonable to me.

[danhoeflinger]

This section of the specification makes me think that the API we end up with for this RFC should be an extension rather than a full part of the specification.

The specification leaves the way data is passed as unspecified, so unless we want to significantly expand that section of the specification, I think an extension is probably the correct place for this.

[danhoeflinger]

This section of the specification makes me think that the API we end up with for this RFC should be an extension rather than a full part of the specification.

The specification leaves the way data is passed as unspecified, so unless we want to significantly expand that section of the specification, I think an extension is probably the correct place for this.

Let me walk that back, after further consideration and discussion with @rarutyun. We do already specify some of the context we need in the specification, and it would not be too much more to add enough to describe using our provided iterator types, and define passed directly in that context as well as how it could be leveraged by users.

I do think it can end up in the full specification, and will add something valuable to for others who may implement oneDPL.

The undefined part of the specification is about the way to transfer host data to the device and back, which is related, but we can still decline to describe it while also providing a way to mark user types as "passed directly".

[masterleinad]

Suggested change

	* Is there a better, more concise name than `oneapi::dpl::is_passed_directly_in_onedpl_device_policies[_v]` that
	* properly conveys the meaning to the users?
	* Is there a better, more concise name than `oneapi::dpl::is_passed_directly_in_onedpl_device_policies[_v]` that
	properly conveys the meaning to the users?

[danhoeflinger]

thanks, fixed.

[masterleinad]

This section of the specification makes me think that the API we end up with for this RFC should be an extension rather than a full part of the specification.

In my opinion, it's important to clarify when the user can pass in device data and when the data is expected to be in host memory. That section doesn't really do that.

[danhoeflinger]

This section of the specification makes me think that the API we end up with for this RFC should be an extension rather than a full part of the specification.

In my opinion, it's important to clarify when the user can pass in device data and when the data is expected to be in host memory. That section doesn't really do that.

We can try to improve the language of the specification either in the context of the specification PR related to this feature, or in a separate specification PR.

[akukanov]

I approve the proposed design. The API needs to be finalized and approved for a oneDPL specification update.

@masterleinad does the proposed design meet your needs and expectations?

@rarutyun @dmitriy-sobolev @MikeDvorskiy - please take a look. The goal is to settle on the design and make sure it does not have significant flaws.

[masterleinad]

@masterleinad does the proposed design meet your needs and expectations?

Yes, the design looks reasonable to me.

[danhoeflinger]

I have a tentative implementation at #2126. This is not ready for review and should not be seriously considered until we have this and a specification PR merged.

However, since I have it, I thought I'd link it in case its useful.