[SYCL][Joint Matrix] Relax matrix_combinations error handling

[dm-vodopyanov]

This patch relaxes reporting of unsupported HW for matrix_combinations
query.
Before: exception thrown in case customer uses matrix_combinations
query on platform unsupported by ext_oneapi_device_architecture.
With this patch: customer gets empty vector from matrix_combinations
query on platform unsupported by ext_oneapi_device_architecture.

[dm-vodopyanov]

@intel/sycl-matrix-reviewers: FYI

[dkhaldi]

@dm-vodopyanov is the idea to make matrix feature independent from ext_oneapi_device_architecture?
so if users use a new hardware not included yet in ext_oneapi_device_architecture, code does not crash at ext_oneapi_device_architecture level but rather they see no support of matrix for this hardware.

[AlexeySachkov]

@dm-vodopyanov is the idea to make matrix feature independent from ext_oneapi_device_architecture? so if users use a new hardware not included yet in ext_oneapi_device_architecture, code does not crash at ext_oneapi_device_architecture level but rather they see no support of matrix for this hardware.

Please note that the extension spec currently doesn't describe the behavior if HW is unsupported by the implementation which can be considered a gap in there. My reading of the extension spec is that since it returns a vector, then it should never emit an exception if HW is unknown or unrecognizable, because an empty vector serves as an indication of "matrix functionality is not supported here".

If we think that exception for unknown HW is useful, then we should probably document it explicitly in the extension spec.

[dm-vodopyanov]

@dm-vodopyanov is the idea to make matrix feature independent from ext_oneapi_device_architecture? so if users use a new hardware not included yet in ext_oneapi_device_architecture, code does not crash at ext_oneapi_device_architecture level but rather they see no support of matrix for this hardware.

Yeah, that's correct. According to matrix spec, this query can return empty vector in case architecture is not supported, so it will be for architectures which are not supported by device_architecture extension

[dm-vodopyanov]

@dm-vodopyanov is the idea to make matrix feature independent from ext_oneapi_device_architecture? so if users use a new hardware not included yet in ext_oneapi_device_architecture, code does not crash at ext_oneapi_device_architecture level but rather they see no support of matrix for this hardware.

Please note that the extension spec currently doesn't describe the behavior if HW is unsupported by the implementation which can be considered a gap in there. My reading of the extension spec is that since it returns a vector, then it should never emit an exception if HW is unknown or unrecognizable, because an empty vector serves as an indication of "matrix functionality is not supported here".

If we think that exception for unknown HW is useful, then we should probably document it explicitly in the extension spec.

Probably there is also an option to make the exception message friendlier if we want to keep throwing the exception

[dkhaldi]

@dm-vodopyanov is the idea to make matrix feature independent from ext_oneapi_device_architecture? so if users use a new hardware not included yet in ext_oneapi_device_architecture, code does not crash at ext_oneapi_device_architecture level but rather they see no support of matrix for this hardware.

Please note that the extension spec currently doesn't describe the behavior if HW is unsupported by the implementation which can be considered a gap in there. My reading of the extension spec is that since it returns a vector, then it should never emit an exception if HW is unknown or unrecognizable, because an empty vector serves as an indication of "matrix functionality is not supported here".
If we think that exception for unknown HW is useful, then we should probably document it explicitly in the extension spec.

Probably there is also an option to make the exception message friendlier if we want to keep throwing the exception

As an optional kernel feature, the extension spec does mention explicitly throwing an exception when combination is not supported:

See in https://github.com/intel/llvm/blob/sycl/sycl/doc/extensions/experimental/sycl_ext_matrix/sycl_ext_oneapi_matrix.asciidoc#backend-support-status
“if the application submits a kernel using an unsupported joint_matrix type or calls joint_matrix_mad with an unsupported combination, the implementation throws a synchronous exception with the errc::kernel_not_supported error code as described in section 5.7.”

I like the fact that we make matrix independent from ext_oneapi_device_architecture, but matrix implementation relies today on ext_oneapi_device_architecture to generate such exception, right?
Is there a way to still generate an exception in matrix for cases where architectures are not part of ext_oneapi_device_architecture?

[AlexeySachkov]

As an optional kernel feature, the extension spec does mention explicitly throwing an exception when combination is not supported:

The exception we see comes from get_info query and not from queue.submit.

I like the fact that we make matrix independent from ext_oneapi_device_architecture, but matrix implementation relies today on ext_oneapi_device_architecture to generate such exception, right?

The matrix combinations runtime query is dependent on ext_onapi_device_architecture implementation and we are not removing that. We are just fixing an edge case where the query is invoked on an unknown/unrecognizable HW.

[dkhaldi]

As an optional kernel feature, the extension spec does mention explicitly throwing an exception when combination is not supported:

The exception we see comes from get_info query and not from queue.submit.

I like the fact that we make matrix independent from ext_oneapi_device_architecture, but matrix implementation relies today on ext_oneapi_device_architecture to generate such exception, right?

The matrix combinations runtime query is dependent on ext_onapi_device_architecture implementation and we are not removing that. We are just fixing an edge case where the query is invoked on an unknown/unrecognizable HW.

What happens when the query is invoked on a known HW to ext_onapi_device_architecture but the HW was not added to the matrix query yet? do we also generate an empty vector in this case?

[AlexeySachkov]

What happens when the query is invoked on a known HW to ext_onapi_device_architecture but the HW was not added to the matrix query yet? do we also generate an empty vector in this case?

Yes. we generate an empty vector in that case

[dkhaldi]

LGTM

[dm-vodopyanov]

Failures are not related:

Failed Tests (1):
  SYCL :: Graph/RecordReplay/host_task_multiple_deps.cpp

Submitted issue: #12941

Failed Tests (1):
  SYCL :: ESIMD/dword_local_accessor_atomic_smoke.cpp

Submitted issue: #12942