<?xml version="1.0" encoding="UTF-8"?>
<rss xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:rdf="http://www.w3.org/1999/02/22-rdf-syntax-ns#" xmlns:taxo="http://purl.org/rss/1.0/modules/taxonomy/" version="2.0">
  <channel>
    <title>topic What USM access is possible without usm_atomic_host/shared_allocations in Intel® oneAPI DPC++/C++ Compiler</title>
    <link>https://community.intel.com/t5/Intel-oneAPI-DPC-C-Compiler/What-USM-access-is-possible-without-usm-atomic-host-shared/m-p/1607409#M3870</link>
    <description>&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I'm working on the 11th gen integrated Iris Xe GPU. This GPU does *not* advertise the aspects&amp;nbsp;aspect::usm_atomic_host_allocations or&amp;nbsp;aspect::usm_atomic_shared_allocations.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Does this mean that any concurrent access at all from CPU and GPU to USM shared or host memory is unsafe, unportable or could crash?&lt;BR /&gt;&lt;BR /&gt;Is it even safe to do concurrent atomic access between different SYCL kernel work-items to USM host or shared memory ?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Or does it mean more narrowly that the specific atomic and fence guarantees in the SYCL 2020 spec are not supported - &lt;A href="https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#_interaction_with_host_code" target="_blank" rel="noopener"&gt;https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#_interaction_with_host_code&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;One possible method for a workgroup to flag that processing has finished for that workgroup's data is finished and ready to access from the CPU would be to sychronize all the workgroup work-items using a barrier and then write a flag in the output data to show that output is complete before the workgroup finishes processing.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;output_data = sycl::malloc_shared();&amp;nbsp; &amp;nbsp;// output data for kernel with separate ranges for each workgroup&lt;BR /&gt;// zero initialise output_data before kernel runs&lt;/P&gt;&lt;P&gt;const auto e = q.parallel_for ( sycl::nd_range { global_range, local_range },&lt;BR /&gt;[ = ] ( sycl::nd_item&amp;lt;2&amp;gt; idx )&lt;BR /&gt;{&lt;BR /&gt;&amp;nbsp; // write N results in output_data from workgroup_offset&amp;nbsp;&lt;BR /&gt;&lt;BR /&gt;&amp;nbsp; idx.get_group().barrier();&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp; if (idx.get_group().leader())&lt;/P&gt;&lt;P&gt;&amp;nbsp; {&lt;BR /&gt;&amp;nbsp; &amp;nbsp; // flag to CPU that this workgroup has finished writing its results&lt;BR /&gt;&amp;nbsp; &amp;nbsp; output_data[workgroup_offset + N] = 1;&lt;/P&gt;&lt;P&gt;&amp;nbsp; }&lt;/P&gt;&lt;P&gt;}&amp;nbsp;);&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Is this likely to crash or fail to guarantee the output_data results are visible to the CPU if the flag is set and cause race conditions?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Mon, 17 Jun 2024 17:26:39 GMT</pubDate>
    <dc:creator>MikeDB</dc:creator>
    <dc:date>2024-06-17T17:26:39Z</dc:date>
    <item>
      <title>What USM access is possible without usm_atomic_host/shared_allocations</title>
      <link>https://community.intel.com/t5/Intel-oneAPI-DPC-C-Compiler/What-USM-access-is-possible-without-usm-atomic-host-shared/m-p/1607409#M3870</link>
      <description>&lt;P&gt;Hi,&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;I'm working on the 11th gen integrated Iris Xe GPU. This GPU does *not* advertise the aspects&amp;nbsp;aspect::usm_atomic_host_allocations or&amp;nbsp;aspect::usm_atomic_shared_allocations.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Does this mean that any concurrent access at all from CPU and GPU to USM shared or host memory is unsafe, unportable or could crash?&lt;BR /&gt;&lt;BR /&gt;Is it even safe to do concurrent atomic access between different SYCL kernel work-items to USM host or shared memory ?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Or does it mean more narrowly that the specific atomic and fence guarantees in the SYCL 2020 spec are not supported - &lt;A href="https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#_interaction_with_host_code" target="_blank" rel="noopener"&gt;https://registry.khronos.org/SYCL/specs/sycl-2020/html/sycl-2020.html#_interaction_with_host_code&lt;/A&gt;&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;One possible method for a workgroup to flag that processing has finished for that workgroup's data is finished and ready to access from the CPU would be to sychronize all the workgroup work-items using a barrier and then write a flag in the output data to show that output is complete before the workgroup finishes processing.&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;output_data = sycl::malloc_shared();&amp;nbsp; &amp;nbsp;// output data for kernel with separate ranges for each workgroup&lt;BR /&gt;// zero initialise output_data before kernel runs&lt;/P&gt;&lt;P&gt;const auto e = q.parallel_for ( sycl::nd_range { global_range, local_range },&lt;BR /&gt;[ = ] ( sycl::nd_item&amp;lt;2&amp;gt; idx )&lt;BR /&gt;{&lt;BR /&gt;&amp;nbsp; // write N results in output_data from workgroup_offset&amp;nbsp;&lt;BR /&gt;&lt;BR /&gt;&amp;nbsp; idx.get_group().barrier();&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;&amp;nbsp; if (idx.get_group().leader())&lt;/P&gt;&lt;P&gt;&amp;nbsp; {&lt;BR /&gt;&amp;nbsp; &amp;nbsp; // flag to CPU that this workgroup has finished writing its results&lt;BR /&gt;&amp;nbsp; &amp;nbsp; output_data[workgroup_offset + N] = 1;&lt;/P&gt;&lt;P&gt;&amp;nbsp; }&lt;/P&gt;&lt;P&gt;}&amp;nbsp;);&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;&lt;P&gt;Is this likely to crash or fail to guarantee the output_data results are visible to the CPU if the flag is set and cause race conditions?&lt;/P&gt;&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Mon, 17 Jun 2024 17:26:39 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-oneAPI-DPC-C-Compiler/What-USM-access-is-possible-without-usm-atomic-host-shared/m-p/1607409#M3870</guid>
      <dc:creator>MikeDB</dc:creator>
      <dc:date>2024-06-17T17:26:39Z</dc:date>
    </item>
    <item>
      <title>Re: What USM access is possible without usm_atomic_host/shared_allocations</title>
      <link>https://community.intel.com/t5/Intel-oneAPI-DPC-C-Compiler/What-USM-access-is-possible-without-usm-atomic-host-shared/m-p/1610080#M3910</link>
      <description>&lt;P&gt;It's true that&amp;nbsp;11th generation integrated Iris Xe GPU does not support the SYCL aspects "aspect::usm_atomic_host_allocation" and "aspect::usm_atomic_shared_allocations," so there are indeed potential limiations or incompatibility when using these aspects. Please check&amp;nbsp;&lt;A href="https://github.khronos.org/SYCL_Reference/iface/interaction-with-host-code.html" target="_blank"&gt;https://github.khronos.org/SYCL_Reference/iface/interaction-with-host-code.html&lt;/A&gt;&amp;nbsp;and&amp;nbsp;&lt;A href="https://github.com/IntelPython/dpctl/issues/309" target="_blank"&gt;https://github.com/IntelPython/dpctl/issues/309&lt;/A&gt;&lt;/P&gt;</description>
      <pubDate>Wed, 26 Jun 2024 19:28:51 GMT</pubDate>
      <guid>https://community.intel.com/t5/Intel-oneAPI-DPC-C-Compiler/What-USM-access-is-possible-without-usm-atomic-host-shared/m-p/1610080#M3910</guid>
      <dc:creator>Alex_Y_Intel</dc:creator>
      <dc:date>2024-06-26T19:28:51Z</dc:date>
    </item>
  </channel>
</rss>

