Codage Graphique Reconfigurable pour maillage 3D

Codage Graphique Reconfigurable pour maillage 3D
Christian Tulvan et Marius Preda
Institut Telecom,
ARTEMIS, Telecom Sudparis (UMR 8145),
9, rue Charles Fourier, 91000 Evry, France
[email protected]
[email protected]
Résumé L’objectif de cet article est d'introduire le concept de codeur graphique reconfigurable et
de présenter une librairie des unités fonctionnelles permettant le décodage des objets graphiques
3D. L'hétérogénéité de la représentation (non-compressée) des objets graphiques 3D rendent
nécessaire la coexistence d'une multitude des schémas de compression, une spécifique pour
chaque représentation. Même si intrinsèquement ces schémas partagent les mêmes composantes
classiques de traitement de signal, il est impossible aujourd'hui de les rendre interopérables. Nous
proposons de résoudre ce problème par l'identification des unités fonctionnelles qui seront
connectées qu'au moment de décodage sur la base d'une information qui va accompagner le
bitstream à décoder. Ce principe permet par ailleurs l'implantation spécifique des unités
fonctionnelles et la gestion optimisée du calcul par rapport à l'architecture matérielle (CPU, GPU,
FPGA, …)
Mots clés Compression, reconfigurabilité, architecture parallèle.
1
Introduction
Étant donné la multiplication des objets graphiques 3D, notamment dans des applications
multimédias interactives et en ligne (par exemple les jeux) la nécessité de traitement et de
compression des maillages 3D pour le stockage et la transmission efficace devient de plus en plus
importante. Les techniques de compression de maillage 3D ont fait l’objet de divers travaux de
recherches centrés principalement sur l’efficacité de la compression. Parmi les technologies de l'état
de l'art nous retrouvons le standard MPEG-4 qui inclue des techniques de codage de maillage 3D
(3DMC) [1-2]. Même si ce standard répond aux critères de compression requises par la majorité des
applications, il est très peu implémenté dans l’industrie. Les principaux obstacles à cette
implémentation sont le niveau élevé de complexité des processus de codage et décodage notamment
pour de dispositifs mobiles ou nécessitant du rendu en temps réel, la complexité de développement et
le faible degré de réutilisation.
Par ailleurs, même si la fréquence des processeurs ne double plus chaque deux ans, comme prédit
par Moore en 1965, les architectures multi-cœurs et mixées (CPU et GPU, CPU et FPGA) font que les
performances computationnelles augmentent. La difficulté de cette nouvelle approche consiste dans le
fait que les langages de programmation standards sont en principe séquentiels et doivent être modifiés
ou utilisés d'une manière spécifiques pour profiter des architectures parallèles.
D'un point de vue recherche, la réalisation d'outils permettant de produire un prototype rapide en
combinant des parties algorithmiques traitées comme des fonctions mathématiques et qui prennent en
compte la plateforme matérielle sur laquelle l'opération et réalisée, incluent la gestion du parallélisme,
est prioritaire. Dans ce cadre, le concept de programmation par flux des données consiste à décrire une
application comme un ensemble des modules implémentent les fonctionnalités et dans un graph
directionnel représentent le flux des données entre les modules. Ce model met en évidence le
parallélisme potentiel de l'application ou le calcul peut être distribué parmi les cœurs de traitement
disponibles voir dédiés (comme le calcul mathématiques de base sur le GPU).
Actuellement, il existe plusieurs bibliothèques qui implémentent différents encodeurs pour les
objets multimédia. Cependant la plupart d’entre eux est centrée dans les processus de CPU et a un
faible degré de parallélisme [5]. En autre, il n’existe pas, à notre connaissance, des IP-Cores publiques
pour le décodage des objets graphiques 3D.
Cet article est organisé comme suit. Dans la section 2, nous présenterons les principales
caractéristiques du codec reconfigurable d’objets 3D (RGC). La section 3 introduit la librairie d’outils
graphiques (GTL - Graphics Tool Library) permettant une production de prototypes plus rapide et une
implémentation flexible dans différentes plateformes (en software et hardware). Basé dans ce GTL,
nous présenterons comment un schéma de compression standard, le QBCR, peut être instancié. Nous
concluons l'article et présentons les perspectives dans la dernière section.
2
Le codeur reconfigurable pour les objets graphiques – RGC (Reconfigurable
Graphics Codec)
L'approche que nous proposons pour le décodage des objets 3D sur architecture parallèle est basée
sur le concept de reconfiguration MPEG RVC (Reconfigurable Video Codec) [6-8]. Le standard
MPEG RCV définie la méthodologie et les spécifications de la technologie pour le codage
reconfigurable des vidéos. Sa principale innovation se trouve dans l’adoption d’un modèle de flux de
données qui utilise le langage RVC-CAL. MPEG RVC associe également un langage pour la
spécification des réseaux d'interconnexion, le FNL [9]. Le concept de la programmation par flux de
données consiste à décrire une application comme une série de modules qui implémentent les
fonctionnalités unitaires et un graph dont les arrêts représentent le flux de données entre les modules.
La programmation des flux de données met en avant le parallélisme potentiel de l’application qui peut
être utilisé pour distribuer les calculs entre les cœurs disponibles. Le langage CAL (Client Access
Licence) est une notation textuelle qui permet la représentation de flux de données, des acteurs et leur
fonctionnalité. Il a été conçu de façon à permettre la description des acteurs en fournissant des
informations statistiquement analysables de leur comportement comme le sont le nombre de jetons
produits et consommés à chaque déclanchement, les conditions qui permettent l’action de ce
déclenché, la description des priorités des actions et leur dépendance.
En utilisant CAL, une application est définie comme une représentation de flux de données
abstraites capable de produire des données prêtes pour la compilation ou de synthétiser du code. A ce
stade, il est possible de produire des versions C, C++, Java et VHDL à partir de la conception abstraite
(Figure 1). Pour faire face aux restrictions de conception de software et hardware, le langage abstrait
connait certaines limitations qui définissent la complexité des opérations que les FUs peuvent
exécuter, la façon dont deux ou plusieurs FUs échangent l’information et leur comportement.
FIFO
PORT_i
FU 1
FIFO
FU 2
FU 3
FIFO
FIFO
FIFO
Figure 1 : Processus d’adaptation de langage
par CAL.
FU 2
PORT_o
Figure 2 : Exemple de processus par FIFO.
Le FU représente un élément de traitement de données et a pour but de consommer et produire des
sous-ensembles de données appelés jetons. Le processus de communication entre deus ou plusieurs
FUs implique l’introduction d’un mécanisme FIFO (premier entré, premier sorti) pour chaque canal de
communication. FIFO permet aux FUs de produire et consommer les données dès qu’elles sont prêtes.
Un exemple d’architecture est présenté dans la Figure 2.
Dans le cadre RVC-CAL, un acteur est un composant modulaire qui peut encapsuler sont propre
état sans avoir accès, ni pouvant modifier un autre acteur. Cet acteur exécute les calculs comme une
séquence appelés firings (déclanchements). Lors de ces déclanchements, les calculs se font en une
action choisie parmi les différentes actions qu’un acteur peut avoir. Une action est capable de changer
le statut de l’acteur. Elle définie la quantité de jetons consommés à l’entrée et peut rendre des jetons.
Sur la base de concepts définis en RVC, qui prévoit l'implantation pour la vidéo (et propose donc
un ensemble des FUs traitent de la vidéo), nous allons introduire dans la section suivante un ensemble
des FUs pour le décodage des objets 3D, groupés dans la bibliothèque GTL (Graphcis Tool Library).
3
Librairie d’outil graphiques (GTL)
La GTL représente une collection de FUs qui sont développées en utilisant le langage RVC-CAL. La
fonctionnalité ainsi que les interfaces d'entrée-sortie de chaque FU sont décrites et permettent un
certain niveau de flexibilité d’instanciation. Il est possible que plusieurs FUs ont la même
fonctionnalité mais des interfaces différentes, permettant ainsi au développeur de l'application de
choisir celles les plus adaptées à l’implémentation.
3.1
Le design du flux des données
Afin de décrire le flux des données, il est nécessaire de défier un réseau qui connecte plusieurs FUs du
GTL pour construire une fonctionnalité donnée. Changer ou ajouter une nouvelle fonctionnalité de
l'ensemble consiste ainsi dans le remplacement ou l'ajout d'une ou plusieurs FUs de la GTL. Le réseau
d'interconnexion entre les FUs est décrit en utilisant le langage XML qui fait référence à des instances
des FUs. Specifiquement, le formalisme FNL est utilisé. Le dernier, s'appuie sur le format utilisé en
environnement Open DataFlow et il est normalisé par MPEG. Le FNL a le support pour la déclaration
des variables locales, l'instanciation des blocks avec des paramètres et la hiérarchie: les blocks
peuvent être des FUs ou des réseaux des FUs. En opposition à d'autres langages de l'environnement
Open DataFlow, le FNL ne peut pas créer des réseaux de manière programmatique. La Figure 4
représente un exemple d’un réseau connectant trois FU décrivant une fonctionnalité complexe et le
code associé.
FU 1
Data1_o
Data2_o
Data3_o
Data4_o
FU 2
Data1_i
Data2_i
Data3_i
Data4_i
Data5_o
FU 3
Data1_i
<?xml ver sio n="1.0" encoding="UT F-8"?>
<XDF name="fnlT est ">
<Inst ance id="FU1">
<Class name="../GTL/ FU 1"/ >
</Inst ance>
<Inst ance id="FU2">
<Class name="../GTL/ FU2"/ >
</Inst ance>
<Inst ance id="FU3">
<Class name="../GTL/ FU3"/ >
</Inst ance>
<Connect io n dst ="FU2" dst -port ="Dat a1_i"
<Connect io n dst ="FU2" dst -port ="Dat a2_i"
<Connect io n dst ="FU2" dst -port ="Dat a3_i"
<Connect io n dst ="FU2" dst -port ="Dat a4_i"
<Connect io n dst ="FU3" dst -port ="Dat a1_i"
</XDF>
src="FU1"
src="FU1 "
src="FU1"
src="FU1"
src="FU2"
sr c -port ="Dat a1_o"/>
sr c-port ="Dat a2_o"/>
sr c -port ="Dat a3_o"/>
sr c -port ="Dat a4_o"/>
sr c -port ="Dat a5_o"/>
Figure 4 : Exemple de réseaux et code FNL associé.
En fonction du dispositif visé, la conception nécessite une traduction à partir du niveau abstrait
vers un code qui soit prêt à être compilé (software) ou synthétisé (hardware). En exécutant un outil
appelé ORCC-compiler, le code à niveau abstrait est compilé dans un langage intermédiaire pour
ensuite être traduit au langage souhaité (C, C++, Java ou VHDL). Au même temps que le code, les
fichiers du projet sont crées s’après la définition du réseau (CMake, VS project, VHDL top-level).
3.2
Unités Fonctionnelles (FUs)
De façon à rendre plus claire l’organisation du GTL, ses composants doivent être divisées entre
différentes catégories d’après leur utilisation dans le processus. Ainsi, nous pouvons distinguer :
a) Les FUs qui sont utilisées pour fournir les données à traiter et stocker : ces FU sont nécessaires au
processus de développement pour simuler des comportements de système avec de vraies données
d’entrée. Par exemple, dans l’implémentation d’un décodeur, les données sont reçues généralement
comme un flux provenant de la source de stockage ou du réseau. Ils transmettent les données au
modules de traitement (par exemple, la transmission de données à un module de rendu 3D ou
directement dans une mémoire vidéo comme structure 3D) et si nécessaire il convertit les structures de
données à un format commun. En général, ses FUs sont développées en utilisant le code visé (C, C++,
Java ou VHDL) et ne sont instanciées que lors de la conceptualisation.
b) Les FUs utilisées dans l’algorithme d’implémentation. Typiquement, les FUs qui peuvent
implémenter les fonctionnalités des algorithmes sont développées en utilisant le langage RVC-CAL
comme la composante modulaire du projet. Elles implémentent des fonctions bien définies et agissent
indépendamment mais sont capables d’échanger des données à travers les ports de connexion. Un
exemple d'un FU algorithmique (quantification inverse) est présenté dans la Figure 5. Basé sur les
informations obtenues par les QP, la FU utilise la fonction inverse appropriée avec les paramètres
quantMin et quantRange. Les données d'entrée sont représentées en 8 bits après traitement, les
données résultantes sont représentées par des entiers de 32 bits. Le nombre de jetons lus peut différer
selon le type d’opération inversée. Cette opération n’est pas dépendante de la taille du réseau étant
donné qu’elle n’utilise qu’un élément (1, 2 ou 3) et traite l’intégralité du flux d’entrée.
c) Les FU nécessaires dans l’implémentation du processus de débogage. Le but de ses FUs est de
permettre au développeur de déboguer une FU des catégories précédentes à partir des données
d’entrée (valeur et ordre) sous forme d’un espace de mémoire accessible ou directement stockés dans
le fichier. Cela permet l’analyse des contenus et des jetons ordonnés produits dans la
conceptualisation. Un des plus grands avantages d'un FU de débogue est qu’il est capable de
reproduire les données d’entrée et sortie, permettant une conceptualisation en temps réel.
Port Name
Data_i
QuantValue_i
quantMin_i
quantRange_i
Data_o
Data Type
Int
UInt
UInt
UInt
UInt
Data Width
8
8
32
32
32
I/O
I
I
I
I
O
Figure 5 : Quantification inverse de FU
En analysant différentes méthodes de compression de maillage 3D, nous avons réalisé le design des 8
FUs.
La
description
complète
de
ces
FUs
est
disponible
à
l'adresse
www.MyMultimediaWorld.com/Projects/CALDER. Une fois la bibliothèque GTL disponible, il est
possible d'implanter un décodeur spécifique en connectant d'une certaines manière les différents FUs.
Nous nous intéressons eux décodeurs MPEG-4 3D, et plus spécifiquement au décodeur SC-3DMC
(Scalable Complexity 3D Mesh Coding) [10]. Le dernier a la spécificité de permettre le ciblage de la
plateforme de décodage par rapport à ses performances matérielles, étant ainsi possible de sélectionner
des jeux des paramètres de compression différents: si le terminal a des capacités réduits en mémoire et
puissance de calcul, une des approches QBCR ou SVA peut entre utilisée, sinon l'approche TFAN va
être utilisée. Comme attendu, les performances de compression sont meilleures quand TFAN est
utilisé car cette méthode permet une analyse de la connectivité du maillage.
Basé sur des FU qui font actuellement partie du GTL, le codeur QBCR a été instancié. La Figure 6
représente une partie de ce codeur, à savoir le décodeur géométrique de l'approche QBCR.
Figure 6 : Décodeur géométrique QBCR.
4
Conclusion
Le concept RGC permet l’implémentation d’une conceptualisation flexible en divisant un
décodeur en différentes unités fonctionnelles (appelées FUs) et dans des sous-réseaux qui agissent
indépendamment et communiquent à l’aide de méthodes définies.
Dans cet article nous avons présenté la conceptualisation d’un codec graphique reconfigurable
(RGC) en définissant la librairie graphique et ses composants, les FUs. L’instanciation pour un codeur
specifique, le QBCR est également présentée.
Les FUs et le cadre RGC s'avère être un outil permettant de produire des prototypes en combinant
des fragments d’algorithmes et de réduire le temps de développement. Du point de vue de
l’optimisation par rapport à le terminal ciblé, le RGC permet la définition locale des FUs et il est
capable d’assurer une gestion efficiente et simple de l'implantation parallèle. Les perspectives de ces
travaux consistent en compléter l'ensemble des FUs de la bibliothèque afin d'obtenir les deux autres
instances definies par MPEG-4 SC-3DMC, le SVA et le TFAN. A noter que le RGC a été récemment
(Avril 2011) retenu comme projet de standardisation par MPEG qui prévoit sa publication comme
standard ISO en 2012.
5
Remerciements
Ces travaux ont été réalisés dans le cadre des projets ANR CALDER et MediaGPU.
Références
[1]
ISO/IEC14496-16:2006, "Part 16: Animation Framework eXtension (AFX) Amendment 1: Geometry and
Shadow ", ed, 2007.
[2] J. Peng, et al., "Technologies for 3D mesh compression: A survey," Journal of Visual Communication and
Image Representation, vol. 16, pp. 688-733, 2005.
[3] R. Da Qi, et al., "Power performance analysis of 3-D finite element mesh refinement with tetrahedra by
CUDA/MPI on multi-core and GPU architecture," in Electromagnetic Field Computation (CEFC),
2010 14th Biennial IEEE Conference on, 2010, pp. 1-1.
[4] L. Haller and S. Singh, "Relieving capacity limits on FPGA-based SAT-solvers," in Formal Methods in
Computer-Aided Design (FMCAD), 2010, 2010, pp. 217-220.
[5] X. Chen, et al., "Design and implementation of MPEG audio layer III decoder using graphics processing
units," in Image Analysis and Signal Processing (IASP), 2010 International Conference on, 2010, pp.
484-487.
[6] E. Bezati, et al., "RVC-CAL dataflow implementations of MPEG AVC/H.264 CABAC decoding," in
Design and Architectures for Signal and Image Processing (DASIP), 2010 Conference on, 2010, pp.
207-213.
[7] K. Jerbi, et al., "Fast Hardware Implementation of an Hadamard Transform Using RVC-CAL Dataflow
Programming," in Embedded and Multimedia Computing (EMC), 2010 5th International Conference
on, 2010, pp. 1-5.
[8] F. Palumbo, et al., "RVC: A multi-decoder CAL Composer tool," in Design and Architectures for Signal
and Image Processing (DASIP), 2010 Conference on, 2010, pp. 144-151.
[9] I. I. 23002-4, "Part 4: Video tool library," ed, 2009.
[10] ISO/IEC14496-16:2011, Marius Preda (Editor) "Animation Framework eXtension (AFX) 4th Edition",
www.iso.ch, Geneva, 2011.