爲ARM優化掃描線轉換功能

下面的代碼將一行從8位蒼白格式轉換爲32-RGBA。爲ARM優化掃描線轉換功能

在我嘗試實現它之前，我想知道下面的代碼是否適合用Direct-Math或ARM Neon intrinsics或內聯彙編進行優化。我第一次看文檔並沒有發現任何可以涵蓋查表部分的內容。

void CopyPixels(BYTE *pDst, BYTE *pSrc, int width, 
    const BYTE mask, Color* pColorTable) 
{ 
    if (width) 
    { 
    do 
    { 
     BYTE b = *pSrc++; 
     if (b != mask) 
     { 
     // Translate to 32-bit RGB value if not masked 
     const Color* pColor = pColorTable + b; 
     pDst[0] = pColor->Blue; 
     pDst[1] = pColor->Green; 
     pDst[2] = pColor->Red; 
     pDst[3] = 0xFF; 
     } 
     // Skip to next pixel 
     pDst += 4; 
    } 
    while (--width); 
    } 
}

來源

2013-07-27 Oliver Weichhold

對錶的訪問只是* memory *操作。這取決於表格的格式。使用* NEON *，您只需使用'vld'。如果您需要重新訂購，有很多選擇。例如，[重新安排向量的博客]（http://blogs.arm.com/software-enablement/684-coding-for-neon-part-5-rearranging-vectors/）。 –

你知道彩色地圖裏有什麼嗎？機會是你可以想出一個近似值，它可以避免查找操作，並且運行時間更短，但只適用於已知的地圖。 – sh1

您將需要一個大小爲256 * 4bytes = 1024bytes的LUT。這類工作根本不適合SIMD。（英特爾新Haswell核心上的SSE部分除外）

NEON可以使用VTBL和VTBX處理最大32字節的LUT，但它或多或少意味着與CLZ一起作爲Newton-Raphson迭代的起始值。

來源

2013-07-28 23:54:27

我同意Jake認爲這不是一個很棒的向量處理器問題，並且可能由ARM主管道更有效地處理。這並不意味着您無法通過彙編（但只是簡單的ARM v7）對其進行優化，從而大大改善結果。

特別是，一個簡單的改進是構建您的查找表，以便它可以與一個字大小的副本一起使用。這將涉及確保Color結構遵循32-RGBA格式，包括將第4個0xFF作爲查找的一部分，以便您可以只執行一次單詞複製。這可能是一個重要的性能提升，無需彙編，因爲它是單個內存提取，而不是3（加上一個常量賦值）。

void CopyPixels(RGBA32Color *pDst, BYTE const *pSrc, int width, 
    const BYTE mask, RGBA32Color const *pColorTable) 
{ 
    if (width) 
    { 
    do 
    { 
     BYTE b = *pSrc++; 
     if (b != mask) 
     { 
     // Translate to 32-bit RGB value if not masked 
     *pDst = pColorTable[b]; 
     } 
     // Skip to next pixel 
     pDst ++; 
    } 
    while (--width); 
    } 
}

來源

2013-07-29 16:05:06

爲ARM優化掃描線轉換功能

回答

相關問題