[SYCL][matrix] Update the query interface with the latest joint matrix approved syntax

[dkhaldi]

No description provided.

[dkhaldi]

This PR replaces #10847. It addresses most of the comments raised there.
An outstanding issue is on how to add a new value for CPU device (intel_cpu_spr), see #10847 (comment)

[dkhaldi]

It's more complicated than adding new item here for CPU device: it won't be usable if user tries to use it in device AOT or host scenarios.
(1) What we can do right now is that we can add explicit limitation to the spec and add the actual functionality later
(2) Another option is to introduce all intel_cpu_* items as separate PR and make this PR dependent on that PR (e.g., regarding host scenario we already have the updated OpenCL extension in OpenCL CPU RT which allows us to query the unique IDs of Intel CPU architectures)
@gmlueck what do you think between (1) and (2) or maybe other option?

I'd like to have a plan for how this new SPR enumerator fits in with all of the other uses of the architecture enum. Currently, all of the following are related:

The enumerators in architecture.
The legal value for the -fsycl-targets command line switch.
The if_architecture_is function that can be called from device code.
The device::ext_oneapi_architecture_is function that can be called from host code.
It seems like it would be nice to support syntax like -fsycl-targets=intel_cpu_spr, which would AOT compile device code for SPR. This would provide a consistent way to AOT compile for either GPU or CPU devices. I think this would also enable support for if_architecture_is as a side-effect.

For device::ext_oneapi_architecture_is, can we use the CPUID instruction to determine if the CPU is SPR?

It might be useful to have a meeting to discuss this further.

Currently -march=sapphirerapids can be used to specify compilation for SPR.
@yubingex007-a11y, is there something like -fsycl-targets=intel_cpu_spr for SPR?
Yes, I have used CPUID to detect whether this is SPR but not sure this is reliable:
(model == 15 && family == 6 && extended_model == 8 &&
extended_family == 0)

[steffenlarsen]

LGTM!

[dkhaldi]

In an offline discussion, we agreed on adding the new SPR enumerator intel_cpu_spr to the list of devices.
But we will need to confirm that there are no issues/objections on having -fsycl-targets include intel_cpu_spr for AOT compilation.

[dkhaldi]

@dm-vodopyanov, @gmlueck can you please approve the spec changes?

[YuriPlyakhin]

LGTM

[dm-vodopyanov]

SYCL Pre Commit on Windows / Windows / SYCL E2E on Windows (pull_request) https://github.com/intel/llvm/actions/runs/6223657584/job/16898974221?pr=11004

seems like a common CI problem.

@dkhaldi is this patch ready to be merged?

[dm-vodopyanov]

@dkhaldi oh last-minute comment: spec has usage of matrix_type::int8, but there is no int8 in matrix_type enum. Should it be sint8? I can fix it together with my upcoming patch.

[dkhaldi]

@dkhaldi oh last-minute comment: spec has usage of matrix_type::int8, but there is no int8 in matrix_type enum. Should it be sint8? I can fix it together with my upcoming patch.

Thanks, I fixed it here.

[dkhaldi]

@gmlueck, do the recent changes to the SPR addition look good now? If so, please approve the spec portion.

[dm-vodopyanov]

What is maxsize? There is no maxsize in combination struct. I will fix in the upcoming patch and enable (and re-write) the test for PVC, as this is a platform where we definitely test in this particular CI.

[dm-vodopyanov]

sycl::ext::oneapi::experimental::info::device::matrix_combinations

[yubingex007-a11y]

should be sycl::ext::oneapi::experimental::architecture.
otherwise, errmsg is reported
error: use of undeclared identifier 'architecture'