[SYCL] kernel_compiler support of OpenCL queries

[cperkinsintel]

This PR both includes and realizes the new specification here originally drafted here: #11994

[densamoilov]

The new API to query OpenCL extensions/features requires a minimum version of ocloc and hence a minimum version of the GPU driver. The documentation says that the latest GPU driver should be used for development, which I find confusing as the latest GPU driver would also be required for running an application that uses the new API.

I also, couldn't find any requirements for the GPU driver for the open-source DPC++ compiler.

The fact that the API may or may not work depending on a version of the GPU driver is confusing so we need to make an effort to let the users know what minimum version of the GPU driver they have to use.

[bader]

couldn't find any requirements for the GPU driver for the open-source DPC++ compiler.

FYI: https://github.com/intel/llvm/blob/sycl/devops/dependencies.json

[gmlueck]

I think this test looks good, but I don't understand how this REQUIIRES selects a CUDA or HIP device. Does it?

What does REQUIRES: ocloc really mean? Does it just mean that ocloc is present on the PATH? If that is the case, you could easily imagine a case where ocloc is on the PATH, but we are still running on a CUDA device.

[cperkinsintel]

I have changed this to // REQUIRES: !ocloc && !opencl && !level_zero and the others to ocloc && (opencl || level_zero)

[gmlueck]

I still don't understand the exact meaning of REQUIRES: ocloc. Does this mean that ocloc is on the PATH?

If so, wouldn't we want the test to fail if ocloc is not on the PATH when running on Level Zero or OpenCL? Isn't it a bug if ocloc is not available in that case?

[cperkinsintel]

Yes, // REQUIRES: ocloc means ocloc is on the PATH. And // REQUIRES: !ocloc means that it is affirmed to NOT be on the PATH.

As it now with my latest change, if the situation of "L0 but no ocloc" or "CUDA but with ocloc" comes up then the test will be skipped as UNSUPPORTED. If I were to go back to just requiring ocloc (or not) then the test would fail in those situations - which might arguably be better because it would alert us to a change or misconfiguration.

As to what it means if we have L0 but not ocloc, that I can't say. You have said that ocloc is "an implementation detail". And that's not unreasonable. The drivers could potentially run perfectly fine without ocloc being exposed on the path. In those cases the kernel_compiler will simply not work for opencl language ( it throws exceptions / returns false depending on the call in that situation), and if that configuration appears then these tests will be skipped over as UNSUPPORTED.

But if it means that it's a bug, then, yes, I should return these //REQUIRES: directives to just focus on ocloc or not and we'll get failures in the future if that happens. Arguably, if it's a bug (not merely an implementation detail) then perhaps these opencl queries should throw exceptions if ocloc isn't present, rather than returning false.

Let me know.

[gmlueck]

Could we do the following:

• Change the positive test to REQUIRES: (opencl || level_zero)
• Change the negative test to REQUIRES: !opencl && !level_zero

The positive test expects d.ext_oneapi_can_compile(syclex::source_language::opencl) to be true. If ocloc is missing for some reason, that query will return false and the test will fail. That makes sense because ocloc is required part of the implementation on these backends, so we want the test to fail if it is somehow missing.

[cperkinsintel]

One last wrinkle I overlooked: opencl:fpga . I'll add an unsupported line for that (simplest)