<?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>i.MX Processors中的主题 Using g2d_multi_blit for interleaving data</title>
    <link>https://community.nxp.com/t5/i-MX-Processors/Using-g2d-multi-blit-for-interleaving-data/m-p/1655083#M206294</link>
    <description>&lt;P&gt;The G2D API to the 2D GPU on i.MX8 family of processors (specifically, those with GC520L GPUs) seems like the hardware should be capable of performing interleaving in a cache-efficient (bandwidth-efficient) manner.&lt;/P&gt;&lt;P&gt;If I have 4 arrays of 128K length containing int16 values, and I wish to interleave these to produce one array of length 128K, containing four int16 values, the 2D GPU blitter seems perfect: set up the problem with a 16-bit pixel format such as BGR565, and treat the four source arrays as 1-wide, 128K-high images, and the output array as a 4-wide, 128K-high image (actually, due to the 32K by 32K raster size limitation, we would split the problem into 4 parts, but still able to be done off-CPU). However, the documentation&amp;nbsp;IMXGRAPHICUG.pdf for&amp;nbsp;g2d_multi_blit says "The key restriction is that the destination rectangle cannot be set, which means that the destination rectangle must be the same as the source rectangle."&lt;/P&gt;&lt;P&gt;This seems to prevent use in this use-case&amp;nbsp; - an alternative possibility involving writing rows, and then rotating, would take two passes, because the documentation also states that the destination surface can't have non-zero rotation for&amp;nbsp;g2d_multi_blit. To do this we would have to use&amp;nbsp;g2d_multi_blit to build our four arrays into rows of a 4-high, 128K-wide image, and then use&amp;nbsp;g2d_blit to rotate this by 90 degrees (as previously, we would need to split into 4 to respect the 32K raster size limit). Whilst getting it off-CPU using this method, it is needlessly using twice as much memory bandwidth.&lt;/P&gt;&lt;P&gt;Is there a better way?&lt;/P&gt;</description>
    <pubDate>Mon, 22 May 2023 23:26:04 GMT</pubDate>
    <dc:creator>shusheer</dc:creator>
    <dc:date>2023-05-22T23:26:04Z</dc:date>
    <item>
      <title>Using g2d_multi_blit for interleaving data</title>
      <link>https://community.nxp.com/t5/i-MX-Processors/Using-g2d-multi-blit-for-interleaving-data/m-p/1655083#M206294</link>
      <description>&lt;P&gt;The G2D API to the 2D GPU on i.MX8 family of processors (specifically, those with GC520L GPUs) seems like the hardware should be capable of performing interleaving in a cache-efficient (bandwidth-efficient) manner.&lt;/P&gt;&lt;P&gt;If I have 4 arrays of 128K length containing int16 values, and I wish to interleave these to produce one array of length 128K, containing four int16 values, the 2D GPU blitter seems perfect: set up the problem with a 16-bit pixel format such as BGR565, and treat the four source arrays as 1-wide, 128K-high images, and the output array as a 4-wide, 128K-high image (actually, due to the 32K by 32K raster size limitation, we would split the problem into 4 parts, but still able to be done off-CPU). However, the documentation&amp;nbsp;IMXGRAPHICUG.pdf for&amp;nbsp;g2d_multi_blit says "The key restriction is that the destination rectangle cannot be set, which means that the destination rectangle must be the same as the source rectangle."&lt;/P&gt;&lt;P&gt;This seems to prevent use in this use-case&amp;nbsp; - an alternative possibility involving writing rows, and then rotating, would take two passes, because the documentation also states that the destination surface can't have non-zero rotation for&amp;nbsp;g2d_multi_blit. To do this we would have to use&amp;nbsp;g2d_multi_blit to build our four arrays into rows of a 4-high, 128K-wide image, and then use&amp;nbsp;g2d_blit to rotate this by 90 degrees (as previously, we would need to split into 4 to respect the 32K raster size limit). Whilst getting it off-CPU using this method, it is needlessly using twice as much memory bandwidth.&lt;/P&gt;&lt;P&gt;Is there a better way?&lt;/P&gt;</description>
      <pubDate>Mon, 22 May 2023 23:26:04 GMT</pubDate>
      <guid>https://community.nxp.com/t5/i-MX-Processors/Using-g2d-multi-blit-for-interleaving-data/m-p/1655083#M206294</guid>
      <dc:creator>shusheer</dc:creator>
      <dc:date>2023-05-22T23:26:04Z</dc:date>
    </item>
    <item>
      <title>Re: Using g2d_multi_blit for interleaving data</title>
      <link>https://community.nxp.com/t5/i-MX-Processors/Using-g2d-multi-blit-for-interleaving-data/m-p/1655813#M206376</link>
      <description>&lt;P&gt;Hello,&lt;/P&gt;
&lt;P&gt;I'm sorry but its the best way possible since a bug in gpu driver, but you must have enough memory bandwidth since you are working with MX8.&lt;/P&gt;
&lt;P&gt;Regards&lt;/P&gt;</description>
      <pubDate>Tue, 23 May 2023 14:22:57 GMT</pubDate>
      <guid>https://community.nxp.com/t5/i-MX-Processors/Using-g2d-multi-blit-for-interleaving-data/m-p/1655813#M206376</guid>
      <dc:creator>Bio_TICFSL</dc:creator>
      <dc:date>2023-05-23T14:22:57Z</dc:date>
    </item>
  </channel>
</rss>

