Using the nvidia opencl runtime

[fcharras]

Can opencl sycl devices be nvidia opencl devices ?

I have libnvidia-opencl.so.1 installed and the icd is correctly configured and clinfo can detect the device, but this device is not detected as a sycl device.

The corresponding cuda device is properly detected (assuming the --cuda flag at build time).

I have not seen this mentioned much in documentation so was wondering if it's normal or not to not see nvidia opencl devices show up as sycl devices, if not what in general prevents interoperability between intel opencl and nvidia opencl backends ?

[npmiller]

Yes it's normal to not see Nvidia OpenCL devices.

They're currently blacklisted because they don't work with the binaries we generate with DPC++, I'm a little unsure about the details but I believe they don't currently support SPIR-V and the PTX we generate for the CUDA backend of DPC++ also doesn't work with the Nvidia OpenCL devices.

Here's the PR blacklisting it from a while back, with some more discussions on this:

• [SYCL][CUDA] Improvements to CUDA device selection #1689

In general I would advise using the CUDA plugin for Nvidia devices.

Ideally we probably should be able to support Nvidia OpenCL devices but our focus has been on the CUDA plugin. Out of curiosity, what are you trying to do that needs Nvidia OpenCL and wouldn't work with the CUDA plugin?

[fcharras]

I'm exploring the interoperability potential of the python software stack dpnp / dpctl / numba_dpex, see e.g IntelPython/dpctl#947 . I'm writing kernels with numba_dpex and investigated the possibility to distribute and run it on the largest possible scope of devices. ATM dpctl does not support compiling kernels for cuda (see issue), I thought maybe adapting the opencl support for intel hardware to other opencl runtimes might be an easier leap. I'm not well used to c/c++ programming myself I'm more trying to inquiry the potential for interoperability in general from the point of view of higher level layers of code.

[npmiller]

Oh I see, that's interesting!

Unfortunately, even if we did support Nvidia OpenCL, I don't think it would help in this case. As far as I understand it, for Level Zero and the Intel OpenCL dpctl is compiling the kernels first to SPIR-V intermediate representation, and then feeding that to the Level Zero and OpenCL runtime which compile it further down to the actual target architecture.

Unfortunately as I understand it, Nvidia OpenCL doesn't support SPIR-V, so just like the current CUDA backend, it couldn't use the same compilation workflow as Level Zero and Intel OpenCL (or other OpenCL drivers supporting SPIR-V).

For CUDA the kernels need to be compiled directly to PTX, so the compilation must be handled differently, and I'm not aware of any way around that at the moment.

[fcharras]

Yes I think that's what happens in dpctl. Thank you for the added explanations it's very informative and really help understanding the remaining barriers.

[AlexeySachkov]

@fcharras, can we close the issue or you have some other questions on the topic?

[fcharras]

The questions has been answered let's close it, thank you 👍