[SYCL] Add esimd device descriptor for 2d load/store/prefetch

[againull]

Add esimd device descriptor to check if 2d block operations are supported by the device.
UR counterpart: oneapi-src/unified-runtime#2261

[Pennycook]

Am I right in thinking that this feature (2D block loads/stores) is not actually exposed to SYCL?

[rolandschulz]

It is indirectly available to users through the joint_matrix abstraction. But for that I don't think the user needs to be able to query it. Currently it isn't available directly in a supported way (cutlass uses IGC builtins). But we plan to support it at least through SPIR-V/OpenCL interop and if there demand also as SYCL extension.

[gmlueck]

It does seem weird to add a SYCL query for a feature that cannot be used via SYCL. Can we instead add the query at the same level as the API? For example, if applications will access 2D block load/store via OpenCL, can we add an OpenCL query?

[againull]

Thanks for the comments, the request was from the user to add this query at the SYCL level. I will get more details about how they use 2D block load/store feature and if they can consider using L0 API directly.

[againull]

According to the info from the user they use either esimd or joint_matrix.
So, I believe if someone uses joint_matrix operations then they can check corresponding matrix aspects.

In case of ESIMD it looks like load_2d/store_2d operations are mapped to this low level feature https://github.com/intel/compute-runtime/blob/24.39.31294.12/level_zero/doc/experimental_extensions/2D_BLOCK_TRANSPOSE.md.
@sarnex Could you please help to confirm that or maybe recommend someone who can help.

Currently in the ESIMD docs there is a statement that load_2d/store_2d can be used only on PVC (see https://github.com/intel/llvm/pull/15905/files#diff-fef71b0090d0ea44c96240cd9d6497881b617b91e234635a19313eb69864b7f3L555):
I believe we can create a new esimd aspect (which checks if device has 2d block load/store) for this load_2d/store_2d operations.
So that users don't have to check particular devices but can just check the aspect.

Does it make sense to introduce such aspect? I've updated the PR with proposed changes.

[sarnex]

I can't say for sure if the architecture restriction is correct (idk if 2d ops are PVC only, or actually PVC or later or what).
But I have no flags to adding an aspect, I guess it would just come down to a arch/device ID check in UR somewhere.
I can help, but please let me know what I'm signing up for.

[againull]

dyn_cgf_different_arg_nums.cpp failure on CUDA is unrelated and is fixed here: #16157

[againull]

@intel/unified-runtime-reviewers Could you please approve.

[AlexeySachkov]

@againull, FYI, this PR breaks some tests on PVC:

• ESIMD/dpas/dpas_tf32.cpp
• ESIMD/acc_gather_scatter_rgba_stateless_64.cpp
• ESIMD/lsc/lsc_block_load_store_stateless_flag_64.cpp
• ESIMD/lsc/lsc_block_load_store_stateless_64.cpp
• ESIMD/accessor_stateless_ctor_64.cpp
• ESIMD/accessor_load_store_stateless_64.cpp
• ESIMD/lsc/lsc_gather_scatter_stateless_64.cpp
• ESIMD/lsc/lsc_load_store_2d_compare.cpp
• ESIMD/accessor_gather_scatter_stateless_64.cpp
• ESIMD/accessor_stateless_64.cpp
• ESIMD/slm_init_no_inline.cpp

[againull]

@againull, FYI, this PR breaks some tests on PVC:

• ESIMD/dpas/dpas_tf32.cpp
• ESIMD/acc_gather_scatter_rgba_stateless_64.cpp
• ESIMD/lsc/lsc_block_load_store_stateless_flag_64.cpp
• ESIMD/lsc/lsc_block_load_store_stateless_64.cpp
• ESIMD/accessor_stateless_ctor_64.cpp
• ESIMD/accessor_load_store_stateless_64.cpp
• ESIMD/lsc/lsc_gather_scatter_stateless_64.cpp
• ESIMD/lsc/lsc_load_store_2d_compare.cpp
• ESIMD/accessor_gather_scatter_stateless_64.cpp
• ESIMD/accessor_stateless_64.cpp
• ESIMD/slm_init_no_inline.cpp

Thanks, those have requires: pvc, so I didn't get failures in pre/post-commit. I know the rootcause, will fix.