TP4 : Déploiement de l'application MJPEG sur une architecture multiprocesseur

TP Précédent : TP3_2012_Monopro

0. Objectif

Comme pour les précédents TP, vous aurez à fournir un certain nombre de sources et un rapport. Il vous est conseillé de parcourir la documentation dans le trac, en partant de ​dsx:wiki:WikiStart.

La première partie de ce TP vise la description en DSX d'une architecture matérielle multiprocesseurs générique donnée (décrite avec soclib). On appelera la description DSX de l'application VgmnMultipro : cette description devra refléter l'architecture décrite en soclib. Cette dernière est générique dans le sens où on peut faire varier par un simple paramètre le nombre de processeurs et le nombre de bancs mémoire, ainsi que les caractéristiques des caches rattachés aux processeurs.

La seconde partie de ce TP vise à déployer l'application MJPEG sur cette plateforme générique en faisant varier les paramètres dont on dispose. Cette exploration architecturale est le but réel de l'outil DSX.

1. Description de l'architecture générique VgmnMultipro

La description DSX de l'architecture VgmnMonopro utilisée dans le TP3 était non-paramètrable, hormis pour le nombre de contrôleurs de terminaux (MultiTty).

On se propose de décrire maintenant avec DSX une architecture reflétant une architecture soclib multiprocesseur générique (illustrée ci-contre), dont les paramètres sont :

• Le nombre de Tty : tty_count
• Le nombre de processeurs : proc_count
• Le nombre de bancs mémoire : ram_count

De plus, on souhaite faire varier lors de l'exécution des paramètres qui n'ont pas à être spécifiés dans DSX :

• Le nombre de lignes des caches : icache_lines et dcache_lines

Note : On pourrait aussi faire varier le nombre de mots par ligne de cache icache_words et dcache_words, mais on ne le fait pas par manque de temps.

Note : pour ce TP, on fixe le nombre de bancs mémoire à 2 pour les différentes simulations. Si vous souhaitez faire varier le nombre de bancs mémoire dans la description DSX, il faut aussi penser à faire varier ce nombre dans le fichier top.cpp de la topcell. En revanche, le nombre de processeurs est défini automatique dans la topcell par l'intermédiaire du GIET.

Vous pourrez vous inspirer de la description de l'architecture VgmnMonopro définie dans le TP3, en n'hésitant pas à utiliser les constructions du langage Python permettant d'exprimer la généricité (tableaux, boucles, etc.) Cette description architecturale DSX VgmnMultipro sera décrite dans un fichier nommé 'vgmn_multipro.py'.

Vous pouvez ajouter des paramètres à la fonction définissant l'architecture, auxquels des valeurs par défaut peuvent être spécifiées. Par exemple :

def VgmnMultipro(proc_count = 1, ram_count = 2, tty_count = 5)

Vous validerez cette description générique VgmnMultipro, en déployant l'application MJPEG sur une instance particulière de cette architecture, équivalente à celle utilisée dans le TP3 : c'est-à-dire un seul processeur et deux bancs mémoire.

Vous instancierez l'architecture avec la ligne (les paramètres non spécifiés prennent leurs valeurs par défaut) :

archi = VgmnMultipro(tty_count = 6)

Vous effectuerez le mapping mémoire de la manière suivante :

• Canaux Mwmr => RAM_0
• Piles d'exécution => RAM_1
• Code => RAM_1
• Données => RAM_0
• Tables des pages => RAM_0
• Noyau (code et données) => RAM_1

• Question 1 : Combien faut-il de cycles pour décompresser 25 images?

2. Exploration Architecturale

Dans cette seconde partie, on va déployer l'application MJPEG sur l'architecture MPSoC VgmnMultipro. Vous ferez principalement varier le nombre de processeurs et la répartition des tâches logicielles sur les processeurs. Les deux tâches d'entrée/sortie tg et ramdac restent pour le moment implantées sur des coprocesseurs matériels spécialisés : il y a donc 5 tâches "logicielles" à déployer sur un nombre de processeurs qui reste à déterminer.

2.1 Profilage de l'application

Pour guider la répartition des tâches sur les processeurs, on commence par effectuer un profilage de l'application sur station de travail POSIX, en mesurant les temps passés dans les différentes tâches.

Ce profilage nous donne, comme charge relative entre les tâches, les valeurs suivantes :

idct	35%
vld	25%
demux	20%
iqzz	16%
libu	4%

• Question 2 : Qu'en déduisez-vous sur les façons optimales de déployer MJPEG sur 2, 3, 4 et 5 processeurs ?

2.2 Déploiement sur une architecture à 5 processeurs

Déployez l'architecture MJPEG sur une architecture VgmnMultipro comportant cinq processeurs (c'est-à-dire une tâche par processeur), le même mapping mémoire et lancez la simulation.

• Question 3 : Combien faut-il de cycles pour décompresser 25 images?

Note : n'oubliez pas de recompiler l'architecture

On cherche maintenant à estimer le taux d'utilisation de chacun des 5 processeurs.

• Question 4 : Quel est selon vous le processeur le plus chargé ? Expliquez quelle méthode pouvez-vous mettre en oeuvre pour vérifier cette supposition ?

• Question 5 : Mettez en oeuvre votre méthode sur l'idct et indiquez le taux de charge obtenu. Pourquoi est-il inférieur à 100% ?

2.3 Déploiement sur des architectures à 4, 3 et 2 processeurs

Pour la suite du TP, désactivez les traces de l'application MJPEG en remplaçant l'appel 'Giet(outdir = 'platform')' par l'appel 'Giet(outdir = 'platform', verbosity = 'NONE')' dans le fichier 'mjpeg.py'.

Déployez l'application MJPEG sur des architectures matérielles comportant 4, puis 3, puis 2 processeurs, en utilisant les informations données sur les charges de chacune des tâches. Pour cela, placez intelligemment les tâches de façon à obtenir les temps de décompression les plus courts possibles.

• Question 6 : Quel est le nombre de cycles minimal pour décompresser 25 images avec 4 processeurs ?

• Question 7 : Quel est le nombre de cycles minimal pour décompresser 25 images avec 3 processeurs ?

• Question 8 : Quel est le nombre de cycles minimal pour décompresser 25 images avec 2 processeurs ?

2.4 Influence de la taille des caches

On souhaite maintenant évaluer l'influence de la taille des caches processeurs sur le temps de décompression.

Pour faire varier le nombre de sets des caches de l'architecture, vous pouvez utiliser les options '-NICACHE <value>' et '-NDCACHE <value>' sur la ligne de commande d'exécution de la simulation.

On se place dans l'hypothèse d'une architecture à 2 processseurs, en conservant le placement des tâches optimal défini à la question précédente. On utilisera des caches de 4 ways avec des lignes de 4 mots, et on se contentera de faire varier le nombre de sets.

• Mesurez le temps de calcul pour décompresser 2 images, en utilisant deux "gros" caches de 512 sets, pour les instructions comme pour les données.
• Refaites cette mesure en diminuant progressivement le nombre de sets du cache de données (512, puis 256, 64, 16, 4 et enfin, 1), en conservant une capacité de 512 sets pour le cache d'instructions.
• Idem en diminuant progressivement le nombre de sets du cache d'instructions (512, puis 256, 64, 16, 4, et enfin 1), en conservant une capacité de 512 sets pour le cache de données.

• Question 8 : Regroupez ces résultats dans deux tableaux de synthèse.

• Question 9 : Que choisiriez-vous comme capacité pour les caches, sachant que la surface de la mémoire embarquée est un facteur important du coût de fabrication ?

3. Compte-Rendu

Comme pour les TP précédents, vous rendrez une archive contenant les fichiers suivants :

$ tar tzf binome0_binome1.tar.gz
tp4/
tp4/rapport.pdf
tp4/mjpeg/
tp4/mjpeg/mjpeg
tp4/mjpeg/vgmn_multipro.py
tp4/mjpeg/src/
tp4/mjpeg/src/iqzz/iqzz.c
tp4/mjpeg/src/libu/libu.c

Le fichier mjpeg sera celui de la partie 2.4, avec la gestion de la ligne de commande. Les deux sources C sont ceux des deux derniers TP, éventuellement modifiés.

Cette archive devra être livrée avant le (jour) (date), 18h00 à [MailAsim:quentin.meunier Quentin Meunier]

Suite

TP Suivant : TP4_Multipipe