Estou tentando entender o comentário feito por "Não existirei idonotexista" emOtimização SIMD do cvtColor usando intrínsecas ARM NEON:

... por que você não usa as intrísticas ARM NEON que mapeiam para a instrução VLD3? Isso poupa todo o embaralhamento, simplificando e acelerando o código. A implementação do Intel SSE requer shuffles porque não possui instruções de carga de desintercalação de 2/3/4 vias, mas você não deve transmiti-las quando estiverem disponíveis.

O problema que estou tendo é que a solução oferece código que não é intercalado e executa multiplicações fundidas em pontos flutuantes. Estou tentando separar os dois e entender apenas as cargas intercaladas.

De acordo com o comentário da outra pergunta eCodificação para NEON - Parte 1: Carga e Armazenamento, a resposta provavelmente vai usarVLD3.

Infelizmente, não estou vendo (provavelmente porque estou menos familiarizado com o NEON e suas funções intrínsecas). Parece queVLD3 basicamente produz 3 saídas para cada entrada, então meu modelo de metal está confuso.

Dadas as seguintes instruções SSE que operam com dados emBGR BGR BGR BGR... formato que precisa de uma reprodução aleatória paraBBBB GGGG RRRR ...:

const byte* data = ...  // assume 16-byte aligned
const __m128i mask = _mm_setr_epi8(0,3,6,9,12,15,1,4,7,10,13,2,5,8,11,14);
__m128i a = _mm_shuffle_epi8(_mm_load_si128((__m128i*)(data)),mask);

Como realizamos as cargas intercaladas usando os intrínsecos NEON, para que não necessitemos de embaralhamento SSE?

Observe também ... Estou interessado em intrínsecas e não em ASM. Posso usar as intrínsecas da ARM nos dispositivos Windows Phone, Windows Store e Linux sob MSVC, ICC, Clang, etc. Não posso fazer isso com o ASM e não estou tentando especializar o código três vezes (Microsoft 32- bit ASM, Microsoft 64 bits e GCC ASM).