Puissance de calcul constante

En conservant une puissance constante unitaire identique tout au long du traite- ment d’une image, les performances sont alors li´ees au format des donn´ees. En effet, toutes les composantes d’un pixel devant ˆetre trait´ees `a l’aide d’op´erateurs dont la puis- sance de calcul p est fixe, le temps de traitement t d´epend alors du nombre de compo- santes. En conservant toute la puissance de calcul disponible, il est alors possible d’alt´erer la fr´equence de fonctionnement du syst`eme en fonction du nombre de composantes par pixel.

6.3

R´esum´e

En d´efinitive, nous venons de voir un nouvel aspect des diff´erences entre les deux domaines de la vid´eo et de la synth`ese graphique au travers des donn´ees que manipule chacun. La convergence des donn´ees manipul´ees est ainsi un passage oblig´e : une API comme OpenML (Open Media Library [114]) dont le but est de proposer une interface pour le d´eveloppement d’applications audio, vid´eo et graphiques (OpenGL est inclus comme interface pour cette partie) souligne cette n´ecessit´e en d´efinissant des extensions graphiques pour le support de format YCrCb. Nous avons ensuite constat´e, `a l’aide de consid´erations g´en´erales, comment, du point de vue mat´eriel, il est possible d’effectuer `a l’int´erieur d’une mˆeme architecture les rendus vid´eo et graphique.

`

A partir des remarques que nous avons explor´ees, nous pouvons alors justifier les choix qui conduiront dans la partie V `a la mise en place d’un traitement effectuant

les traitements `a l’aide d’une puissance de calcul constante. Cette puissance constante conduit `a un temps constant par composante de couleur des pixels. Ce choix permet d’assurer a priori, dans le cas d’affichage vid´eo, un temps de traitement connu et, par cons´equent, une part d’extensibilit´e selon le format de l’image.

Chapitre 7

Le rendu d’images par tuiles :

mod´elisation et optimisation

Ce chapitre traite de l’organisation du rendu d’images par tuiles et de ses cons´e- quences en terme de complexit´e de traitement puis de bande-passante m´emoire. Nous supposerons dans ce chapitre qu’une image est constitu´ee d’objets (primitives vid´eo ou primitives graphiques). Dans le cas d’objets graphiques, ceux-ci sont constitu´es de maillages de triangles sur lesquels nous appliquons une texture par transformation affine. Cette derni`ere est d´efinie par les positions d’un triangle de r´ef´erence dans la texture et le triangle `a repr´esenter dans l’image. Rappelons que, conform´ement au mod`ele d’archi- tecture pr´esent´e dans la figure2.1chapitre2, les donn´ees de texture sont contenues dans une m´emoire unique ext´erieure `a notre op´erateur.

7.1

Introduction

Nous avons introduit dans le paragraphe 3.3.2.3 le rendu par tuile d’une image. Nous compl´etons cette introduction `a l’aide de donn´ees issues d’une ´etude que nous avons men´ee sur la complexit´e des sc`enes 3D de jeux commerciaux [16]. Cette ´etude dont nous reproduisons de larges extraits en annexeA recherchait `a d´eterminer les caract´eristiques d’un cœur de rendu 3D unifi´e avec les traitements vid´eo pour des r´ecepteurs de t´el´evision. Outre une familiarisation avec le fonctionnement d’une application graphique fond´ee sur l’analyse des appels aux API graphiques des applications, nous avons ´egalement pu ´etudier les implications en terme de bande-passante du rendu par tuiles. Nous repre- nons ici les conclusions que nous avions faites concernant l’activit´e du z-buffer : cf. paragraphe A.3.1 page 210.

L’´elimination des surfaces cach´ees par la technique du z-buffer peut conduire `a une consommation importante de la bande-passante. Dans le cas de la sc`ene comme celle pr´esent´ee au chapitre 3(figure 3.1), sc`ene que nous nommerons dans la suite de la discussion « Vampire », la complexit´e en profondeur des pixels peut ˆetre mod´elis´ee par une loi gaussienne Lg de moyenne 2,34 et d’´ecart-type 1,10. Nous supposerons ´egalement une ´equir´epartition de l’ordre de g´en´eration des pixels de l’´ecran (ordre selon la valeur de la coordonn´ee de profondeur z).

L’algorithme du z-buffer associ´e `a une m´emoire d’accumulation (A-buffer ) en- gendre une lecture de la coordonn´ee z par pixel et, en fonction du r´esultat de la compa- raison avec la coordonn´ee courante (c.-`a-d. l’ordre de g´en´eration des pixels), une lecture du pixel d´ej`a ´ecrit pour effectuer un m´elange des couleurs et les r´e´ecritures du pixel et de la nouvelle coordonn´ee z. Le nombre de lectures Nl. ne d´epend que de la complexit´e

moyenne de la sc`ene et de la taille de celle-ci (Nl. ≈ 2,34 × 640 × 480). Le nombre

de comparaisons Nc. impliquant une r´e´ecriture apr`es m´elange du pixel est donn´e par

l’expression (7.1) o`u d repr´esente la complexit´e en profondeur.

Nc. = ∞ X d=1 Lg(d) d X i=1 1 i ! (7.1)

La coordonn´ee z ainsi que les pixels sont suppos´es cod´es sur quatre octets chacun. Les lectures des seules coordonn´ees z avant comparaison n´ecessitent une bande-passante, `a 30 images pas seconde, de Nl. × 4 × 30 B/s, soit environ 82 MB/s. En appliquant

la formule (7.1) pour le calcul de Nc., les comparaisons impliquant un m´elange et une

´ecriture n´ecessitent une bande-passante d’environ Nc.× 4 × 30 ≈ 65 MB/s pour chacune

des op´erations de lecture du pixel pr´ec´edent, d’´ecriture des nouveaux pixels et d’´ecriture des coordonn´ees z. En dehors de toute optimisation des acc`es, la bande-passante totale n´ecessaire `a la r´ealisation du rendu est donc de 3 × 65 + 82 = 277 MB/s. La localit´e des traitements n’´etant pas assur´ee, le rendement d’un cache ne permettra pas de r´eduire significativement cette bande-passante. `A l’extrˆeme, une architecture tuile, o`u le principe de localit´e est assur´e, autorise les comparaisons et les m´elanges `a partir de m´emoires locales. Seule l’´ecriture finale de la tuile r´esultante est r´ealis´ee et ne n´ecessite qu’une bande-passante de 640 × 480 × 4 × 30 ≈ 35 MB/s.

La r´eduction de l’activit´e de la m´emoire et donc de la bande-passante d’un syst`eme est un des axes majeurs de r´eduction de la consommation [115]. La probl´ematique est d’un large int´erˆet dans le contexte de syst`emes embarqu´es. Le raisonnement pr´ec´edent est donc un argument de premier plan en faveur d’un rendu par tuile. En outre, nous avons d´ej`a signal´e l’extensibilit´e d’une architecture qui utilise ce mode de rendu.

Cependant, le rendu par tuile introduit des contraintes (d´eterminer quels triangles traiter, comment les traiter, etc.) dont les effets de bords peuvent ˆetre r´edhibitoires. C’est pourquoi nous allons tenter de mod´eliser dans une premi`ere partie l’impact de ce type de rendu sur les puissances de calcul mises en jeu. Nous proposerons ensuite un mode de parcours qui a l’avantage de permettre une compatibilit´e entre un rendu purement vid´eo et de la synth`ese d’images. Nous r´e´evaluerons alors les puissances de calculs mises en jeu. Dans une seconde partie, nous ´etudierons plus pr´ecis´ement la mani`ere d’acc´eder aux donn´ees n´ecessaires au parcours propos´e. Finalement nous montrerons comment il est possible de tirer profit des propri´et´es du rendu par tuiles pour approcher le comportement d’un cache parfait.