Groupe des Ecoles des Télécommunications Institut National des Télécommunications Département ARTEMIS Advanced Research & TEchniques for Multidimensional Imaging Systems INRIA Rennes / Projet CAPS Livrable 2.2 Rapport sur le découpage en threads des modules P, T, Q et F de l encodage MPEG-4 AVC Projet PARA Auteurs : Son Minh Tran, Sébastien Matz, Marius Preda et Françoise Prêteux Participants : INT/ARTEMIS, UVSQ, IRISA CAPS, CAPS ENTREPRISE Juillet 2007
Sommaire. INTRODUCTION... 3 2. ETUDE DU PARALLELISME POUR L ENCODEUR AVC/H.264... 4 2. DECOMPOSITION DANS LE DOMAINE DES DONNEES... 4 2.2 DECOMPOSITION DANS LE DOMAINE DES TACHES... 8 2.3 PRESENTATION DU LOGICIEL ASTEX... 2 2.4 ANALYSE DE L'APPLICATION X264 PAR ASTEX... 4 3. SOMMAIRE ET PERSPECTIVES... 7 2
. Introduction Selon les prévisions sur le développement matériel et la puissance de calcul annoncée, les encodeurs implantant la nouvelle norme MPEG-4 AVC (Advanced Video Coding) seront capables d encoder la vidéo en temps réel, en qualité HD avec un débit de Mbps à l horizon 2009. L objectif de la tâche T2 du projet PARA est de prouver l hypothèse qu un développement conjoint matériel et logiciel doit permettre d anticiper cette prévision. En effet, l encodage MPEG-4 AVC, le dernier dans la famille des encodeurs MPEG-4, fournit des outils efficaces aboutissant à une meilleure compression vidéo (d au moins 50%) par rapport à celle de MPEG-2 et MPEG-4 v2, mais au prix d une plus grande complexité de calcul (0 fois plus pour les encodeurs). Ce livrable présente une analyse des processus dans l encodeur MPEG-4 AVC afin d identifier les parties du code qui sont parallélisables et les parties du code qui dont l'implémentation sur un coprocesseur est possible. Ce rapport servira de base dans la prochaine l étape: la création des bibliothèques multithreads. Les partenaires contributeurs à cette tâche du projet sont le GET/INT et l IRISA. Ils ont collaboré et ont partagé leur savoir-faire sur leur domaine de compétences afin d atteindre le but final identifié en commun. Le GET/INT et l IRISA ont respectivement apporté leur expertise sur les algorithmes de compression MPEG et parallélisme de code à l aide de l outil ASTEX développé par l IRISA. 3
2. Etude du parallélisme pour l encodeur AVC/H.264 Actuellement, AVC / H.264 est le standard du codage vidéo le plus performant par rapport au ratio débit/qualité visuelle. L utilisation d'algorithmes complexes au niveau de l encodeur implique une charge plus importante des calculs. Pour comparaison, l encodeur AVC/H.264 est dix fois plus complexe que l encodeur MPEG-2, pour un gain de 50% en taille de fichier. Pour améliorer les performances de l encodeur AVC/H.264 en terme de temps de calcul, la technique de parallélisation du code est une des solutions possibles, surtout dans le contexte actuel où l'utilisation des processeurs à double cœur et la programmation des cartes de graphiques sont de plus en plus courantes. La spécificité d un codeur vidéo permet, en général, d'exploiter différentes les techniques de parallélisme. Au niveau algorithmique il existe principalement deux manières de décomposer l encodeur AVC en modules qui peuvent être ensuite traités en parallèle par différents processeurs: la décomposition dans le domaine des données et la décomposition dans le domaine des taches. Afin de compléter cette analyse basée sur l interprétation des algorithmes de compression nous avons également utilisé un logiciel, appelé ASTEX, qui permet de détecter les tâches de calcul intensif afin de les implémenter sur des processeurs dédiés. Dans les sections suivantes nous présentons les spécificités de chaque décomposition ainsi que le logiciel ASTEX. 2. Décomposition dans le domaine des données Pour tout codage vidéo les trames encodées sont groupés dans des GOP (Group Of Picture), qui est l entité maximale de codage et temps. Chaque trame qui compose un GOP est divisée en tranches qui sont des unités indépendantes de codage. Ces dernières sont encore décomposées en macro blocs 6x6 qui représentent les unités maximales pour l estimation et la compensation du mouvement ainsi que pour le encodage entropique. Enfin, ces macros blocs sont séparés en sous-macros blocs qui peuvent avoir les tailles suivantes (6x8), (8x6), (8x8), (8x4), (4x8) ou (4x4). Cette division de l information à traiter conduit naturellement à la possibilité de considérer le parallélisme à différents niveaux : GOP, trame, tranche, macro blocs ou blocs. La décomposition dans le domaine des données est illustrée dans la 4
Figure. Bloc macro 4 blocs 8x8 2 blocs 6x8 2 blocs 8x6 I B B P B B P GOP Trame Tranche Bloc sousmacro Bloc 4x4, 8x4 et 4x8 Figure : Décomposition sur le domaine des données. En général, plus on descend dans la fragmentation, plus les processus doivent être couplés et synchronisés. Afin de réduire cette dépendance, nous avons opté pour le parallélisme au niveau des trames et des tranches. Le schéma traditionnel de codage au niveau des trames est illustré dans la Figure 2. Le processus est séquentiel, trame/trame. Après l initialisation d une trame et le choix de la prédiction (I, P ou B), le codeur est initialisé et le processus de codage de la trame courante est enclenché. La procédure finit par la mise à jour de l état de l encodeur et elle est reprise pour la trame suivante. Ce schéma peut être parallélisé comme il est montré à la Figure 3. Par rapport au nombre des processus (threads) disponibles, noté N, le segment vidéo est traité simultanément sur N trames consécutives. La seule contrainte est la synchronisation de l encodage des frames P et B. Du fait de la nature prédictive des certains blocs dans les trames P ou B, le processus associé à leur encodage doit attendre la fin de l opération de l encodage des tous les blocs dans toutes les trame de référence. La norme AVC/H264 permettant une prédiction plus libre au niveau de la longueur du buffer de prédiction et au niveau du nombre des prédicateurs, un paramètre limitant le nombre de blocs de référence doit contrôler le compromis entre le parallélisme et les performances de compression. 5
Oui Dernière trame Non Initialisation trame x264_slicetype_decide Initialisation Encodeur x264_ratecontrol_threads_start x264_slice_write Processus d'encodage des trames Mettre à jour l'état de l'encodeur x264_reference_update Figure 2: La technique séquentielle de codage des trames. 6
Dernière trame Non Oui Initialisation trame i N Initialisation trame x264_slicetype_decide x264_slicetype_decide Initialisation Encodeur... Initialisation Encodeur x264_ratecontrol_threads_start x264_slice_write x264_ratecontrol_threads_start x264_slice_write Attendre la fin des encodages des blocs de référence Signaler la fin de l'encodage des blocs Mettre à jour l'état de l'encodeur x264_reference_update Mettre à jour l'état de l'encodeur x264_reference_update Ensembler trames Figure 3: La technique parallèle de codage des trames. A l intérieur d une trame, les processus de traitement des tranches sont indépendantes, principalement due à une prédiction spatiale locale. Ainsi ces processus peuvent être traités en parallèle comme illustré dans la Figure 4. 7
Oui Denière trame Non Initialisation trame x264_slicetype_decide Initialisation Encodeur x264_ratecontrol_threads_start Copie contexte i N Copie contexte Création les tranches... Création les tranches x264_slice_write Ensembler contexte x264_slice_write Ensembler contexte N processus d'encodage en parallèle Mettre à jour l'état de l'encodeur x264_reference_update Figure 4: La technique parallèle de codage des tranches. Poursuivons notre analyse en considérant la décomposition dans le domaine des tâches. 2.2 Décomposition dans le domaine des tâches Chaque trame / bloc encodé est traité avec plusieurs modules, comme l estimation de mouvement, la compensation de mouvement, la transformation en fréquence, la quantification et l encodage entropique. Les trames utilisées comme référence pour la prédiction seront également traitées par une boucle de décodage : de-quantification, transformation de l espace des fréquences en domaine spatial et filtrage. Certains de ces modules contiennent des tâches qui peuvent être exécutées en parallèle. 8
La chaîne de traitement implémentée dans le codeur AVC ainsi que les temps d exécution des modules les plus complexes sont illustrés dans la Figure 5. x264_nal_start x264_slice_header_write Non CABAC? Oui x264_cabac_context_init x264_cabac_encoder_init Dernier MB? Non x264_macroblock_cache_load Oui x264_macroblock_analyse x264_macroblock_encode Oui CABAC? Non x264_cabac_encode_terminal x264_cabac_mb_skip x264_macroblock_write_cavlc x264_macroblock_write_cabac x264_macroblock_cache_save x264_ratecontrol_mb x264_cabac_encode_terminal Oui CABAC? Non bs_write_ue x264_cabac_encode_flush bs_rbsp_trailling x264_nal_end Figure 5: Les fonctions typiques appliquées à chaque trame. 9
00% 90% 80% 70% 60% 50% 40% x264_macroblock_cache_save x264_macroblock_cache_load Cabac(init,skip,renorm,write,terminal) x264_macroblock_encode x264_macroblock_analyse 30% 20% 0% 0% Akiyo Children Coastguard Foreman Funfair Figure 6: Temps d exécution des différents modules du schéma de codage d une trame. Comme illustré dans la Figure 6, parmi les modules les plus complexes et plus demandeurs de calcul, nous avons identifié le x264_macroblock_analyse et x264_macroblock_encode. Le premier module consiste à analyser pour chaque bloc le coût minimal par rapport à une taille et un mode de prédiction optimales, opérations qui peuvent être traitées en parallèle. Dans la Figure 7 nous illustrons chaque sous-module qui se prête au parallélisme. P type Parallèle I type B type x264_macroblock_probe_pskip Choix de la taille (6x6,8x8,6x8,8x6,8x4,4x8,4x4) optimale par l'estimation de coût Verifier le mode SKIP Choix de la taille (6,8,4) optimale par l'estimation de coût Parallèle Parallèle Choix de la taille ( 6x6,8x8,6x8,8x6 ) optimale par l'estimation de coût Parallèle Figure 7: x264_macroblock_analyse.
Nous avons poursuivi l analyse de temps d exécution à l intérieur des ces deux modules (x264_macroblock_analyse et x264_macroblock_encode) en répétant l expérimente pour plusieurs jeux de données. 00% 80% 60% 40% 20% add4x4_idct clip_uint8 x264_mb_predict_mv_ref6x6 x264_median scan_zigzag_4x4full x264_clip_uint8 mc_luma x264_pixel_sad_4x4 x264_macroblock_cache_mv x264_clip3 mc_copy x264_macroblock_cache_ref x264_mb_decimate_score quant_4x4 x264_pixel_sad_8x6 x264_pixel_sad_6x8 pixel_avg_wxh sub4x4_dct quant_4x4_core motion_compensation_chroma pixel_avg x264_pixel_sad_8x8 x264_pixel_sad_6x6 pixel_sub_wxh 0% Akiyo Children Coastguard Foreman Funfair Figure 8: Les différentes fonctions dans le module x264_macroblock_analyse. 00% 80% 60% 40% quant_8x8_core x264_clip3 pixel_avg sub4x4_dct mc_luma add4x4_idct mc_copy quant_4x4_core pixel_avg_wxh motion_compensation_chroma 20% 0% Akiyo Children Coastguard Foreman Funfair
Figure 9: Les différentes fonctions dans le module x264_macroblock_encode. Grace à cette analyse nous identifions les fonctions les plus consommatrices de temps comme étant : pixel_sub_wxh, x264_pixel_sad_6x6, x264_pixel_sad_8x8, motion_compensation_chroma, quant_4x4_core, add4x4_idct. 2.3 Présentation du logiciel ASTEX ASTEX est un logiciel développé dans l'équipe de recherche CAPS à l'irisa qui permet de découper les applications écrites en langage C en plusieurs threads implémentables sur système hétérogène (processeur principal + un co-processeur dédié). A partir d'une analyse dynamique du code de l'application, le logiciel est alors capable de détecter les tâches de calcul intensif afin de les implémenter sous forme de threads. Une version optimisée de la thread ou du codelet peut alors être écrite (ou générée) pour un type particulier de coprocesseurs (GPU, multi-core,... ) comme illustré dans la Figure 0. Figure 0: Procédure d identification et de découplage des parties de code comportant des calculs intensifs. Sachant que l'élaboration des threads est basée sur le profiling de l'application, ces threads sont dites spéculatives. C'est-à-dire qu'elles sont exécutées sur le coprocesseur dédié uniquement si certaines préconditions (déterminées par ASTEX) sont remplies. La spéculation intervient à deux niveaux : le flot de contrôle. les données (accès mémoire, transferts,...). Lors de l'exécution, si la routine quitte le chemin pré-calculé par ASTEX ou si un accès se fait en-dehors de la mémoire locale du coprocesseur, la spéculation échoue et la version originale de la routine est alors exécutée (Figure ).
Figure : Modèle des threads spéculatives dans ASTEX. ASTEX est capable de générer une version C utilisant la bibliothèque de thread POSIX. Il est alors possible de tester l'application avec divers jeux de données d'entrée et ainsi vérifier si la spéculation est pertinente. Comme l'illustre la Figure 2, le pipeline logiciel est divisé en trois parties:. Trouver les hotpaths de l application (les tâches qui font des calculs intensifs), 2. Instrumenter les accès mémoire liés aux hotpaths. Construire un modèle spéculatif de l'usage de la mémoire. 3. A partir des résultats d'exécutions, évaluer les caractéristiques des threads ou codelets potentielles. Sélectionner celles qui peuvent être déportées sur des coprocesseurs dédiés.
Figure 2: Le pipeline logiciel dans ASTEX. Pour sélectionner des threads ou des codelets pour un type particulier de coprocesseurs des critères statiques et dynamiques doivent pris en compte comme les types de données, la forme des accès mémoire, les branchements conditionnels,...) 2.4 Analyse de l'application x264 par ASTEX Cette section présente les résultats préliminaires de l'analyse de l'application x264 par ASTEX. Pour notre analyse, nous avons paramétré x264 dans sa version générique (la version de x264 utilisé n'est construite qu'à partir de fichiers sources en langage C). De plus, pour ne pas interférer avec le parallélisme déjà mise en place dans la version courante de x264, le support des threads POSIX a été désactivé. La Figure montre le contenu du fichier config.mak qui permet de compiler une version de x264 exploitables par ASTEX: ARCH=GENERIC SYS=LINUX CC=gcc CFLAGS=-Wall -I. -O2 -ffast-math -D X264 -DHAVE_MALLOC_H -DARCH_GENERIC -DSYS_LINUX LDFLAGS= -lm -s AS=nasm ASFLAGS=-O2 -f elf VFW=no VIS=no HAVE_GETOPT_LONG= DEVNULL=/dev/null CONFIGURE_ARGS= '--disable-pthread' Figure 3: Contenu du fichier config.mak
D'autres part, les différentes analyses (dynamiques) effectuées par ASTEX aux différentes étapes du pipeline ont utilisés les données d'entrées (des fichier.yuv) fournies par l'équipe ARTEMIS. Les options passées à l'encodeur lors de chaque exécution sont les suivantes: $./x264 -b-pyramid -I 50 -r 5 <fichier d'entrée> -o <fichier de sortie> 2.4. Problèmes rencontrés La plupart des problèmes rencontrés viennent du fait que x264 est la première «grande» application que l'on a faite «passée» dans ASTEX. De ce fait, nous avons pu trouver et corriger quelques bugs dans ASTEX (notamment dans notre parser C). Les traces générées par la version instrumentée de x264 étaient aussi relativement grandes. Nous avons donc reconsidéré certains de nos algorithmes d'analyse traitant des hotpaths et des accès mémoires car ces derniers prenaient trop de temps. Nous avons également travaillé sur des fichiers d'entrée plus petit (une dizaine de frames) toujours dans l'optique d'arriver à des temps d analyse raisonnable (surtout pour l'analyse des accès mémoire). 2.4.2 Résultats ASTEX a détecté différents «bouts de code» dans x264 susceptibles d'être implémentés sous forme de thread dans un système hétérogène, l'objectif étant la mise en place des systèmes comportant un processeur principal (x86 ou IA64) et un accélérateur graphique (NVDIA ou ATI). Figure 4 montre les différents morceaux de code qui sont candidats pour être déportés sur coprocesseur. dct.c sub_4x4_dct() - boucle A dct.c add_4x4_idct() - boucle A for( y = 0; y < i_size; y++ ) { for( x = 0; x < i_size; x++ ) { diff[x + y*i_size] = pix[x] - pix2[x]; } pix += i_pix; pix2 += i_pix2; } dct.c sub_4x4_dct() - boucle B for( i = 0; i < 4; i++ ) { s03 = d[i][0] + d[i][3]; s2 = d[i][] + d[i][2]; d03 = d[i][0] - d[i][3]; d2 = d[i][] - d[i][2]; tmp[0][i] = s03 + s2; tmp[][i] = (d03<<) + d2; tmp[2][i] = s03 - s2; tmp[3][i] = d03 - (d2<<); } for( i = 0; i < 4; i++ ) { const int s02 = dct[0][i] + dct[2][i]; const int d02 = dct[0][i] - dct[2][i]; const int s3 = dct[][i] + dct[3][i]>>); const int d3 = (dct[][i]>>) - dct[3][i]; tmp[i][0] = s02 + s3; tmp[i][] = d02 + d3; tmp[i][2] = d02 - d3; tmp[i][3] = s02 - s3; } dct.c add_4x4_idct() - boucle B for( i = 0; i < 4; i++ ) { const int s02 = tmp[0][i] + tmp[2][i]; const int d02 = tmp[0][i] - tmp[2][i]; const int s3 = tmp[][i] + (tmp[3][i]>>); const int d3 = (tmp[][i]>>) - tmp[3][i]; d[0][i] = ( s02 + s3 + 32 ) >> 6; d[][i] = ( d02 + d3 + 32 ) >> 6; d[2][i] = ( d02 - d3 + 32 ) >> 6; d[3][i] = ( s02 - s3 + 32 ) >> 6; }
dct.c sub_4x4_dct() - boucle C for( i = 0; i < 4; i++ ) { s03 = tmp[i][0] + tmp[i][3]; s2 = tmp[i][] + tmp[i][2]; d03 = tmp[i][0] - tmp[i][3]; d2 = tmp[i][] - tmp[i][2]; dct[i][0] = s03 + s2; dct[i][] = (d03<<) + d2; dct[i][2] = s03 - s2; dct[i][3] = d03 - (d2<<); } dct.c add_4x4_idct() - boucle C for( y = 0; y < 4; y++ ) { for( x = 0; x < 4; x++ ) { p_dst[x] = clip_uint8(p_dst[x] + d[y][x]); } p_dst += FDEC_STRIDE; } quant.c quant_4x4_core() for( i = 0; i < 6; i++ ) QUANT_ONE( dct[0][i], quant_mf[0][i] ); Figure 4: Code paralelisable. On remarque que la plupart de ces «bouts de code» ou codelet concernent la DCT et qu'il existe déjà une version optimisé de ces fonctions pour certaines plateformes (x86,...). Seuls les codelets traitant des macros blocs (4x4) ont été détectés. En inspectant le code de la version générique de x264, on s'aperçoit que les fonctions DCT traitant des macros blocs de tailles différentes sont implémentés à partir de des fonctions sub_4x4_dct() et add_4x4_idc(). Ces fonctions sont appelées la plupart du temps depuis le module x264_macroblock_analyse mise en évidence dans l'analyse algorithmique. ASTEX nous donne le pourcentage de temps pour ces différents codelets. Ces pourcentages sont des pourcentages moyens et varient bien sûr selon le fichier d'entrée. Il s'agit juste ici de présenter un ordre de grandeur et d'avoir une idée de ce que l'on peut gagner si ces codelets sont implémentés sur un coprocesseur. Codelets Pourcentage de temps sub_4x4_dct() - boucle A 7 % sub_4x4_dct() - boucle B 6 % sub_4x4_dct() - boucle C 5 % sub_4x4_dct() - Total 8 % add_4x4_idct() - boucle A % add_4x4_idct() - boucle B % add_4x4_idct() - boucle C,5 % add_4x4_idct() - Total 3,5 % quant_4x4_core() 7 % Actuellement l'analyse des accès mémoire de ces codelets est encore incomplète. Un peu développement sur ASTEX doit encore être fait pour avoir cette analyse. Il nous manque donc encore des informations sur la manière dont ces codelets utilisent la mémoire pour avoir un modèle spéculatif complet. Cette analyse sera présente dans un prochain rapport. ASTEX a correctement identifié les zones de calculs intensifs dont l'implémentation sur un coprocesseur dédié est possible. Évidemment la détection de ces zones de calculs n'est pas une surprise car elles ont déjà
été mises en évidences précédemment. Néanmoins cela valide la technologie mise en œuvre dans ASTEX. 3. Sommaire et perspectives Ce rapport présente, au sein du codeur AVC/H264, une analyse algorithmique des composantes parallélisables ainsi qu'une analyse empirique des threads spéculatifs sur coprocesseur. Nous avons identifié les modules qui se prêtent à un calcul parallèle et pour lesquelles le gain en temps de calcul, dans la version parallèle, justifie la réécriture du code. Nos investigations algorithmiques ont été confirmées en partie par l utilisation du logiciel ASTEX qui indique qu'une partie du code parallélisable peut être déporté sur un accélérateur (type GPU). Ces résultats d'analyses vont être utilisés dans la suite de nos travaux sur l'optimisation de l'application x264 dans le cadre de tâche T2.