Comment utiliser DSP pour accélérer un code sur OMAP?

Question

Je travaille sur un codec vidéo pour OMAP3430. J'ai déjà du code écrit en C ++ et j'essaie de modifier / porter certaines parties de celui-ci pour tirer parti du DSP (le SDK (SDK OMAP ZOOM3430) que j'ai possède un DSP supplémentaire).

J'ai essayé de porter une petite boucle for qui fonctionne sur une très petite quantité de données (~ 250 octets), mais environ 2 millions de fois sur des données différentes. Mais la surcharge de la communication entre le processeur et le DSP est bien plus que le gain (si j'en ai).

Je suppose que cette tâche ressemble beaucoup à l'optimisation d'un code pour le GPU sur des ordinateurs normaux. Ma question porte quel type de pièces serait bénéfique? Comment les programmeurs GPU s’occupent-ils de telles tâches?

modifier:

1. L'application GPP alloue un tampon de taille 0x1000 octets.
2. L'application GPP appelle DSPProcessor_ReserveMemory pour réserver un espace d'adressage virtuel DSP pour chaque mémoire tampon allouée à l'aide d'une taille supérieure de 4 Ko à celle de la mémoire tampon allouée pour tenir compte de l'alignement automatique de la page. La taille totale de la réservation doit également être alignée sur une limite de page de 4 Ko.
3. L’application GPP appelle DSPProcessor_Map pour mapper chaque tampon alloué aux espaces d’adresse virtuelle DSP réservés à l’étape précédente.
4. L'application GPP prépare un message pour notifier la phase d'exécution du DSP de l'adresse de base de l'espace d'adressage virtuel mappé sur une mémoire tampon allouée sur le GPP. L’application GPP utilise DSPNode_PutMessage pour envoyer le message au DSP.
5. GPP appelle memcpy pour copier les données à traiter dans la mémoire partagée.
6. L'application GPP appelle DSPProcessor_FlushMemory pour s'assurer que le cache de données a été vidé.
7. L’application GPP prépare un message pour informer la phase d’exécution du DSP que son écriture est terminée dans le tampon et que le DSP peut désormais accéder au tampon. Le message contient également la quantité de données écrites dans la mémoire tampon afin que le DSP sache exactement quelle quantité de données copier. Le GPP utilise DSPNode_PutMessage pour envoyer le message au DSP, puis appelle DSPNode_GetMessage pour attendre la réponse du DSP.

Ensuite, l’exécution du programme DSP commence et DSP informe le GPP par un message à la fin du traitement. Juste pour essayer, je ne mets aucun traitement dans le programme DSP. Je viens d'envoyer un "traitement terminé". message au GPP. Et cela prend encore beaucoup de temps. Cela pourrait-il être dû à l'utilisation de la mémoire interne / externe, ou est-ce simplement à cause de la surcharge de communication?

Answer 1

D'après les mesures que j'ai effectuées, un cycle de messagerie entre le processeur et le DSP prend environ 160 us. Je ne sais pas si cela est dû au noyau que j'utilise ou au pilote de pont; mais c’est très long pour un simple back & amp; quatrième messagerie.

Il semble raisonnable de porter un algorithme sur DSP uniquement si la charge de calcul totale est comparable au temps requis pour la messagerie; et si l'algorithme est adapté à l'informatique simultanée sur CPU et DSP.

Answer 2

L'OMAP3430 ne possède pas de DSP intégré, mais un moteur de décodage vidéo / audio IVA2 + connecté au bus système et le cœur du Cortex dispose d'instructions SIMD de type DSP. Le GPU de l’OMAP3430 est une unité basée sur PowerVR SGX. Bien qu’il ait des shaders programmables et que je ne pense pas qu’il y ait un soutien pour la programmation à usage général comme CUDA ou OpenCL. Je peux me tromper, mais je n'ai jamais entendu parler d'un tel soutien

Si vous utilisez le moteur de codage / décodage IVA2 + intégré, vous devez utiliser les bibliothèques appropriées pour cette unité et ne prendre en charge que des codecs spécifiques que je connais. Essayez-vous d’écrire votre propre bibliothèque dans ce module?

Si vous utilisez le DSPish intégré au Cortex (instructions SIMD), postez du code.

Si votre conseil de développement dispose d'un DSP supplémentaire, qu'est-ce que le DSP et comment est-il connecté au OMAP?

En ce qui concerne la question des GPU de bureau, dans le cas du décodage vidéo, vous utilisez les bibliothèques de fonctions fournies par le fournisseur pour passer des appels au matériel. Il existe plusieurs bibliothèques, VDAPU pour Nvidia sur Linux, des bibliothèques similaires sur Windows (PureViewHD, ). ATI a également des bibliothèques Linux et Windows pour leurs moteurs de décodage embarqués, je ne connais pas les noms.

Answer 3

Je ne sais pas quelle est la base de temps pour le transfert des données, mais je sais que le TMS32064x qui est répertorié dans la fiche technique du SDK possède un moteur DMA très puissant. (J'imagine que c'est le MDO ZOOM OMAP34X d'origine. Il indique qu'il a un 64xx.) J'espère que l'OMAP a quelque chose de similaire, utilisez-le à son meilleur avantage. Je recommanderais la mise en place " ping-pong " tampons dans le ram interne du 64xx et utilisation de la mémoire SDRAM en tant que mémoire partagée avec le descripteur de transfert par DMA. La mémoire vive externe constitue un goulot d'étranglement pour toutes les pièces de la série 6xxx. Conservez tout ce que vous pouvez verrouiller dans la mémoire interne pour améliorer les performances. En règle générale, ces parties pourront transférer 8 mots de 32 bits au bus une fois dans la mémoire interne, mais cela varie d’une partie à l’autre en fonction du niveau de cache qu’il vous permet de mapper en tant que mémoire RAM à accès direct. Les pièces sensibles au coût de TI déplacent la " mémoire mappable " plus loin que certains des autres puces. Tous les manuels des pièces sont également disponibles en téléchargement gratuit auprès de TI au format PDF. Ils m'ont même remis gratuitement des copies papier du manuel du processeur et d'instructions TMS320C6000 et de nombreux autres livres.

En ce qui concerne la programmation, vous devrez peut-être utiliser certains des "paramètres intrinsèques du processeur". ou assemblage en ligne pour optimiser les calculs que vous faites. Pour l'opération 64xx, privilégiez l'opération entière lorsque cela est possible, car elle ne possède pas de noyau en virgule flottante intégrée. (Celles-ci appartiennent à la série 67xx.) Si vous regardez les unités d’excution et que vous pouvez cartographier vos calculs de telle sorte que les différentes parties ciblent différentes opérations de manière pouvant se produire en un seul cycle, vous pourrez obtenir la meilleure performance possible. de ces parties. Le manuel du jeu d'instructions répertorie les types d'opérations exécutés par chaque unité d'exécution. Si vous pouvez diviser votre calcul en deux ensembles de flux de données et dérouler un peu les boucles, le compilateur sera "plus agréable". à vous lorsque l'optimisation totale est activée. Cela est dû au fait que le processeur est divisé en un côté gauche et un côté droit avec des unités d’exécution presque identiques de chaque côté.

J'espère que cela vous aidera.