[SYCL] Rename cuda, hip and fix renaming for level_zero backends

[ghost]

According to SYCL spec, backend::cuda was renamed to backend::ext_oneapi_cuda,
and backend::hip was renamed to backend::ext_oneapi_hip. Old names were
marked as deprecated. The renaming is also applied in the sources, tests and
unit-tests. Renaming for the Level Zero backend was also applied for the sources,
tests and unit-tests.

The following properties were moved into namespaces reserved for extensions:

• ext::oneapi::cuda::property::context::use_primary_context,
• ext::oneapi::cuda::property::queue::use_default_stream.

The interop class template was re-defined in the sycl::detail namespace since
it is not an extension of the SYCL API but just an implementation detail. The parts
of CL/sycl/backend/opencl.hpp that contain specializations for the
sycl::detail::interop class template were moved into the new created
CL/sycl/detail/backend_traits_opencl.hpp header, as well as the same parts of the
sycl/ext/oneapi/backend/level_zero.hpp header. The whole
CL/sycl/backend/cuda.hpp header file was also renamed into the
CL/sycl/detail/backend_traits_cuda.hpp one since the file contains a number of
sycl::detail::interop class template specializations only. A warning was added into
the old file.

[vladimirlaz]

please do renaming in https://github.com/intel/llvm-test-suite/ as well.

[ghost]

@bader Alexey what about namespaces? I see there are namespaces containing the "cuda" word: sycl::property::context::cuda and sycl::property::queue::cuda ones. Should these namespaces be renamed into something containing ext::openapi::cuda? In the spec I see the requirements for namespaces in monopoly use by the extension ("The namespace sycl::ext:: is reserved for use by extensions") but what about sub-namespaces for the standard namespaces?

[ghost]

@vladimirlaz I've opened a PR with renamings: intel/llvm-test-suite#521 But as I understand, the tests will pass only after merging this PR.

[bader]

According to SYCL spec, backend::cuda is renamed to backend::ext_oneapi_cuda,
backend::hip is renamed to backend::ext_oneapi_hip.

I was under impression that SYCL 2020 spec doesn't require additional extensions to implement it on top of non-OpenCL API. So this statement sounds surprising.
@AerialMantis, @gmlueck, do we really want to require non-standard extensions for back-end implementation (e.g. back-end interop) on top of CUDA, HIP or Level Zero?

[gmlueck]

@bader Alexey what about namespaces? I see there are namespaces containing the "cuda" word: sycl::property::context::cuda and sycl::property::queue::cuda ones. Should these namespaces be renamed into something containing ext::openapi::cuda?

If there are properties that are specific to the CUDA backend, the extension naming guideline would put them in the ext::oneapi::cuda namespace.

[ghost]

@gmlueck

If there are properties that are specific to the CUDA backend, the extension naming guideline would put them in the ext::oneapi::cuda namespace.

This properties are in the CL\sycl\properties\context_properties.hpp and CL\sycl\properties\queue_properties.hpp files. The first file has the following content:

namespace sycl {
namespace property {
namespace context {
namespace cuda {
class use_primary_context
    : public detail::DataLessProperty<detail::UsePrimaryContext> {};
} // namespace cuda
} // namespace context
} // namespace property
} // namespace sycl
} // __SYCL_INLINE_NAMESPACE(cl)

So, there are cuda-related properties only. Should the use_primary_context class be moved into the sycl::ext::oneapi::cuda namespace or into the sycl::property::context::ext::oneapi::cuda one?

The second file is in a bit different situation: there are a cuda-related property as well as some generic ones:

__SYCL_INLINE_NAMESPACE(cl) {
namespace sycl {
namespace property {
namespace queue {
class in_order : public detail::DataLessProperty<detail::InOrder> {};
class enable_profiling
    : public detail::DataLessProperty<detail::QueueEnableProfiling> {};
namespace cuda {
class use_default_stream
    : public detail::DataLessProperty<detail::UseDefaultStream> {};
} // namespace cuda
} // namespace queue
} // namespace property
} // namespace sycl
} // __SYCL_INLINE_NAMESPACE(cl)

But the question is the same. In which namespace the sycl::property::queue::cuda::use_default_stream class should be moved?

Thank you.

P.S. Hmm, as I see in the buffer.properties.hpp file, the use_pinned_host_memory class for oneapi is defined in the sycl::ext::oneapi::property::buffer namespace (the standard properties in this file are defined in the [cl]::sycl::property::buffer namespace.) This looks like the answer on my questions.

[gmlueck]

P.S. Hmm, as I see in the buffer.properties.hpp file, the use_pinned_host_memory class for oneapi is defined in the sycl::ext::oneapi::property::buffer namespace (the standard properties in this file are defined in the [cl]::sycl::property::buffer namespace.) This looks like the answer on my questions.

Yes, this is the pattern to follow:

• ext::oneapi::cuda::property::context::use_primary_context
• ext::oneapi::cuda::property::queue::use_default_stream

[ghost]

@vladimirlaz @gmlueck @AerialMantis @bader @againull @smaslov-intel The PR is ready for review. Could you check, please? I've updated on the current sycl branch since there were conflicts due to the new property mechanism (implemented by @steffenlarsen as I get). @steffenlarsen Could you review the renaming of properties for CUDA as well?

[steffenlarsen]

@steffenlarsen Could you review the renaming of properties for CUDA as well?

Absolutely! LGTM.

[AerialMantis]

LGTM

[againull]

PI and Level Zero part LGTM.