OpenCL devices that don't support the UR_DEVICE_INFO_IP_VERSION query are reporting it is now causing issues.

[aarongreig]

This query is tied to an intel CL extension, it gets used in a few places in the sycl RT but always in such a way that support is optional, i.e. the typical pattern involves checking the query for success and falling back to something else if it wasn't successful. It seems the port has introduced a path somewhere that makes supporting it non-optional, which wasn't intentional and shouldn't be a necessary change. We should look to revert this.

[coldav]

For me I see this here auto Arch = Device.get_info<syclex::info::device::architecture>(); which ultimately causes UR_DEVICE_INFO_IP_VERSION which then tries to use CL_DEVICE_IP_VERSION_INTEL from https://registry.khronos.org/OpenCL/extensions/intel/cl_intel_device_attribute_query.html.

The issue started after https://github.com/intel/llvm/pull/14909, but I think only because it makes use of auto Arch = Device.get_info() which comes from (I think)

__SYCL_PARAM_TRAITS_SPEC(ext::oneapi::experimental, device, architecture, ext::oneapi::experimental::architecture, UR_DEVICE_INFO_IP_VERSION)

I can't quite work out how it is using the ip version to be honest.

It's unclear if the port caused it or not.

The test I am running is ./bin/test_address_space in SYCL-CTS

[coldav]

We are still seeing this error on OCK OpenCL (but I seem to see a different error on test_address_space now), but I still see it on test_accessor etc. Note that test_address_space now gives an INVALID_BINARY error which I hadn't been seeing before (we used to pass this test.

[RossBrunton]

Likely fixed by https://github.com/oneapi-src/unified-runtime/pull/2032

[coldav]

This does seem fixed now.