<?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 Best practices for handling variable width sub_group sizes? in OpenCL* for CPU</title>
    <link>https://community.intel.com/t5/OpenCL-for-CPU/Best-practices-for-handling-variable-width-sub-group-sizes/m-p/1110084#M5267</link>
    <description>&lt;P style="word-wrap: break-word; font-size: 12px;"&gt;I wrote the following back in May 2015:&lt;/P&gt;

&lt;BLOCKQUOTE&gt;
	&lt;P style="word-wrap: break-word; font-size: 12px;"&gt;It would be great to get some sort of compile-time indication or guarantee that a certain size subgroup was selected in order to close off certain code paths.&lt;/P&gt;

	&lt;P style="word-wrap: break-word; font-size: 12px;"&gt;If only the compiler can determine the subgroup size and your codebase is dependent on a certain subgroup size and variations in the code result in changes to the subgroup size then ... it becomes a circular mess.&lt;/P&gt;

	&lt;P style="word-wrap: break-word; font-size: 12px;"&gt;There is always the option of probing the subgroup size at&amp;nbsp;&lt;EM&gt;runtime&lt;/EM&gt;&amp;nbsp;with&amp;nbsp;get_sub_group_size()&amp;nbsp;but I would caution against that approach. &amp;nbsp;It may be portable but it's probably not performant.&lt;/P&gt;

	&lt;P style="word-wrap: break-word; font-size: 12px;"&gt;But if get_sub_group_size()&amp;nbsp;was a compile time constant resolved early enough to snip dead code then it would provide portability and performance.&lt;/P&gt;

	&lt;P style="word-wrap: break-word; font-size: 12px;"&gt;It would be great to hear how Intel actually implements this super useful extension.&lt;/P&gt;
&lt;/BLOCKQUOTE&gt;

&lt;P style="word-wrap: break-word; font-size: 12px;"&gt;Is there any new info on how and when sub_group sizes are determined in Intel Processor Graphics OpenCL and whether or not a sub_group size can ever be an optimizable compile time constant (maybe it can't if get_sub_group_size() and get_max_sub_group_size() are not always equal)?&lt;/P&gt;

&lt;P style="word-wrap: break-word; font-size: 12px;"&gt;As implied above, Intel GEN appears to be unique in allowing the compiler to determine the "warp" (SIMD) width at compile time.&lt;/P&gt;

&lt;P style="word-wrap: break-word; font-size: 12px;"&gt;A small change to a kernel might result in switching from SIMD8 to SIMD16 sub groups.&lt;/P&gt;

&lt;P style="word-wrap: break-word; font-size: 12px;"&gt;My experience so far is that this flexibility forces a defensive assumption that SIMD8 is the widest sub_group that can be relied upon and that various work item id calculations have to be performed explicitly: e.g. "get_local_id(0) &amp;amp; 7" instead of "get_sub_group_local_id()".&lt;/P&gt;

&lt;P style="word-wrap: break-word; font-size: 12px;"&gt;Some tips and tricks on this subject would be appreciated!&lt;/P&gt;

&lt;P style="word-wrap: break-word; font-size: 12px;"&gt;&amp;nbsp;&lt;/P&gt;</description>
    <pubDate>Wed, 24 Aug 2016 17:35:25 GMT</pubDate>
    <dc:creator>allanmac1</dc:creator>
    <dc:date>2016-08-24T17:35:25Z</dc:date>
    <item>
      <title>Best practices for handling variable width sub_group sizes?</title>
      <link>https://community.intel.com/t5/OpenCL-for-CPU/Best-practices-for-handling-variable-width-sub-group-sizes/m-p/1110084#M5267</link>
      <description>&lt;P style="word-wrap: break-word; font-size: 12px;"&gt;I wrote the following back in May 2015:&lt;/P&gt;

&lt;BLOCKQUOTE&gt;
	&lt;P style="word-wrap: break-word; font-size: 12px;"&gt;It would be great to get some sort of compile-time indication or guarantee that a certain size subgroup was selected in order to close off certain code paths.&lt;/P&gt;

	&lt;P style="word-wrap: break-word; font-size: 12px;"&gt;If only the compiler can determine the subgroup size and your codebase is dependent on a certain subgroup size and variations in the code result in changes to the subgroup size then ... it becomes a circular mess.&lt;/P&gt;

	&lt;P style="word-wrap: break-word; font-size: 12px;"&gt;There is always the option of probing the subgroup size at&amp;nbsp;&lt;EM&gt;runtime&lt;/EM&gt;&amp;nbsp;with&amp;nbsp;get_sub_group_size()&amp;nbsp;but I would caution against that approach. &amp;nbsp;It may be portable but it's probably not performant.&lt;/P&gt;

	&lt;P style="word-wrap: break-word; font-size: 12px;"&gt;But if get_sub_group_size()&amp;nbsp;was a compile time constant resolved early enough to snip dead code then it would provide portability and performance.&lt;/P&gt;

	&lt;P style="word-wrap: break-word; font-size: 12px;"&gt;It would be great to hear how Intel actually implements this super useful extension.&lt;/P&gt;
&lt;/BLOCKQUOTE&gt;

&lt;P style="word-wrap: break-word; font-size: 12px;"&gt;Is there any new info on how and when sub_group sizes are determined in Intel Processor Graphics OpenCL and whether or not a sub_group size can ever be an optimizable compile time constant (maybe it can't if get_sub_group_size() and get_max_sub_group_size() are not always equal)?&lt;/P&gt;

&lt;P style="word-wrap: break-word; font-size: 12px;"&gt;As implied above, Intel GEN appears to be unique in allowing the compiler to determine the "warp" (SIMD) width at compile time.&lt;/P&gt;

&lt;P style="word-wrap: break-word; font-size: 12px;"&gt;A small change to a kernel might result in switching from SIMD8 to SIMD16 sub groups.&lt;/P&gt;

&lt;P style="word-wrap: break-word; font-size: 12px;"&gt;My experience so far is that this flexibility forces a defensive assumption that SIMD8 is the widest sub_group that can be relied upon and that various work item id calculations have to be performed explicitly: e.g. "get_local_id(0) &amp;amp; 7" instead of "get_sub_group_local_id()".&lt;/P&gt;

&lt;P style="word-wrap: break-word; font-size: 12px;"&gt;Some tips and tricks on this subject would be appreciated!&lt;/P&gt;

&lt;P style="word-wrap: break-word; font-size: 12px;"&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Wed, 24 Aug 2016 17:35:25 GMT</pubDate>
      <guid>https://community.intel.com/t5/OpenCL-for-CPU/Best-practices-for-handling-variable-width-sub-group-sizes/m-p/1110084#M5267</guid>
      <dc:creator>allanmac1</dc:creator>
      <dc:date>2016-08-24T17:35:25Z</dc:date>
    </item>
    <item>
      <title>Indeed.</title>
      <link>https://community.intel.com/t5/OpenCL-for-CPU/Best-practices-for-handling-variable-width-sub-group-sizes/m-p/1110085#M5268</link>
      <description>&lt;P&gt;&lt;SPAN style="font-size: 1em; line-height: 1.5;"&gt;Indeed.&lt;/SPAN&gt;&lt;/P&gt;

&lt;P&gt;&lt;A href="https://www.khronos.org/registry/cl/extensions/intel/cl_intel_required_subgroup_size.txt" target="_blank"&gt;https://www.khronos.org/registry/cl/extensions/intel/cl_intel_required_subgroup_size.txt&lt;/A&gt;&lt;/P&gt;

&lt;P&gt;There is a minimum HW requirement, so I am not sure which platform it becomes available.&lt;/P&gt;

&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Mon, 29 Aug 2016 21:31:46 GMT</pubDate>
      <guid>https://community.intel.com/t5/OpenCL-for-CPU/Best-practices-for-handling-variable-width-sub-group-sizes/m-p/1110085#M5268</guid>
      <dc:creator>Timothy_B_Intel</dc:creator>
      <dc:date>2016-08-29T21:31:46Z</dc:date>
    </item>
    <item>
      <title>Aww yiss!  That looks perfect</title>
      <link>https://community.intel.com/t5/OpenCL-for-CPU/Best-practices-for-handling-variable-width-sub-group-sizes/m-p/1110086#M5269</link>
      <description>&lt;P&gt;Aww yiss! &amp;nbsp;&lt;SPAN style="font-size: 1em; line-height: 1.5;"&gt;That looks perfect&lt;/SPAN&gt;&lt;SPAN style="font-size: 1em; line-height: 1.5;"&gt;.&lt;/SPAN&gt;&lt;/P&gt;

&lt;P&gt;&amp;nbsp;&lt;/P&gt;</description>
      <pubDate>Mon, 29 Aug 2016 21:47:32 GMT</pubDate>
      <guid>https://community.intel.com/t5/OpenCL-for-CPU/Best-practices-for-handling-variable-width-sub-group-sizes/m-p/1110086#M5269</guid>
      <dc:creator>allanmac1</dc:creator>
      <dc:date>2016-08-29T21:47:32Z</dc:date>
    </item>
  </channel>
</rss>

