[SYCL][Doc] Add slm_per_subslice query for Xe GPUs

[Pennycook]

Extends sycl_ext_intel_device_info with a new query for the amount of SLM per subslice. The amount of SLM per subslice may be greater than the amount of memory available to a single work-group, and can be used to reason about occupancy.

[Pennycook]

@gmlueck - I've opened this as a draft because I think that's your preferred workflow for updates to supported extensions, but this is ready for review.

[bader]

@gmlueck, Intel introduced new terminology for GPUs in 2022.

https://www.intel.com/content/www/us/en/docs/oneapi/optimization-guide-gpu/2023-0/intel-iris-xe-gpu-architecture.html#XE-TERMINOLOGY-CHANGES

I think we should update DPC++ documentation/specifications to use new terminology at some point.

[gmlueck]

I think we should update DPC++ documentation/specifications to use new terminology at some point.

The APIs in this extension are all pass-throughs to Level Zero. It seems like the Level Zero documentation is still using the old terminology:

https://oneapi-src.github.io/level-zero-spec/level-zero/latest/core/api.html#_CPPv422ze_device_properties_t

[AlexeySachkov]

I think we should update DPC++ documentation/specifications to use new terminology at some point.

The APIs in this extension are all pass-throughs to Level Zero. It seems like the Level Zero documentation is still using the old terminology:

https://oneapi-src.github.io/level-zero-spec/level-zero/latest/core/api.html#_CPPv422ze_device_properties_t

But do our customers care about whether or not this is a pass-through to L0? We already have asks to update the used terminology: #16068

[gmlueck]

I think many customers who call these low-level APIs do know about the Level Zero interfaces, though. Using different terms in the SYCL API may add more confusion since it will be unclear how the SYCL API relates to the Level Zero one. In addition, all the other APIs in this extension use the old terminology, so it would be weird to change just this one.

Updating the SYCL terminology seems like a good goal, but I'd rather do it in conjunction with changes to the Level Zero API.

[gmlueck]

@Pennycook It seems like the issues above are resolved? If that is the case, then I'd suggest:

• Resolve conflicts
• Keep the PR as "draft" since we don't want to update the spec until the feature is available for customers to use
• Open an internal tracker about implementing this new query

I forget which customer request lead to this proposal, but we should include that in the tracker if possible.

[Pennycook]

Resolving the merge conflicts was too hard -- the other changes introduced lots of similar subsections, and git diff got very confused. I rebased the changes on top of the sycl branch instead, but had to force push the result as 31d410d.

CMPLRLLVM-64348 already exists to track the implementation, and CMPLRLLVM-64179 is the original customer request.