PI_USM_INDIRECT_ACCESS exec info is unconditionally set

[Naghasan]

Right after the creation of a kernel, piKernelSetExecInfo is unconditionally called to set PI_USM_INDIRECT_ACCESS. However not all kernels require this as they may purely use accessor, making this call unnecessary.

For an underlying runtime supporting USM this has no (or shouldn't have) implication. But if the runtime does not support it, this artificially raises the bar as it now has to support an unnecessary extension.

[AlexeySachkov]

For an underlying runtime supporting USM this has no (or shouldn't have) implication.

I'm not sure if that is the case for at least OpenCL, for example: cl_intel_unified_shared_memory. If I understand correctly, it does not guarantees that a USM pointer passed within a struct (and not directly as a kernel argument through clSetKernelArgMemPointerINTEL is accessible unless corresponding exec mode is set.

But if the runtime does not support it, this artificially raises the bar as it now has to support an unnecessary extension.

With that I agree. We could change the semantic of PI_USM_INDIRECT_ACCESS for it to mean "set if supported", but that is likely a hack. The proper solution is likely to first check if indirect access is supported and only then set the property

[steffenlarsen]

@Naghasan - Did your patch (#12780) address this issue? If yes, can we close this?

[Naghasan]

yes it does, thanks for flagging it up