[SYCL] Fix failures on tests that use double datatype

[aelovikov-intel]

No description provided.

[kbobrovs]

In one of other reviews I mentioned that test reporting "Passed" state w/o actually exercising all features it is supposed to test, can be dangerous - e.g. tests run on TGLLP will report "Passed" w/o running fp64 test cases. Alternative is to extract feature-specific test cases (e.g. fp64-specific) into a separate test which would use "REQUIRES: aspect_fp64" and report "UNSUPPORTED" on TGLLP.

[aelovikov-intel]

Alternative is to extract feature-specific test cases (e.g. fp64-specific) into a separate test which would use "REQUIRES: aspect_fp64" and report "UNSUPPORTED" on TGLLP.

IMO, this is less maintainable and isn't really better. Does anybody even look at UNSUPPORTED on any regular basis? How exactly would that information be used?

[kbobrovs]

Alternative is to extract feature-specific test cases (e.g. fp64-specific) into a separate test which would use "REQUIRES: aspect_fp64" and report "UNSUPPORTED" on TGLLP.

IMO, this is less maintainable and isn't really better. Does anybody even look at UNSUPPORTED on any regular basis? How exactly would that information be used?

If nobody looks at this, this is another problem. Taking this to the extreme, a product, which passes all the tests, but all tests return "UNSUPPORTED" is not really tested and should not be released.

[v-klochkov]

Alternative is to extract feature-specific test cases (e.g. fp64-specific) into a separate test which would use "REQUIRES: aspect_fp64" and report "UNSUPPORTED" on TGLLP.

IMO, this is less maintainable and isn't really better. Does anybody even look at UNSUPPORTED on any regular basis? How exactly would that information be used?

Even though (static checks + REQUIRES) solution gives more info on which tests run or which skipped, my final vote was for device.has() because IMO using (static checks + REQUIRES) may cause quick growth of number of tests.
2 tests: is what we get after separation of fp64 test cases.
3 tests: if use same approach and separate fp16 test cases to another test.
4 tests: if we have test cases using both fp16&fp64.
That might grow exponentially with adding more independent/orthogonal features (3 or more).

[kbobrovs]

That might grow exponentially with adding more independent/orthogonal features (3 or more).

I think tests should strive to test feature alone, w/o making combination with other features. So I would not expect exponential growth of number of tests (which would actually be even worse - combinatorial explosion - if we want to test combinations).

[aelovikov-intel]

In an offline discussion we've agreed to proceed with device.has approach at least short-term.

I've also addressed @AlexeySachkov 's concern in e63b15c. Can somebody please re-review/merge?