[SYCL][Doc] Add KernelProperties extension #4280
Conversation
Pennycook
added
spec extension
This extension introduces a replacement for the kernel attributes defined in Section 5.8.1 of the SYCL 2020 specification, in the form of a property_list accepting properties with compile-time constant values. Signed-off-by: John Pennycook <[email protected]>
Implementing the PROPERTIES macro as previously described would have required a very complex solution (or usage of a preprocessor library). Additionally, forgetting to enclose arguments in parentheses would produce error messages that are difficult to understand. Providing a PROPERTY macro that a developer may supply multiple times is much simpler to implement and gives much better error messages.
| class queue { | ||
| public: | ||
| template <typename KernelName, typename KernelType, typename PropertyList> | ||
| event single_task(PropertyList properties, const KernelType &kernelFunc); |
There was a problem hiding this comment.
Doesn't the spec ask us to have a prefix ext_oneapi_ here?
The only section which may tell that this is an expectation is:
A similar situation can occur if an existing SYCL template is
specialized with an extended enumerated value. Obviously,
the extension cannot rename the template in this case.
Instead, it is sufficient that the template is specialized with
an extended enumerated value, and this guarantees that
the extended specialization will not collide.
but I'm not sure I can tell for sure what it is talking about.
There was a problem hiding this comment.
I think we're following the guidelines in the paragraph above that one:
In some cases, an extension does not have the freedom to choose a specific function name. For example, this could happen if the extension adds a new constructor overload for an existing SYCL class. In cases like this, the extension should ensure that one of the function parameters has a type that is defined in the extension’s namespace. For example, the Acme vendor could add a new constructor for
sycl::contextwith the signaturecontext(ext::acme::frobber &).
We're adding an argument to single_task, parallel_for etc, but that argument is in our namespace (ext::oneapi::property_list); if a developer tries to use this extension with another SYCL compiler, they'll get an error about ext::oneapi::property_list not being defined, and from that it will be obvious that they're trying to use an extension.
Arguably we do have the freedom to choose a different function name in this case, but I think the proposed syntax is easier to remember and still in line with the guidelines.
Tagging @gmlueck for awareness, and in case he has anything to add.
|
Since #4203 has been merged, I'm marking this ready for review. |
|
Pinging @intel/dpcpp-specification-reviewers; besides the merge conflict, is there anything more we need to do here? |
Will split these out into a separate extension.
…into kernel-properties
SYCL 2020 has already renamed this to "device_has".
This extension introduces a replacement for the kernel attributes
defined in Section 5.8.1 of the SYCL 2020 specification, in the form of
a property_list accepting properties with compile-time constant
values.
Signed-off-by: John Pennycook [email protected]