[SYCL] Rename cuda, hip, level_zero backends to conform SYCL 2020

[ghost]

According to SYCL spec, backend::cuda is renamed to backend::ext_oneapi_cuda,
backend::hip is renamed to backend::ext_oneapi_hip, and backend::level_zero is
renamed to backend::ext_oneapi_level_zero. The backend interop APIs is available
through separate header files "sycl/ext/oneapi/backend/[backendname].hpp".

[ghost]

As I understand, the changes in the compiler (see intel/llvm#4785) must be merged before this patch.

[ghost]

The changes in the compiler has been merged, the PR is ready for review.

[AlexeySachkov]

sub_groups_sycl2020.cpp LGTM

[smaslov-intel]

Why CUDA backend has the relation to "oneapi": ext_oneapi_cuda?

[ghost]

@smaslov-intel Chupin Pavel @pvchupin has approved using oneapi as the vendorstring for the CUDA extension. In accordance to https://www.khronos.org/registry/SYCL/specs/sycl-2020/html/sycl-2020.html#_names_for_extensions_to_existing_classes_or_enumerations the enumeration for an extension backend should have the form ext_<vendorstring>_<backendname>, so ext_oneapi_cuda in our case.

[smaslov-intel]

@smaslov-intel Chupin Pavel @pvchupin has approved using oneapi as the vendorstring for the CUDA extension. In accordance to https://www.khronos.org/registry/SYCL/specs/sycl-2020/html/sycl-2020.html#_names_for_extensions_to_existing_classes_or_enumerations the enumeration for an extension backend should have the form ext_<vendorstring>_<backendname>, so ext_oneapi_cuda in our case.

This doesn't look right to me. Do you understand the reason for such direction?

[ghost]

@smaslov-intel The idea is to have CUDA as an extension since CUDA is not a backend that is defined in the SYCL 2020 specification (only opencl is). If we define CUDA as a "standard" backend as well as the opencl one is defined and in the future CUDA will really be specified in the SYCL specification, some details in the specification can be changed and not the same as we defined them. So, we will potentially have a problem: our CUDA backend is in the standard namespace and have a standard enumeration (cuda) while the behavior of the CUDA backend specified in the SYCL specification is a bit different. So, we made a decision to consider CUDA as an extension and have ext_oneapi_cuda as the backend name.

[smaslov-intel]

I agree it is an "extension" just wondering why we call it a "oneapi" extension.

[ghost]

@smaslov-intel Do I right understand, the concern is CUDA should be a part of the intel extension, not oneapi one because the CUDA extension is not built (by default?) with oneapi? @gmlueck @jbrodman could you explain why we have chosen "oneapi" as the vendorstring for CUDA and HIP extensions?

[gmlueck]

@gmlueck @jbrodman could you explain why we have chosen "oneapi" as the vendorstring for CUDA and HIP extensions?

The "vendorstring" identifies the vendor that creates the extension, so that's us. We use the vendor string "oneapi". Remember, this extension is only the interop API to CUDA / HIP. It is not the CUDA / HIP backend itself. We are not claiming ownership of those backends, only to the interop API we develop to those backends.

[ghost]

@smaslov-intel Let me bring my consideration about chosen vendorstring. Even if "oneapi" is not built with CUDA support by default, we have an open source project intel/llvm and have an instruction how to build the project from sources with the CUDA as well as HIP backends. Anyway, those extensions with the interop API are the extensions of the product and by definition of extension, they can be shipped not with all builds or versions, or "editions" of the product.

[v-klochkov]

non-blocking comment: "cl::" here could be removed. I.e. "sycl::platform" instead of "cl::sycl::platform"