https://community.intel.com/t5/OpenCL-for-CPU/OpenCL-Using-USM-on-Intel-CPU-Runtime-along-with/m-p/1621200#M7351 <P>Hi, I had a brief look at this issue. Continuing the discussion from the GitHub issue:</P><P>I don't think the call to enable&nbsp;<SPAN>CL_KERNEL_EXEC_INFO_INDIRECT_SHARED_ACCESS_INTEL is required.&nbsp; The test app isn't making any SHARED allocations, so this call will have no affect.&nbsp; Enabling CL_KERNEL_EXEC_INFO_INDIRECT_DEVICE_ACCESS_INTEL does have an affect, but because the set of USM pointers is explicitly provided using CL_KERNEL_EXEC_INFO_USM_PTRS_INTEL, enabling indirect access globally for all DEVICE allocations is redundant.</SPAN></P><P><SPAN>Note: enabling&nbsp;CL_KERNEL_EXEC_INFO_INDIRECT_DEVICE_ACCESS_INTEL does "fix" this issue, but I think this is overkill and shouldn't be required.&nbsp; Said another way, if the global indirect access flag is enabled then there is no need to pass any set of USM pointers explicitly.</SPAN></P><P><SPAN>I don't see anything wrong with the call to provide the set of USM pointers with&nbsp;CL_KERNEL_EXEC_INFO_USM_PTRS_INTEL, and it works with several other USM implementations I've tried.</SPAN></P><P>Perhaps a good next step would be for somebody on the CPU OpenCL runtime team to report why the call to clEnqueueNDRangeKernel is returning CL_INVALID_OPERATION when the set of USM pointers is provided explicitly by&nbsp;<SPAN>CL_KERNEL_EXEC_INFO_USM_PTRS_INTEL and indirect access is NOT enabled globally.</SPAN></P><P><SPAN>Thanks!</SPAN></P> Tue, 06 Aug 2024 15:00:25 GMT Ben_A_Intel 2024-08-06T15:00:25Z https://community.intel.com/t5/OpenCL-for-CPU/OpenCL-Using-USM-on-Intel-CPU-Runtime-along-with/m-p/1621136#M7350 <P>Original issue:&nbsp;<A href="https://github.com/intel/compute-runtime/issues/748" target="_blank" rel="noopener">https://github.com/intel/compute-runtime/issues/748</A></P><P>&nbsp;</P><P>&nbsp;</P> Tue, 06 Aug 2024 11:49:01 GMT https://community.intel.com/t5/OpenCL-for-CPU/OpenCL-Using-USM-on-Intel-CPU-Runtime-along-with/m-p/1621136#M7350 Paulius_V_ 2024-08-06T11:49:01Z https://community.intel.com/t5/OpenCL-for-CPU/OpenCL-Using-USM-on-Intel-CPU-Runtime-along-with/m-p/1621200#M7351 <P>Hi, I had a brief look at this issue. Continuing the discussion from the GitHub issue:</P><P>I don't think the call to enable&nbsp;<SPAN>CL_KERNEL_EXEC_INFO_INDIRECT_SHARED_ACCESS_INTEL is required.&nbsp; The test app isn't making any SHARED allocations, so this call will have no affect.&nbsp; Enabling CL_KERNEL_EXEC_INFO_INDIRECT_DEVICE_ACCESS_INTEL does have an affect, but because the set of USM pointers is explicitly provided using CL_KERNEL_EXEC_INFO_USM_PTRS_INTEL, enabling indirect access globally for all DEVICE allocations is redundant.</SPAN></P><P><SPAN>Note: enabling&nbsp;CL_KERNEL_EXEC_INFO_INDIRECT_DEVICE_ACCESS_INTEL does "fix" this issue, but I think this is overkill and shouldn't be required.&nbsp; Said another way, if the global indirect access flag is enabled then there is no need to pass any set of USM pointers explicitly.</SPAN></P><P><SPAN>I don't see anything wrong with the call to provide the set of USM pointers with&nbsp;CL_KERNEL_EXEC_INFO_USM_PTRS_INTEL, and it works with several other USM implementations I've tried.</SPAN></P><P>Perhaps a good next step would be for somebody on the CPU OpenCL runtime team to report why the call to clEnqueueNDRangeKernel is returning CL_INVALID_OPERATION when the set of USM pointers is provided explicitly by&nbsp;<SPAN>CL_KERNEL_EXEC_INFO_USM_PTRS_INTEL and indirect access is NOT enabled globally.</SPAN></P><P><SPAN>Thanks!</SPAN></P> Tue, 06 Aug 2024 15:00:25 GMT https://community.intel.com/t5/OpenCL-for-CPU/OpenCL-Using-USM-on-Intel-CPU-Runtime-along-with/m-p/1621200#M7351 Ben_A_Intel 2024-08-06T15:00:25Z