【发布时间】：2012-07-15 12:41:25
【问题描述】：
我正在开发一个进行实时图像处理的 iPhone 应用程序。其管道中最早的步骤之一是将 BGRA 图像转换为灰度。我尝试了几种不同的方法，计时结果的差异远比我想象的要大。首先我尝试使用 C。我通过添加 B+2*G+R /4 来近似转换为亮度
void BGRA_To_Byte(Image<BGRA> &imBGRA, Image<byte> &imByte)
{
uchar *pIn = (uchar*) imBGRA.data;
uchar *pLimit = pIn + imBGRA.MemSize();
uchar *pOut = imByte.data;
for(; pIn < pLimit; pIn+=16) // Does four pixels at a time
{
unsigned int sumA = pIn[0] + 2 * pIn[1] + pIn[2];
pOut[0] = sumA / 4;
unsigned int sumB = pIn[4] + 2 * pIn[5] + pIn[6];
pOut[1] = sumB / 4;
unsigned int sumC = pIn[8] + 2 * pIn[9] + pIn[10];
pOut[2] = sumC / 4;
unsigned int sumD = pIn[12] + 2 * pIn[13] + pIn[14];
pOut[3] = sumD / 4;
pOut +=4;
}
}
此代码需要 55 毫秒来转换 352x288 图像。然后我发现了一些本质上做同样事情的汇编代码
void BGRA_To_Byte(Image<BGRA> &imBGRA, Image<byte> &imByte)
{
uchar *pIn = (uchar*) imBGRA.data;
uchar *pLimit = pIn + imBGRA.MemSize();
unsigned int *pOut = (unsigned int*) imByte.data;
for(; pIn < pLimit; pIn+=16) // Does four pixels at a time
{
register unsigned int nBGRA1 asm("r4");
register unsigned int nBGRA2 asm("r5");
unsigned int nZero=0;
unsigned int nSum1;
unsigned int nSum2;
unsigned int nPacked1;
asm volatile(
"ldrd %[nBGRA1], %[nBGRA2], [ %[pIn], #0] \n" // Load in two BGRA words
"usad8 %[nSum1], %[nBGRA1], %[nZero] \n" // Add R+G+B+A
"usad8 %[nSum2], %[nBGRA2], %[nZero] \n" // Add R+G+B+A
"uxtab %[nSum1], %[nSum1], %[nBGRA1], ROR #8 \n" // Add G again
"uxtab %[nSum2], %[nSum2], %[nBGRA2], ROR #8 \n" // Add G again
"mov %[nPacked1], %[nSum1], LSR #2 \n" // Init packed word
"mov %[nSum2], %[nSum2], LSR #2 \n" // Div by four
"add %[nPacked1], %[nPacked1], %[nSum2], LSL #8 \n" // Add to packed word
"ldrd %[nBGRA1], %[nBGRA2], [ %[pIn], #8] \n" // Load in two more BGRA words
"usad8 %[nSum1], %[nBGRA1], %[nZero] \n" // Add R+G+B+A
"usad8 %[nSum2], %[nBGRA2], %[nZero] \n" // Add R+G+B+A
"uxtab %[nSum1], %[nSum1], %[nBGRA1], ROR #8 \n" // Add G again
"uxtab %[nSum2], %[nSum2], %[nBGRA2], ROR #8 \n" // Add G again
"mov %[nSum1], %[nSum1], LSR #2 \n" // Div by four
"add %[nPacked1], %[nPacked1], %[nSum1], LSL #16 \n" // Add to packed word
"mov %[nSum2], %[nSum2], LSR #2 \n" // Div by four
"add %[nPacked1], %[nPacked1], %[nSum2], LSL #24 \n" // Add to packed word
///////////
////////////
: [pIn]"+r" (pIn),
[nBGRA1]"+r"(nBGRA1),
[nBGRA2]"+r"(nBGRA2),
[nZero]"+r"(nZero),
[nSum1]"+r"(nSum1),
[nSum2]"+r"(nSum2),
[nPacked1]"+r"(nPacked1)
:
: "cc" );
*pOut = nPacked1;
pOut++;
}
}
此功能在 12 毫秒内转换相同的图像，几乎快 5 倍！我以前没有用汇编程序编程过，但我认为对于这样一个简单的操作，它不会比 C 快得多。受到这次成功的启发，我继续搜索并发现了一个 NEON 转换示例here。
void greyScaleNEON(uchar* output_data, uchar* input_data, int tot_pixels)
{
__asm__ volatile("lsr %2, %2, #3 \n"
"# build the three constants: \n"
"mov r4, #28 \n" // Blue channel multiplier
"mov r5, #151 \n" // Green channel multiplier
"mov r6, #77 \n" // Red channel multiplier
"vdup.8 d4, r4 \n"
"vdup.8 d5, r5 \n"
"vdup.8 d6, r6 \n"
"0: \n"
"# load 8 pixels: \n"
"vld4.8 {d0-d3}, [%1]! \n"
"# do the weight average: \n"
"vmull.u8 q7, d0, d4 \n"
"vmlal.u8 q7, d1, d5 \n"
"vmlal.u8 q7, d2, d6 \n"
"# shift and store: \n"
"vshrn.u16 d7, q7, #8 \n" // Divide q3 by 256 and store in the d7
"vst1.8 {d7}, [%0]! \n"
"subs %2, %2, #1 \n" // Decrement iteration count
"bne 0b \n" // Repeat unil iteration count is not zero
:
: "r"(output_data),
"r"(input_data),
"r"(tot_pixels)
: "r4", "r5", "r6"
);
}
计时结果令人难以置信。它在 1 毫秒内转换相同的图像。比汇编程序快 12 倍，比 C 快 55 倍。我不知道这样的性能提升是可能的。鉴于此，我有几个问题。首先，我在 C 代码中做错了什么吗？我仍然很难相信它是如此缓慢。其次，如果这些结果完全准确，我可以期望在哪些情况下看到这些收益？你可以想象我对让管道的其他部分运行速度提高 55 倍的前景感到多么兴奋。我应该学习汇编程序/NEON 并在任何需要大量时间的循环中使用它们吗？
更新 1：我已将 C 函数的汇编程序输出发布在文本文件中 http://temp-share.com/show/f3Yg87jQn 太大了，无法直接包含在此处。
使用 OpenCV 函数完成计时。
double duration = static_cast<double>(cv::getTickCount());
//function call
duration = static_cast<double>(cv::getTickCount())-duration;
duration /= cv::getTickFrequency();
//duration should now be elapsed time in ms
结果
我测试了几个建议的改进。首先，按照 Viktor 的建议，我对内部循环进行了重新排序，以将所有获取放在首位。然后内部循环看起来像。
for(; pIn < pLimit; pIn+=16) // Does four pixels at a time
{
//Jul 16, 2012 MR: Read and writes collected
sumA = pIn[0] + 2 * pIn[1] + pIn[2];
sumB = pIn[4] + 2 * pIn[5] + pIn[6];
sumC = pIn[8] + 2 * pIn[9] + pIn[10];
sumD = pIn[12] + 2 * pIn[13] + pIn[14];
pOut +=4;
pOut[0] = sumA / 4;
pOut[1] = sumB / 4;
pOut[2] = sumC / 4;
pOut[3] = sumD / 4;
}
此更改将处理时间缩短至 53 毫秒，提高了 2 毫秒。接下来，按照 Victor 的建议，我将函数更改为 fetch as uint。然后内部循环看起来像
unsigned int* in_int = (unsigned int*) original.data;
unsigned int* end = (unsigned int*) in_int + out_length;
uchar* out = temp.data;
for(; in_int < end; in_int+=4) // Does four pixels at a time
{
unsigned int pixelA = in_int[0];
unsigned int pixelB = in_int[1];
unsigned int pixelC = in_int[2];
unsigned int pixelD = in_int[3];
uchar* byteA = (uchar*)&pixelA;
uchar* byteB = (uchar*)&pixelB;
uchar* byteC = (uchar*)&pixelC;
uchar* byteD = (uchar*)&pixelD;
unsigned int sumA = byteA[0] + 2 * byteA[1] + byteA[2];
unsigned int sumB = byteB[0] + 2 * byteB[1] + byteB[2];
unsigned int sumC = byteC[0] + 2 * byteC[1] + byteC[2];
unsigned int sumD = byteD[0] + 2 * byteD[1] + byteD[2];
out[0] = sumA / 4;
out[1] = sumB / 4;
out[2] = sumC / 4;
out[3] = sumD / 4;
out +=4;
}
这种修改产生了显着的效果，将处理时间减少到 14 毫秒，减少了 39 毫秒 (75%)。最后一个结果非常接近 11ms 的汇编器性能。 rob 建议的最终优化是包含 __restrict 关键字。我在每个指针声明前面添加了它，更改了以下几行
__restrict unsigned int* in_int = (unsigned int*) original.data;
unsigned int* end = (unsigned int*) in_int + out_length;
__restrict uchar* out = temp.data;
...
__restrict uchar* byteA = (uchar*)&pixelA;
__restrict uchar* byteB = (uchar*)&pixelB;
__restrict uchar* byteC = (uchar*)&pixelC;
__restrict uchar* byteD = (uchar*)&pixelD;
...
这些更改对处理时间没有明显影响。感谢大家的帮助，以后我会更加关注内存管理。
【问题讨论】：
-
你能发布编译器制作的程序集吗？
-
Err.. 如果我错了，请纠正我，但 NEON 在单独的 DSP 阵列硬件上运行？如果是这样，也许这可以解释为什么它会快一点？
-
相同的硬件，相同的芯片。它是一个指令集扩展，就像 SSE 或 MMX。
-
@harold 我去获取编译器生成的汇编器，但它大得离谱。我在 xcode 4.3.2 中，并在助手编辑器中查看程序集。我在 C 中的函数长 23 行，没有包含，但生成的汇编程序长 9029 行。知道为什么会这样吗？我让编译器最大限度地优化 C 代码。
-
如果您真的想要快速处理视频，我可以建议您使用 OpenGL ES 2.0 片段着色器吗？与 NEON 优化例程相比，GPU 在处理简单的并行操作方面甚至更快。我围绕这个编写了一个开源框架：github.com/BradLarson/GPUImage，我已经看到 iOS GPU 上的图像处理与 CPU 绑定的 C 函数相比，速度提高了 100 倍以上。我已经复制了一些 OpenCV 的功能，我的目标是尽可能多地提供这些功能。
标签： iphone c image-processing assembly neon