我正在转换的游戏在 8 位调色板纹理上运行，几乎每一帧我都必须将该纹理的一部分更新为 OpenGL 纹理以进行渲染。它看起来像这样:
unsigned short RGB565PaletteLookupTable[256]; // Lookup table
unsigned char* Src; // Source data
unsigned short* Dst; // Destination buffer
int SrcPitch; // Source data row length
int OriginX, OriginY, Width, Height; // Subrectangle to copy
assert( Width % 4 == 0 );
int SrcOffset = SrcPitch-Width;
Src += OriginY*SrcPitch+OriginX;
int x, y;
for( y = OriginY; y < OriginY+Height; ++y, Src += SrcOffset )
{
for( x = OriginX; x < OriginX+Width; x += 4 )
{
*Dst++ = RGB565PaletteLookupTable[*Src++];
*Dst++ = RGB565PaletteLookupTable[*Src++];
*Dst++ = RGB565PaletteLookupTable[*Src++];
*Dst++ = RGB565PaletteLookupTable[*Src++];
}
}
这段代码在游戏过程中占用了 17% 的主线程时间，所以我正在寻找加快速度的方法。数据直接转到 glTexSubImage2D()，所以我无法更改目标缓冲区中的任何内容。它来自游戏中的代码，该代码是古老的且没有记录的，并且没有人知道它是如何工作的，所以我也不能乱搞。查找表也是由这个古老的代码提供的，并且可以在游戏中更改。
是否可以使用 Accelerate 框架/汇编指令/任何其他方式加速此代码？我阅读了将 RGB888 直接转换为 RGB565 的示例，但这些不需要使用查找表。我应该在哪里学习如何以最佳方式加速它？
更新:我发现 OriginX 也是 4 对齐的，并且能够以这种方式优化代码:
unsigned long RGB565PaletteLookupTable[256]; // Lookup table
unsigned char* Src; // Source data
unsigned long* Dst; // Destination buffer
int SrcPitch; // Source data row length
int OriginX, OriginY, Width, Height; // Subrectangle to copy
assert( Width % 4 == 0 );
int SrcOffset = SrcPitch-Width;
Src += OriginY*SrcPitch+OriginX;
SrcOffset >>= 2;
int x, y;
unsigned long* LSrc = (unsigned long*)Src;
for( y = OriginY; y < OriginY+Height; ++y, LSrc += SrcOffset )
{
for( x = OriginX; x < OriginX+Width; x += 4 )
{
unsigned long Indexes = *LSrc++;
unsigned long Result = RGB565PaletteLookupTable[ Indexes & 0xFF ];
Indexes >>= 8;
Result |= ( RGB565PaletteLookupTable[ Indexes & 0xFF ] << 16 );
*Dst++ = Result;
Indexes >>= 8;
Result = RGB565PaletteLookupTable[ Indexes & 0xFF ];
Indexes >>= 8;
Result |= ( RGB565PaletteLookupTable[ Indexes & 0xFF ] << 16 );
*Dst++ = Result;
}
}
据我所知，这段代码没有使用任何未对齐的内存访问。它稍微提高了性能，也就是说，它现在占用了主线程时间的 15.5%。不过，我希望能加快速度。
理论上，每个查找表操作都独立于之前和后续的操作(除了它们每个都从同一个查找表读取的事实)，所以我期待会有一些 SIMD 指令，或者也许汇编指令将允许并行查找许多像素。类似的东西
_mm_movemask_ps( _mm_cmpneq_ps( _mm_loadu_ps( cmp1 ), _mm_loadu_ps( cmp2 ) ) ) )
在 Mac 上与 memcmp( cmp1, cmp2, 16 ) 做同样的事情，只是快 8 倍。
我现在继续寻找。
更新:我确定似乎没有办法使用 NEON 指令集加快查表速度。该表需要 512 字节大，没有办法将其完全放入 ARM 寄存器中，VTBX NEON 指令一次最多可以处理 32 个字节，并且它还假设查找结果的大小必须等于索引。有一些东西可以作为 http://forums.arm.com/index.php?/topic/15521-8bit-look-up-table-by-neon-code/ 中描述的类似问题的解决方案来解决。 ，但它不适合我的。所以确保所有操作数的对齐是正确的似乎是解决这个问题的最佳答案。
问题出在缓存上。您从 Src 进行大量读取，如果它未对齐四次(可能是这种情况，因为 OriginX 很可能是任意的)，则 (*Src++) 会在未对齐读取上浪费循环。
尝试强制执行 (OriginX % 4 == 0) 并将剩余的 (OriginX % 4) 像素复制到主循环之外。
与 "*Dst++ = "相同 - 是 Dst 未对齐，这是不好的。尝试将 RGB565 对(两个顺序 *Dst 写入)组合成一个 32 位副本。您甚至可以尝试覆盖更多像素以使循环更简单，然后处理边框像素。
希望你能明白。
第二种方式:将转换卸载到GPU。
为 RGB565PaletteLookupTable 创建一维纹理并编写一个简单的片段着色器，该着色器采用 (Src + RGB565PaletteLookupTable) 并输出 Dst(然后 glTexImage2D 将更新 Src 纹理，而不是像现在这样更新 Dst)
关于ios - iOS 4+上调色板纹理转换为RGB565的优化(使用查找表)，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/11215667/
| 欢迎光临 OGeek|极客世界-中国程序员成长平台 (https://ogeek.cn/) | Powered by Discuz! X3.4 |