使用NEON优化Cortex-A8的颜色转换

5

我目前正在进行一种颜色转换程序,以将YUY2转换为NV12。

我有一个函数非常快,但不如我预期的那么快,主要是由于缓存未命中。

void convert_hd(uint8_t *orig, uint8_t *result) {
uint32_t width          = 1280;
uint32_t height         = 720;
uint8_t *lineOdd        = orig;
uint8_t *lineEven       = orig + width*2;
uint8_t *resultYOdd     = result;
uint8_t *resultYEven    = result + width;
uint8_t *resultUV       = result + height*width;
uint32_t totalLoop      = height/2;

while (totalLoop-- > 0) {
  uint32_t lineLoop = 1280/32; // Bytes length: width*2, read by iter 16Bytes

  while(lineLoop-- > 0) {
    __asm__ __volatile__(
        "pld [%[lineOdd]]   \n\t"
        "vld4.8   {d0, d1, d2, d3}, [%[lineOdd],:128]!   \n\t" // d0:Y d1:U0 d2:Y d3:V0
        "pld [%[lineEven]]   \n\t"
        "vld4.8   {d4, d5, d6, d7}, [%[lineOdd],:128]!   \n\t" // d4:Y d5:U1 d6:Y d7:V1
        "vld4.8   {d8, d9, d10, d11}, [%[lineEven],:128]!  \n\t" // d8:Y d9:U0' d10:Y d11:V0'
        "vld4.8   {d12, d13, d14, d15}, [%[lineEven],:128]!  \n\t" // d12:Y d13:U1' d14:Y d15:V1'
        "vhadd.u8   d1, d1, d9    \n\t" // (U0+U0') / 2
        "vhadd.u8   d3, d3, d11    \n\t" // (V0+V0') / 2
        "vhadd.u8   d5, d5, d13    \n\t" // (U1+U1') / 2
        "vhadd.u8   d7, d7, d15    \n\t" // (V1+V1') / 2
        // Save
        "vst2.8 {d0, d2}, [%[resultYOdd],:128]!           \n\t"
        "vst2.8 {d4, d6}, [%[resultYOdd],:128]!           \n\t"
        "vst2.8 {d8, d10}, [%[resultYEven],:128]!          \n\t"
        "vst2.8 {d12, d14}, [%[resultYEven],:128]!          \n\t"
        "vst2.8 {d1, d3}, [%[resultUV],:128]!   \n\t"
        "vst2.8 {d5, d7}, [%[resultUV],:128]!   \n\t"
        : [lineOdd]"+r"(lineOdd), [lineEven]"+r"(lineEven), [resultYOdd]"+r"(resultYOdd), [resultYEven]"+r"(resultYEven), [resultUV]"+r"(resultUV)
        :
        : "memory"
    );
  }
  lineOdd += width*2;
  lineEven += width*2;
  resultYOdd += width;
  resultYEven += width;
}
}

当我询问oprofile程序占用时间的情况时,它会返回以下信息:
                                           :    220c:   add r2, r0, #2560   ;
                                           :    2210:   add r3, r1, #1280   ;
                                           :    2214:   add ip, r1, #921600 ;
                                           :    2218:   push    {r4, lr}
                                           :    221c:   mov r4, #360    ;
 6  0.1243    10  0.5787     4  0.4561     :    2220:   mov lr, #40 ; 0x28
 9  0.1864     5  0.2894     0       0     :    2224:   pld [r0]
45  0.9321     7  0.4051     3  0.3421     :    2228:   vld4.8  {d0-d3}, [r0 :128]!
51  1.0563     7  0.4051     1  0.1140     :    222c:   pld [r2]
 1  0.0207     1  0.0579     0       0     :    2230:   vld4.8  {d4-d7}, [r0 :128]!
1360 28.1690   770 44.5602   463 52.7936     :    2234: vld4.8  {d8-d11}, [r2 :128]!
 980 20.2983   329 19.0394   254 28.9624     :    2238: vld4.8  {d12-d15}, [r2 :128]!
                                             :    223c: vhadd.u8    d1, d1, d9
1000 20.7125   170  9.8380   104 11.8586     :    2240: vhadd.u8    d3, d3, d11
                                             :    2244: vhadd.u8    d5, d5, d13
   5  0.1036     2  0.1157     2  0.2281     :    2248: vhadd.u8    d7, d7, d15
                                             :    224c: vst2.8  {d0,d2}, [r1 :128]!
1125 23.3016   293 16.9560    15  1.7104     :    2250: vst2.8  {d4,d6}, [r1 :128]!
  34  0.7042    41  2.3727     0       0     :    2254: vst2.8  {d8,d10}, [r3 :128]!
  74  1.5327     8  0.4630     0       0     :    2258: vst2.8  {d12,d14}, [r3 :128]!
  60  1.2428    39  2.2569     6  0.6842     :    225c: vst2.8  {d1,d3}, [ip :128]!
  53  1.0978    24  1.3889    14  1.5964     :    2260: vst2.8  {d5,d7}, [ip :128]!
                                             :    2264: subs    lr, lr, #1
   0       0     0       0     1  0.1140     :    2268: bne 2224 <convert_hd+0x18>
  11  0.2278    14  0.8102    10  1.1403     :    226c: subs    r4, r4, #1
                                             :    2270: add r0, r0, #2560   ;
                                             :    2274: add r2, r2, #2560   ;
   2  0.0414     6  0.3472     0       0     :    2278: add r1, r1, #1280   ;
                                             :    227c: add r3, r3, #1280   ;
   2  0.0414     1  0.0579     0       0     :    2280: bne 2220 <convert_hd+0x14>
                                             :    2284: pop {r4, pc}
  • 前两列是循环计数(绝对和相对)
  • 接下来的两列是L1缓存未命中(绝对和相对)
  • 最后两列是L2缓存未命中(绝对和相对)

因为现在找出思路并避免缓存未命中是相当困难的任务,所以任何帮助都将不胜感激...

谢谢!


2
有一个看起来可以改进的地方是你对缓存预加载的使用。通过使用PLD [R2],你告诉系统预加载你即将读取的内存。你需要做的是告诉它在你读取数据之前预加载数据,这样当你需要时它就已经准备好了(例如:PLD [R2,#0x200])。 - BitBank
1
无法避免缓存未命中,因为CPU比内存快得多。通过优化R0和R2的预加载距离,可以最小化未命中。尝试不同的距离,直到找到最佳距离。这通常可以将速度提高20-25%。 - BitBank
1
另一个可以加速的方法是再展开一次循环。你只使用了 NEON 寄存器的一半。 - BitBank
@BitBank另一方面可能只有16个D寄存器,就像VFPv3-D16那样? - auselen
1
你无法避免缓存未命中,但可以提高缓存未命中率。这就是你要达到的目标。如果你真的想做到这一点,首先要移除PLDs,将循环转换为单个循环,确保origin和result与缓存行大小对齐,交错加载和存储,并在此过程中进行计时并找到最佳布局,然后再添加一些PLDs。PLDs应该始终比当前所做的事情超前,但不要太远。如果这不是Cortex-A8,我会建议完全放弃它,因为在不同核心上通用/广泛使用时很难正确实现。 - auselen
显示剩余9条评论
1个回答

1
缓存行长度固定为8个字(32字节)。除了您当前拥有的pld,您还需要pld [lineEven+cacheLine]。缺失是vld4.8 {d8-d11},这是lineEven的第二个一半。 pld仅会获取一个缓存行。此外,您应该改变pld的位置。在vhadd之前放置一个,也许是下一个内存目标。 然后你可以同时激活ALU和内存单元。
此外,将vst2.8 {d0,d2}vhadd交错使用;看起来大多数数据都是内存传输。 vhadd将阻塞数据依赖项,例如您可能从pld中加载的d9,但调度不好。
我对NEON并不太熟悉,但以下是尝试遵循我所说的。
__asm__ __volatile__(
    "pld [%[lineOdd], #32]\n\t" // 2nd part of odd.
    "vld4.8   {d0, d1, d2, d3}, [%[lineOdd],:128]!\n\t"
    "pld [%[lineEven], #32]\n\t" // 2nd part of even.
    "vld4.8   {d8, d9, d10, d11}, [%[lineEven],:128]!\n\t"
    "vld4.8   {d4, d5, d6, d7}, [%[lineOdd],:128]!\n\t"
    "vld4.8   {d12, d13, d14, d15}, [%[lineEven],:128]!\n\t" 
    "vhadd.u8   d1, d1, d9\n\t"
    // First in memory pipe, so write early.
    "vst2.8 {d0, d2}, [%[resultYOdd],:128]!\n\t"  
    "vhadd.u8   d3, d3, d11\n\t"
    "vst2.8 {d8, d10}, [%[resultYEven],:128]!\n\t"
    "vhadd.u8   d5, d5, d13\n\t"
    "vst2.8 {d4, d6}, [%[resultYOdd],:128]!           \n\t"
    "vhadd.u8   d7, d7, d15\n\t"
    "vst2.8 {d12, d14}, [%[resultYEven],:128]!          \n\t"
    "pld [%[lineOdd]]\n\t"   // 1st part of odd.
    "vst2.8 {d1, d3}, [%[resultUV],:128]!   \n\t"
    "pld [%[lineEven]]\n\t"  // 1st part of even.
    "vst2.8 {d5, d7}, [%[resultUV],:128]!   \n\t"
    : [lineOdd]"+r"(lineOdd), [lineEven]"+r"(lineEven),
      [resultYOdd]"+r"(resultYOdd), [resultYEven]"+r"(resultYEven),
      [resultUV]"+r"(resultUV)
    :
    : "memory"
);

我可能错的地方在于 NEON 操作的步幅,我不知道你的寄存器有多宽(64/128),因此可能需要更多的 PLD。最好将存储操作与加法交替进行,特别是某些 dX 将在其他之前加载并准备好使用,否则您的 ALU (vhadd) 将因等待数据加载而阻塞。
在开始之前,您可能还想在循环中使用 pld[lineOdd]pld[lineEven] 进行预热。

1
预加载距离与缓存行长度无关,它关乎系统需要多少时间来读取内存,以便在您的代码需要时准备好。 - BitBank
1
PLD for Cortex-A8PLD for Cortex-A5;它们都涉及缓存和缓存行。此外,OP提供的数据支持第二个部分缺失的事实。请参阅Linux copy template,其中包含其 PLD 值。 - artless noise
1
True - 需要发出多个预加载指令来加载正在处理的数量。我想我误解了你的答案,认为它应该与缓存行长度相隔一定距离。 - BitBank
我刚刚尝试了你的代码,@artlessnoise,并且分析的结果在这里: http://pastebin.com/T79H2Sfm 如你所见,它并不是很好(实际上,时间效率也不好)。 - jmh
@jmh 将 vld4.8 {d4-d7}vld4.8 {d12-d15} 向下移至 vhadd.u8 d5, d5, d13;这些是缓存未命中,直到那时你都不需要数据。我没有说我的代码会更好;你绝对需要四个 pld 而不仅仅是两个,否则你总是会有缓存未命中。你还可以调整 vstvld 的顺序,或尝试重新定位 pld 指令。 - artless noise
显示剩余5条评论

网页内容由stack overflow 提供, 点击上面的
可以查看英文原文,
原文链接