Add sycl ext intel kernel queries extension

[kurapov-peter]

This adds a sycl_ext_intel_kernel_queries extension for target-specific low-level information retrieval. In a nutshell, the extension adds compiled kernel traits for the intel backend. The traits can be queried using the usual kernel::get_info() calls (and get_kernel_info). Each query gets its own aspect to tell whether the query is supported on the device. This PR adds ext_intel_spill_memory_size aspect and an implementation for querying the spilled memory size as reported by L0.

[kurapov-peter]

Is it possible to check for the aspect here as well?

[kurapov-peter]

The mapping to devices relies on UR providing the same order within a single application (see oneapi-src/unified-runtime#2614 for details). There was a problem inside UR implementation that demanded the API to return an array of values for spills instead of a single value (due to device pointer unavailability). This implementation hides that inconvenience from SYCL users.

[kurapov-peter]

Fixed in UR v1 adapter

[kurapov-peter]

Is this the right type of exception?

[kurapov-peter]

There might be a better way to test the thing. This would just return zero. Any suggestions?

[gmlueck]

Hi @kurapov-peter, I hope you don't mind, but I pushed a commit with my proposal for how the specification should look in b027f870d67e035e6476dc0a84bc3f5dfddbf99f. Feel free to revert this commit if you are opposed, or to add comments in this PR.

Here is my rationale for some of the changes:

• Since this PR is implementing the extension, it can't be "proposed". It needs to be either "experimental" or "supported". I thought the extension seemed simple enough to go straight to "supported", but we can do "experimental" if you think the API might change.
• I reworded the Overview to be a bit more general, allowing us to add more queries in the future.
• I think each query needs to have its own matching aspect. This is similar to what we did in sycl_ext_intel_device_info.
• I changed the names to spell out "memory" because the newer APIs in SYCL tend to prefer whole words rather than abbreviations.
• I changed the return type of the query to size_t because that seemed more appropriate for a C++ API.
• I changed the namespace of the info descriptor to kernel_device_specific because this is the correct namespace for kernel info descriptors that are used with the get_info(const device&) overload.
• I updated the general style of the specification to use a newer format that we are moving to.

Note that I did not update the implementation, so that will need to be changed to match the spec.

[kurapov-peter]

All the changes look reasonable to me. I'll update the implementation.

[kurapov-peter]

Is L0 important here?

[gmlueck]

Normally, we would not define a SYCL API in terms of a particular backend like this. However, it seemed to me that "spill memory size" is too vaguely defined. The reality is that SYCL is just returning whatever value comes from Level Zero. If people have questions about what it means, I'd rather direct them to Level Zero.

[kurapov-peter]

fair enough

[kurapov-peter]

#16810 is merged, so this has no dependencies. Putting it to ready for review.

[AlexeySachkov]

I doubt that this line has any effect on the test, so you may as well drop it. Moreover, I'm not sure what are the rules of redefining metadata, it may not be a valid change at all

[AllanZyne]

Yep, I agree with @AlexeySachkov on behalf of sanitizer reviewer.

[AlexeySachkov]

This should be hidden under an if, the query is not guaranteed to be supported everywhere. The same goes for other change in this file.

[gmlueck]

@Pennycook could you review this for @intel/dpcpp-specification-reviewers ? I'm the author of the spec in this PR.

[Pennycook]

Specification looks good, but a meta-comment: if we're going to have to end up exposing all the Level Zero kernel queries, it might be a good idea to just provide a single way to query things using the Level Zero enums and/or backend interop.

[aelovikov-intel]

it might be a good idea to just provide a single way to query things using the Level Zero enums and/or backend interop

Why don't we push for that right now?

This is a draft for the extension and its implementation.

This needs an update, I assume