Como usar DSP a velocidade-up um código no OMAP?

Question

Eu estou trabalhando em um codec de vídeo para OMAP3430. Já têm código escrito em C ++, e Tento modificar / porta certas partes do mesmo para tirar vantagem do DSP (SDK (OMAP ZOOM3430 SDK) que tem tem um DSP adicional).

I tentou uma pequena porta para o laço que está em execução sobre uma muito pequena quantidade de dados (~ 250 bytes), mas sobre os tempos de 2M em dados diferentes. Mas a sobrecarga de comunicação entre CPU e DSP é muito mais do que o ganho (se tiver algum).

Eu assumo esta tarefa é muito parecido com otimização de um código para os GPU em computadores normais. A minha pergunta é portar o tipo de peças seria benéfico? Como programadores GPU cuidar de tais tarefas?

edit:

1. aplicação de GPP atribui uma memória intermédia de tamanho 0x1000 bytes.
2. GPP invoca aplicação DSPProcessor_ReserveMemory para reservar um espaço de endereço virtual DSP para cada alocados buffer usando um tamanho que é 4K maior do que o buffer alocado para a conta para o alinhamento de página automática. O tamanho total da reserva também devem ser alinhados ao longo de um limite de página de 4K.
3. invoca aplicação GPP DSPProcessor_Map mapear cada buffer alocado para os espaços de endereços virtuais DSP reservados na etapa anterior.
4. Aplicação de GPP prepara uma mensagem para notificar o DSP executar fase do endereço base de espaço de endereço virtual, que foram mapeados para um buffer alocado no GPP. aplicação GPP usa DSPNode_PutMessage para enviar a mensagem para o DSP.
5. invoca GPP memcpy para copiar os dados a serem processados ??na memória compartilhada.
6. Aplicação de GPP invoca DSPProcessor_FlushMemory para garantir que o cache de dados foi liberado.
7. Aplicação de GPP prepara uma mensagem para notificar o DSP executar fase que tem escrito acabado para o buffer e o DSP podem agora acessar o buffer. A mensagem também contém a quantidade de dados gravados para o buffer de modo que o DSP vai saber o quanto de dados para copiar. O GPP usa DSPNode_PutMessage para enviar a mensagem para o DSP e, em seguida, invoca DSPNode_GetMessage que esperar para ouvir uma volta mensagem do DSP.

Depois de estes a execução do programa inicia DSP e DSP notifica o GPP com uma mensagem quando termina o processamento. Apenas para tentar eu não colocar qualquer processamento dentro do programa de DSP. Eu só enviar um "tratamento terminado" mensagem de volta para o GPP. E isso ainda consome muito tempo. Poderia ser por causa do uso de memória interna / externa, ou é apenas por causa da sobrecarga de comunicação?

Answer 1

A partir das medidas que eu fiz, um ciclo de mensagens entre CPU e DSP leva cerca de 160us. Eu não sei se isso é por causa do uso do kernel I, ou o driver ponte; mas este é um tempo muito longo para uma volta simples e diante de mensagens.

Parece que é apenas razoável para a porta de um algoritmo para DSP se a carga computacional total é comparável ao tempo necessário para mensagens; e se o algoritmo é adequado para a computação simultânea na CPU e DSP.

Answer 2

O OMAP3430 não tem um bordo DSP, tem um motor de decodificação IVa2 + Video / Audio ligado ao barramento do sistema e do núcleo Cortex tem DSP-like instruções SIMD. A GPU no OMAP3430 é uma unidade baseada PowerVR SGX. Enquanto isso não tem shaders programáveis ??e eu não acredito que haja qualquer suporte para programação de uso geral ala CUDA ou OpenCL. Eu posso estar errado, mas eu nunca ouvi falar de tal apoio

Se o seu usando o motor IVa2 + envio / recepção que está a bordo você precisa usar as bibliotecas adequadas para esta unidade e que só suporta codecs específicos de que eu sei. Você está tentando escrever a sua própria biblioteca para este módulo?

Se o seu usando construído em DSPish (SIMD instruções) da Cortex, postar algum código.

Se o seu conselho dev tem algum DSP extra sobre ele, o que é o DSP e como ele é ligado ao OMAP?

Quanto à questão GPU desktop, no caso de decodificação de vídeo que você usar os vender fornecido bibliotecas de funções para fazer chamadas para o hardware, existem vários, VDAPU para Nvidia em Linux, bibliotecas semelhantes no Windows (PureViewHD eu acho que é chamado ). ATI também tem ambas as bibliotecas Linux e Windows para os seus motores de bordo decodificar sobre, eu não sei os nomes.

Answer 3

Eu não sei o que a base de tempo suas transferir dados em é, mas eu sei o TMS32064x que está listada na specsheet para o SDK tem um motor de DMA muito poderoso. (Estou assumindo que é o orignal ZOOM OMAP34X MDK. Ele diz que tem um 64xx.) Eu espero que o OMAP tem algo simalar, usá-los em seu benefício máximo. Gostaria de recomendar a criação de buffers "ping-pong" na RAM interal do 64xx e usando a SDRAM como memória compartilhada com as transferências de lidar por DMA. RAM externa vai ser um gargalo em qualquer das peças da série 6xxx de modo a manter o que você pode bloqueado na memória interna para melhorar o desempenho. Normalmente essas peças terão a capacidade de ônibus 8 32bits palavras para o núcleo do processador uma vez que está na memória interna, mas que variam de parte a parte com base no que cache de nível que permite mapear como ram acesso directo. Custo partes sensíveis de TI mover a "memória mappable" mais longe do que alguns dos outros chips. Também estão disponíveis todos os manuais para as peças de TI para download gratuito em PDF. Eles até me deu cópias impressas gratuitamente do TMS320C6000 CPU e Instrução conjunto de manuais e muitos outros livros.

Quanto programação está preocupado que você pode precisar usar alguns dos "intrínsecos processador" ou linha de montagem para otimizar qualquer matemática que você está fazendo. Para a operação inteiro 64xx favor quando possível, porque ele não tem construído em um núcleo de ponto flutuante. (Essas são nas séries 67xx). Se olhar para as unidades excution e você pode mapear seus cálculos de tal forma que as diferentes partes alvo diferentes operações de uma forma que pode ocorrer em um único ciclo, então você vai ser capaz de achive o melhor desempenho dessas partes. O conjunto de instruções lista Manual os tipos de ops que são executadas por cada unidade de execução. Se você pode quebrar o cálculo em que uma dupla de fluxo de dados conjuntos e descontrair os laços um pouco o compilador será "mais agradável" para você quando optimizaiton completa está ligado. Isto é devido ao fato de que o processador é dividido em um esquerdo e um lado direito com unidades de execução quase idênticos em ambos os lados.

Espero que isso ajude.