我正在尝试使用NEON向量指令集在iOS上优化图像格式转换。我认为这将很好地映射到它，因为它处理了大量类似的数据。
尽管如此，我的尝试并没有那么好，与天真的c实现相比，只取得了微不足道的加速：
for(int i = 0; i < pixelCount; ++i, ++inPixel32) {
const unsigned int r = ((*inPixel32 >> 0 ) & 0xFF);
const unsigned int g = ((*inPixel32 >> 8 ) & 0xFF);
const unsigned int b = ((*inPixel32 >> 16) & 0xFF);
*outPixel16++ = ((r >> 3) << 11) | ((g >> 2) << 5) | ((b >> 3) << 0);
}
格式为[min avg max n =计时器样本数]，以毫秒为单位
C： [14.446 14.632 18.405 n = 1000] ms
NEON： [11.920 12.032 15.336 n = 1000] ms
我对NEON实施的尝试如下：
int i;
const int pixelsPerLoop = 8;
for(i = 0; i < pixelCount; i += pixelsPerLoop, inPixel32 += pixelsPerLoop, outPixel16 += pixelsPerLoop) {
//Read all r,g,b pixels into 3 registers
uint8x8x4_t rgba = vld4_u8(inPixel32);
//Right-shift r,g,b as appropriate
uint8x8_t r = vshr_n_u8(rgba.val[0], 3);
uint8x8_t g = vshr_n_u8(rgba.val[1], 2);
uint8x8_t b = vshr_n_u8(rgba.val[2], 3);
//Widen b
uint16x8_t r5_g6_b5 = vmovl_u8(b);
//Widen r
uint16x8_t r16 = vmovl_u8(r);
//Left shift into position within 16-bit int
r16 = vshlq_n_u16(r16, 11);
r5_g6_b5 |= r16;
//Widen g
uint16x8_t g16 = vmovl_u8(g);
//Left shift into position within 16-bit int
g16 = vshlq_n_u16(g16, 5);
r5_g6_b5 |= g16;
//Now write back to memory
vst1q_u16(outPixel16, r5_g6_b5);
}
//Do the remainder on normal flt hardware
代码是通过LLVM 3.0编译成以下内容的（删除了.loc和额外标签）：
_DNConvert_ARGB8888toRGB565:
push {r4, r5, r7, lr}
mov r9, r1
mov.w r12, #0
add r7, sp, #8
cmp r2, #0
mov.w r1, #0
it ne
movne r1, #1
cmp r0, #0
mov.w r3, #0
it ne
movne r3, #1
cmp.w r9, #0
mov.w r4, #0
it ne
movne r4, #1
tst.w r9, #3
bne LBB0_8
ands r1, r3
ands r1, r4
cmp r1, #1
bne LBB0_8
movs r1, #0
lsr.w lr, r9, #2
cmp.w r1, r9, lsr #2
bne LBB0_9
mov r3, r2
mov r5, r0
b LBB0_5
LBB0_4:
movw r1, #65528
add.w r0, lr, #7
movt r1, #32767
ands r1, r0
LBB0_5:
mov.w r12, #1
cmp r1, lr
bhs LBB0_8
rsb r0, r1, r9, lsr #2
mov.w r9, #63488
mov.w lr, #2016
mov.w r12, #1
LBB0_7:
ldr r2, [r5], #4
subs r0, #1
and.w r1, r9, r2, lsl #8
and.w r4, lr, r2, lsr #5
ubfx r2, r2, #19, #5
orr.w r2, r2, r4
orr.w r1, r1, r2
strh r1, [r3], #2
bne LBB0_7
LBB0_8:
mov r0, r12
pop {r4, r5, r7, pc}
LBB0_9:
sub.w r1, lr, #1
movs r3, #32
add.w r3, r3, r1, lsl #2
bic r3, r3, #31
adds r5, r0, r3
movs r3, #16
add.w r1, r3, r1, lsl #1
bic r1, r1, #15
adds r3, r2, r1
movs r1, #0
LBB0_10:
vld4.8 {d16, d17, d18, d19}, [r0]!
adds r1, #8
cmp r1, lr
vshr.u8 d20, d16, #3
vshr.u8 d21, d17, #2
vshr.u8 d16, d18, #3
vmovl.u8 q11, d20
vmovl.u8 q9, d21
vmovl.u8 q8, d16
vshl.i16 q10, q11, #11
vshl.i16 q9, q9, #5
vorr q8, q8, q10
vorr q8, q8, q9
vst1.16 {d16, d17}, [r2]!
Ltmp28:
blo LBB0_10
b LBB0_4
完整代码可在https://github.com/darknoon/DNImageConvert获得。我将不胜感激，谢谢！
答案 0 :(得分：10)
在这里，您手动优化了NEON实现，为XCode做好准备：
/* IT DOESN'T WORK!!! USE THE NEXT VERSION BELOW.
* BGRA2RGB565.s
*
* Created by Jake "Alquimista" Lee on 11. 11. 1..
* Copyright 2011 Jake Lee. All rights reserved.
*/
.align 2
.globl _bgra2rgb565_neon
.private_extern _bgra2rgb565_neon
// unsigned int * bgra2rgb565_neon(unsigned int * pDst, unsigned int * pSrc, unsigned int count);
//ARM
pDst .req r0
pSrc .req r1
count .req r2
//NEON
blu .req d16
grn .req d17
red .req d18
alp .req d19
rg .req red
gb .req blu
_bgra2rgb565_neon:
pld [pSrc]
tst count, #0x7
movne r0, #0
bxne lr
loop:
pld [pSrc, #32]
vld4.8 {blu, grn, red, alp}, [pSrc]!
subs count, count, #8
vshr.u8 red, red, #3
vext.8 rg, grn, red, #5
vshr.u8 grn, grn, #2
vext.8 gb, blu, grn, #3
vst2.8 {gb, rg}, [pDst]!
bgt loop
bx lr
这个版本的速度比你建议的快很多倍：
通过PLD提高缓存命中率
无需转换为“长”
循环中的指令更少
但仍有一些优化空间，您可以修改循环，使其每次迭代转换16个像素而不是8个。 然后，您可以安排指令以完全避免两个停顿（这在上面的8 /迭代版本中根本不可能），并且还可以从NEON的双重发布功能中受益。
我没有这样做，因为它会使代码难以理解。
知道VEXT应该做什么很重要。
现在由你决定。 ：）
我验证了这段代码是在Xcode下正确编译的。 虽然我很确定它也能正常工作，但我不能保证这一点，因为我没有测试环境。 如果出现故障，请告知我们。我会相应地纠正它。
孢霉素A
=============================================== ===============================
嗯，这是改进版。
由于VSRI指令的性质不允许除目标之外的两个操作数，因此无法创建关于寄存器赋值的更强大的操作数。
请检查源图像的图像格式。 （元素的确切字节顺序）
如果它不是B，G，R，A，这是iOS上的默认和原生应用程序，那么您的应用程序将受到iOS内部转换的严重影响。
如果由于某种原因绝对无法改变这一点，请告诉我。 我会写一个与之匹配的新版本。
PS：我忘了在函数原型的开头删除下划线。现在已经不见了。
/*
* BGRA2RGB565.s
*
* Created by Jake "Alquimista" Lee on 11. 11. 1..
* Copyright 2011 Jake Lee. All rights reserved.
*
* Version 1.1
* - bug fix
*
* Version 1.0
* - initial release
*/
.align 2
.globl _bgra2rgb565_neon
.private_extern _bgra2rgb565_neon
// unsigned int * bgra2rgb565_neon(unsigned int * pDst, unsigned int * pSrc, unsigned int count);
//ARM
pDst .req r0
pSrc .req r1
count .req r2
//NEON
blu .req d16
grn .req d17
red .req d18
alp .req d19
gb .req grn
rg .req red
_bgra2rgb565_neon:
pld [pSrc]
tst count, #0x7
movne r0, #0
bxne lr
.loop:
pld [pSrc, #32]
vld4.8 {blu, grn, red, alp}, [pSrc]!
subs count, count, #8
vsri.8 red, grn, #5
vshl.u8 gb, grn, #3
vsri.8 gb, blu, #3
vst2.8 {gb, rg}, [pDst]!
bgt .loop
bx lr
答案 1 :(得分：1)
如果您使用的是iOS或OS X，那么您可能会很高兴在Accelerate.framework中发现vImageConvert_RGBA8888toRGB565（）和朋友。此函数将8位值四舍五入到最接近的565值。
对于更好的抖动，其质量几乎与8位颜色无法区分，请尝试vImageConvert_AnyToAny（）：
vImage_CGImageFormat RGBA8888Format =
{
.bitsPerComponent = 8,
.bitsPerPixel = 32,
.bitmapInfo = kCGBitmapByteOrderDefault | kCGImageAlphaNoneSkipLast,
.colorSpace = NULL, // sRGB or substitute your own in
};
vImage_CGImageFormat RGB565Format =
{
.bitsPerComponent = 5,
.bitsPerPixel = 16,
.bitmapInfo = kCGBitmapByteOrder16Little | kCGImageAlphaNone,
.colorSpace = RGBA8888Format.colorSpace,
};
err = vImageConverterRef converter = vImageConverter_CreateWithCGImageFormat(
&RGBA8888Format, &RGB565Format, NULL, kvImageNoFlags, &err );
err = vImageConvert_AnyToAny( converter, &src, &dest, NULL, kvImageNoFlags );
这些方法中的任何一种都将被矢量化和多线程以获得最佳性能。
答案 2 :(得分：0)
您可能希望使用vld4q_u8（）而不是vld4_u8（）并相应地调整其余代码。很难说问题可能在哪里，但汇编程序看起来并不太糟糕。
答案 3 :(得分：0)
（我不熟悉NEON，也不熟悉Ipad2的内存系统，但这是我们过去常用的88110像素操作，这是今天SIMD扩展的早期前提）
内存延迟有多大？
当ARM从内存中提取“下一个”值时，是否可以通过展开内部循环并在“之前”值上运行NEON指令来隐藏它？对NEON手册的简要扫描意味着您可以并行运行ARM和NEON指令。
答案 4 :(得分：0)
我认为将vld4_u8转换为vld4q_u8不会导致性能提升。
代码看起来很简单。我不擅长ASM，因此需要一些时间深入研究它。
霓虹灯似乎很简单。但我并不确定使用 r5_g6_b5 | = g16 代替 vorrq_u16
请看一下优化级别。据我所知，霓虹灯代码优化级别最高为1.因此，当参考代码和霓虹灯代码考虑默认优化时，性能可能会有所不同，因为DEFAULT的参考优化级别可能是不同。
我在霓虹灯中找不到任何可以改善当前代码的区域。