Changed pi_context to ur_context_handle_t and include pi.hpp to ur.hpp

[konradkusiak97]

Description

After plugin interface removal patch in intel/llvm, the oneMKL build broke. This PR fixes it by:

• changing all occurences of #include pi.hpp to ur.hpp
• changing pi_context to ur_context_handle_t

Also, for the build to work correctly again, this patch is needed:

• [SYCL][UR] Use static cast instead of ur::cast intel/llvm#14830

[hjabird]

Hi Konrad,
A few questions:

• Can you provide test logs for everything you've changed
  • cublas, rocblas, cusolver, rocsolver
• I'm confused about the compiler compatibility right now?

[konradkusiak97]

Hi Hugh,

Yes, we've realized this would break compatibility with previous DPC++ releases so I'm working on adding some ifdefs. I'll provide the test logs as well.

[konradkusiak97]

Sorry for a delay with this as I was sick.

Here are the logs when using 2024.2.1 DPC++:
amd_test_main_lapack_rt.txt
amd_test_main_lapack_ct.txt
amd_test_main_blas_rt.txt
amd_test_main_blas_ct.txt
amd_example_lapack_getrs_usm.txt
amd_example_blas_gemm_usm.txt

nvidia_test_main_lapack_rt.txt
nvidia_test_main_lapack_ct.txt
nvidia_test_main_blas_rt.txt
nvidia_test_main_blas_ct.txt
nvidia_example_lapack_getrs_usm.txt
nvidia_example_blas_gemm_usm.txt

For 2025 DPC++ testing there are some failures with both Nvidia and AMD but I think they are unrelated to this patch. Likely the problem is with the compiler but I'm still investigating those.

[gajanan-choudhary]

Looks like this is the fix for #558 that I just opened.

[Rbiessy]

@oneapi-src/onemkl-admin this change is needed to get the CI working with a nightly compiler, a second approval would be useful.

[andrewtbarker]

This all looks fine to me. Should we have someone from @oneapi-src/onemkl-lapack-write take a quick look at the solvers changes?

[Rbiessy]

Ideally yes but I am planning to merge this tomorrow morning unless I hear an objection.

[AlexeySachkov]

Please note that instead of removing a footgun you have just reloaded it so it will fire at you once again in upcoming months (or years) when we drop UR in favor of something else.

You should not use implementation details like this in your project. Why aren't use using the official SYCL interop interface, i.e. backend_return_t<your_backend, context>?

I'm also surprised that you are changing the type of that variable without changing any of its uses, meaning that the type doesn't matter for you because it will be erased at some point. Wouldn't it be better to use some opaque type right away to avoid dependency on particular SYCL implementation?