[gmlueck]

Proposed KHR for a new property mechanism that conveys more information at compilation time. These new style properties allow better error checking at compilation time, and they support properties that can influence the code generated by the compiler (because some properties can have values that are known at compilation time).

[keryell]

I have made an implementation of this with 5 variations with the help of Claude Code CLI Opus 4.6 1M tokens: https://github.com/SYCL/properties

So it looks like using prop2<> as a key works for constexpr properties. @illuhad

[keryell]

Some other ideas on clean interface https://github.com/qlibs/mp

[VerenaBeckham]

I love the idea of compile-time properties, but does Intel have a killer use-case for them right now? As I understand it, all the existing SYCL properties would remain "runtime properties" as described by this KHR. Also, in the "free function commands KHR", which now depends on this KHR, I can't immediately see a property that would be implemented as a compile-time property, unless I missed it?
Is there a compile-time property that you are intending to introduce once this KHR is merged?

[gmlueck]

Is there a compile-time property that you are intending to introduce once this KHR is merged?

The reason we proposed this KHR now is because we want to use it in #922. We'd like to replace the khr::requirements class template with the new khr::properties. The khr::requirements is very similar to khr::properties, but it's not as general. If we can settle on the compile-time properties KHR, then we can avoid defining khr::requirements at all, which will simplify the overall API surface. It will also improve #922 because we can use the new khr::properties in the future to pass kernel launch properties to those APIs. Intel has a number of kernel launch properties in our extensions already, and I expect we will want a standard way for vendors to pass properties when launching a kernel.

[TApplencourt]

> The properties defined and illustrated in this extension are all in the sycl::khr namespace rather than some nested namespace like sycl::khr::properties. If this KHR is adopted into the core spec, properties will be defined directly in sycl. This was intentional in order to reduce verbosity in applications that use the extensions. Is this a good idea, or will we end up polluting the top-level SYCL namespace with lots of properties?

Done

> The properties constructor has a Mandates that no two properties in the list have the same key. Does it make sense for this to be a Mandates instead of a Constraint? I think the error message will be better with a Mandates, but you could make that same argument for other cases where we decided to use Constraints anyways.

Not allowed: 
- plist.has_property_list<prop_1<false>, prop_1<true>>;

- C++: Mandates versus Constraint
	- Mandates: Compile Time
	- Constraint: "no overload matching"
		Allow: - if require 
					 - else 
	- Nevin Todo: When does the C++ choise to use Mandates or Constraint.

- No exception for plist.has_property_list<prop_1{true}, prop_1{true}>;
	- To much compile time overhead.
	- Imposible to do for runtime value

> Should we define operator== and operator!= for every property? The DPC++ extension has this, but I left it out of this KHR because they didn’t seem very useful to me.

- Can use `decltype` for get/has in CTS.
- WG vote to go without `==` and `!=`

> Should we define operator== and operator!= for the properties list? This would require metaprogramming to deduce EncodedProperties as the sorted list of Properties, otherwise two properties lists constructed from the same set of properties would have different types if the properties were specified in a different order. The DPC++ extension has this, but I left it out of this KHR because the comparison operators didn’t seem that useful, and I didn’t think it was worth the extra complexity required to sort the properties. Sorting the properties (via metaprogramming) would also slow down compilation (because the properties would be sorted at compilation time), and I didn’t want to impact compilation time by adding this sorting requirement. However, I defined the properties constructor in such a way that we could add this sorting as a later revision of this KHR.

auto p1 = sycl::property_list{ p1, p2 };
auto p2 = sycl::property_list{ p2, p1 };

static_assert { p1 == p2 };

- N^2 algorithm
- Property and property list will not follow SYCL "Common reference semantics", neither "Common  by-value semantics"
- Not possible to be implemented in user-space.
- WG vote to go without `==` and `!=`
- Potential to Add KHR section "Limitation"

> Can we guarantee that properties is trivially copyable unless it contains a runtime property that is not trivially copyable? The POC uses std::tuple to implement properties, and std::tuple is not trivially copyable. As a result the POC version of properties is not trivially copyable. This seems like it should be fixable, though, because the DPC++ version is trivially copyable.

- If `property_list` trivialy copyable, can be passed as Kernel Argument?
	- tuple is currently potentially `Device copyable`.
	- When all compile time, don't need a tuple, so trivial to make it "trivial copyable"

- For the same argument of simplification, we don't say anything.  WG vote to go without the `trivially copyable` requirement

> This KHR already defines the trait is_property_list_for, but should it also define the trait is_property_list? It turns out that none of the APIs in this KHR need is_property_list to implement any of their constraints, but maybe this trait would be useful to users who want to create a utility function that takes a generic properties list?

`is_property_for_v<in_order, queue> == true`
`is_property_for_v<sub_group_size, queue> == false`
`is_property_list_for_v<plist, queue>` == plist.all?

- WG vote for don't add it `is_property_list`. Also maybe easier in C++26 introspection

[CLAassistant]

All committers have signed the CLA.

[gmlueck]

Adding a comment here about the namespace.

We considered adding these new overloads to sycl::khr instead, but decided on the sycl namespace. My commit message (adab485) explains the reasoning:

After an internal discussion, we think the namespace for these functions should remain sycl (not sycl::khr).

The motivation for putting these functions in the sycl::khr namespace was to make it clear to people who read or write the source code that these functions are an extension vs. part of the core spec. However, this should be clear despite the namespace because these functions all take new-style properties, and the properties themselves are in the syc::khr namespace.

Our plan is to adopt these new-style properties into the next version of the SYCL specification (SYCL-Next), and these functions will be in the sycl namespace once that happens. By defining them in the sycl namespace now, we avoid some API thrash while still making it clear that they are (currently) an extension.

I'll leave this comment open for a while, though, to see if others agree.

[gmlueck]

Hi everyone,

I'm finished making changes and consider this ready for final review now. During the F2F, we decided that we wanted to concentrate on getting KHR's ratified between now and the spring, and this one was on our priority list. It would be great to get some conditional approvals on the specification text. Then, once KhronosGroup/SYCL-CTS#1251 is ready, we can finalize and send it out for ratification.

[VerenaBeckham]

It's not clear to me which functions this is referring to. is_in_order and khr_is_profiling_enabled? But which one is added and which one is modified? How is it modified? And how is it legal for an extension to modify an existing function?

[gmlueck]

I reworded this in db82a01. Does that seem better?

I think it is OK for an extension to expand an existing API so long as it doesn't break any existing code that is already using that API. The previous definition returned true whenever the queue was constructed with the old-style in_order property. The new definition returns true whenever the queue is in order. Therefore, the intent of the query is the same. It just got expanded to cover both the old-style and the new-style in_order properties.

[VerenaBeckham]

The wording is much better, thanks.
I see what you're saying about is_in_order(), and it makes sense, but I think it would be clearer if the description read something like Returns: true only if this queue was constructed with either the property::queue::in_order or khr::property::in_order property.

[gmlueck]

That still wouldn't be correct, though, because constructing the queue with khr::property::in_order{false} would not create an in-order queue.

In the future, we plan to adopt the new-style properties into the core spec (e.g. as part of SYCL-Next). At that point, an in-order queue could be constructed in any of the following ways:

• with the sycl::property::queue::in_order property
• with the sycl::khr::property::in_order{true} property
• with the sycl::property::in_order{true} property

Listing them all will get very unwieldy.

[VerenaBeckham]

I see your point. Could we then add something more descriptive in the intro, like "This extension modifies the queue::is_in_order function to additionally enable querying of the in_order property or the queue if it was constructed with khr::property::in_order..."?
I just feel it's confusing as it stands, because it feels like the description should always have been like that. In fact, you could probably argue that you could make that change to the SYCL 2020 spec right now, because it doesn't make any semantic change, does it?

[gmlueck]

In fact, you could probably argue that you could make that change to the SYCL 2020 spec right now, because it doesn't make any semantic change, does it?

I like this idea! I created #1076 to make this generalization. If the WG approves that change, I'll simplify this KHR because it will no longer be necessary for it to expand the definition of is_in_order.