Les données stoquées sur la carte graphique ne permettent pas l’utilisation des conteneurs de la li-brairie standard, en fait il n’existe pas de représentation "objet" sous CUDA, la programmation est séquentielle. La mémoire vidéo est également plus limitée et son usage très sensible.
Dans la plateforme d’accueil, la mémoire est éparse et fragmentée. Les objets sont créés dynamique-ment en cours d’exécution et les zones mémoires relatives à chaque objet sont allouées dynamiquedynamique-ment en cours d’exécution. La figureIII.24présente cet état de fait. Les définitions des objets du simulateur sont réparties dans la mémoire vive. Du point de vue d’une application prévue pour le microprocesseur central, ce n’est pas un problème.
Pour ce modèle, en revanche, il est nécessaire de redéfinir l’information et son organisation avant de pouvoir la transférer sur la carte graphique.
géométrie (SiVIC) repère local (SiVIC) propriétés (SiVIC) boite englobante (SiVIC) géométrie (CUDAH) repère local (CUDAH) propriétés (CUDAH) boite englobante (CUDAH)
Figure III.24 – Préparation des buffers de données pour le transfert de l’information sur la carte gra-phique
Il apparaît également sur la figureIII.24d’autres zones mémoires sous l’appellation CUDAH (signifiant que l’information est prévu pour être transférer sur la carte graphique (CUDA) mais que celle-ci se situe encore sur la mémoire vive, côté microprocesseur (H pour Host)), ces zones sont définies de façon contigues. Une représentation plus fine de cette zone est la figureIII.25.
Pour ce modèle, les objets sont définis sous forme de structures élémentaires correspondant à leur différentes caractéristiques. Ces structures ont une taille fixe. Il est donc très facile de déterminer la position de la structure associée à un objet dans la zone allouée grâce à son ID. Une caractéristique de l’objet cependant échappe à cette règle, il s’agit de la géométrie. En effet, tous les objets n’ont pas la même représentation spatiale et cela se caractérise notamment par un nombre de facettes variable.
geometry0geometry1geometry2geometry3 . . . locate0 locate1 locate2 locate3 . . .
property0 property1 property2 property3 . . . boundingbox0 boundingbox1 boundingbox2 boundingbox3
. . . geometry
geometryID
geometryID + geometrySize
Figure III.25 – Principe de la propagation électromagnétique mis en oeuvre dans le modèle "aéronau-tique"
Le même principe est cependant appliqué, à la différence près ici que la géométrie de l’objet est carac-térisée à la fois par un buffer mémoire (geometry) où est stocké l’ensemble des géométries des objets et une structure propre à chaque objet (geometry0, geometry1, . . . ) permettant d’accéder aux informa-tions concernant l’objet par rapport à l’adresse du début de la zone stoquant la géométrie: la position relative du premier point caractérisant l’objet (geometryID) et le nombre de points (geometrySize). Un objet, outre sa géométrie, est caractérisé par l’ensemble des propriétés définies dans la table2.2.
Propriété Définition Taille associée
Géométrie de l’objet
Objet statique bool: static 1octect
Position début int: pos 4octects
Nombre de points int: size 4octects
Total 9octects
Repère de l’objet
Origine double3: O 3* 4 octects
Axe X double3: x 3* 4 octects
Axe Y double3: y 3* 4 octects
Axe Z double3: z 3* 4 octects
Total 48octects
Matériau de l’objet
Coef. de Fresnel double: N1, N2 2* 4 octects Polariseur double22: p 4* 4 octects
Nature objet int: mode 4octects
Coef. de Diffusion double:dδ, h, f 3* 4 octects
Total 40octects
Boite englobante de l’objet
Origine double3: O 3* 4 octects
Axe X double3: x 3* 4 octects
Axe Y double3: y 3* 4 octects
Axe Z double3: z 3* 4 octects
Dimension double3: dim 3* 4 octects
Total 60octects
Total Objet 157octects
Tableau III.4 – Données nécessaires au modèle CUDA
Dans ces conditions, il est possible de définir 417 objets (64 ko / 157) en mémoire constante si l’en-semble des informations caractérisant un objet est nécessaire pour unKernel.
Ce n’est pas suffisant pour permettre de prendre en compte l’ensemble des objets définis dans le simulateur. Un véhicule, en considérant celui-ci comme étant simplement un chassis, deux pare-chocs, quatre routes (jante et pneu) ainsi que deux pare brises et huit vitres latérales, représente déjà plus de vingt définitions d’objet différentes.
Les définitions d’objet comme la géométrie sont donc stockées dans la mémoire locale (mémoire vidéo de la carte graphique)
Dans une scène virtuelle, tous les objets ne sont pas dynamiques. Le paysage, la végétation (les arbres) ainsi que les bâtiments constituent des objets dont la géométrie n’évoluera pas au cour de la simulation, tout comme les véhicules stationnés qui n’intègrent pas de modèles dynamiques. Un objet qui partage sa définition géométrique avec un autre sera considéré comme dynamique.
Les transferts d’information entre le simulateur et le modèle doivent se faire à chaque itération, cette tache doit être la plus rapide possible et limiter autant que faire ce peux les échanges entre les deux mémoires. De même, limiter les calculs inutiles dans lesKernelspermet de gagner des cycles d’horloge. Pour les objets comme le relief, considérés comme statique, la géométrie est définie par rapport au repère monde, il n’est donc pas nécessaire pour un objet statique de recalculer les coordonnées de sa géométrie à chaque itération. Pour les objets statiques, comme pour les problèmes exécutés sur leCPU, il est nécessaire de recalculer les coordonnées dans le repère mondes des points de la géométrie mais seule la zone mémoire correspondant à la définition du repère de l’objet est mise à jour entre chaque itération.
Les premiers essais de mise en oeuvre ont souvent été perturbés par un code qui finissait par ne plus compiler. Non pas à cause d’erreurs mais dù à la taille duKernelgénéré qui devenait trop importante pour les capacités de la carte graphique. Dans le modèle de capteur, cette problématique n’est pas apparue, les traitements sont simples et non conditionnés et leur taille est toujours restés raisonnable. Ce n’est pas le cas des traitements réalisés ici.
La prise en compte de paramètres qualitatifs comme la rugosité implique l’utilisation de modèles plus complexes pour le calcul de la réponse de la surface. En fonction de cette nature, les traitements divergent.
De même la nature volumique du lancer de faisceau induit des réponses également différentes en fonction de l’intersection avec une surface. L’interface entre un faisceau et une surface élémentaire peut mener à plus de 12 réponses possibles (figureIII.29), dont la plus complexe mène à 6 sous-faisceaux distincts.
La taille des Kernels n’a donc cessée d’augmenter au fur et à mesure de l’implémentation faisant échouer à plus ou moins long terme la compilation. La solution consiste à découper leKernel initial en plusieurs sousKernels comportant seulement une partie du traitement associé à un aspect de la problématique traitée.
Ce découpage à conduit à la définition du moteur de propagation du modèleCUDA du diagramme
Unified Modeling Language (UML) III.26.
Le DataManager est l’interface entre la définition des objets dans le simulateur et la représentation utilisée dans ce modèle de propagation. Il est également responsable des transferts de mémoire entre l’architecture centrale et la carte graphique.
Les modèles d’objet, d’un point de vue géométrique sont complexes, et leurs définitions comportent pour certains plusieurs centaines de milliers de facettes. Il ne serait pas raisonnable d’effectuer les trai-tements sur l’ensemble de ces facettes sans s’être préalablement assuré qu’elles interviendraient effecti-vement dans la situation concernée. Tous les objets situés derrière l’origine du faisceau par rapport à sa direction de propagation ne seront pas concernés par celui-ci lors de cette propagation initiale. Aussi, avant d’effectuer les calculs d’interactions physiques survenant sur une facette, le modèle procède à un ensemble de tests permettant de sélectionner les facettes réellement concernées par le traitement. La première étape dans cette sélection est réalisée par l’ ObjectSelecter . Il détermine les objets impactés par un faisceau en se fondant sur la définition de leur boîte englobante.
ObjectSelecter : {fi}i∈{1..N}×oj j∈{1..M} −→ (fi, oj)k k∈{1..K} (fi, oj) 7−→ (fi, oj) , si fiintersecte oj rien , sinon (III.6)
DataManager #statics : Objet3D[] #dynamics : Objet3D[] #beams : Beam add_static(Objet3D) : void remove_static(Objet3D) : void add_dynamic(Objet3D) : void remove_dynamic(Objet3D) : void . . . ObjectSelecter process() : void FaceSelecter process() : void PhysicsProcess process() : void SubBeamComputer process() : void
Figure III.26 – Diagramme UML du modèle de propagation CUDA
avec {fi}i∈{1..N}, l’ensemble des faisceaux présents dans la scène, oj j∈{1..M} l’ensemble des objets pris en compte par le modèle et
(fi, oj)k
k∈{1..K} l’ensemble des couples caractérisant les interactions faisceau-objet dans la scène. Un objet et un faisceau peuvent être représentés plusieurs fois au sein de ces couples.
La seconde étape consiste à sélectionner cette fois-ci les facettes de l’objet qui sont concernées par le faisceau, c’est le rôle du FaceSelecter .
FaceSelecter : (fi, oj)k k∈{1..K}× f cj,m m∈{1..Mj} −→ (fi, f cj,m)l l∈{1..L} (fi, f cj,m) 7−→ (fi, f cj,m) , si fi intersecte f cj,m rien , sinon (III.7) avec K, le nombre de couple faisceaux-objet définis par l’ ObjetSelecter , et K0 le nombre de couples caractérisant les faisceaux et les faces concernés. Une face et un faisceau peuvent être représentés plusieurs fois au sein de ces couples.
Une face est considérée comme illuminée si (cf. figure2.2) une partie de sa surface est contenue dans le faisceau, etN~f = −k.N~b.
Il s’agit donc ici de déterminer la position des sommets vis à vis des trois plans définis par le faisceau, et donc vis à vis des quatre espaces associés. Si tous les sommets se trouvent dans un même sous-espace, autre que celui définissant l’intérieur du faisceau, la face n’est impactée. Autrement, il existe une intersection.
Ces deux premiers traitements permettent d’effectuer les traitements physiques de manière plus par-cimonieuse.
x y z A B C Nb D E F face Nf
Figure III.27 – Paramètre du test de l’orientation des faces.
x y z A B C D E F
Figure III.28 – Détermination des sous-faisceaux d’intersection.
Mais avant cela, il reste à déterminer les sous-faisceaux caractéristiques des intersections. Ce rôle est dévolu au SubBeamComputer
Le SubBeamGenerator détermine ensuite quelle partie du faisceau impacte la face (figure2.2) et défini le ou les sous-faisceau(x) associés. Le modèle ne travaille qu’avec des faisceaux à base triangulaire. Ainsi en fonction de la forme de l’intersection, il peut arriver que l’intersection génère plus d’un sous faisceau. Le pire scenario étant une intersection sous la forme d’une étoile de David, nécessitant la génération de 6 sous-faisceaux (figureIII.29).
Tous les aspects liés à la géométrie sont traités, il ne reste plus qu’à définir les interactions entre les sous-faisceaux et les faces. C’est le rôle du PhysicsProcessor . Il détermine les interactions entre les sous-faisceaux impactant et les faces impactées, en fonction de leurs caractéristiques. Ici encore, toutes les interactions définies dans le modèle ne peuvent pas être prises en considération simultanément à cause de la taille cumulée du Kernel associé. Le premier traitement du PhysicsProcessor consiste à appliquer le modèle de diffusion associée à la surface. Puis il détermine les faisceaux transmis et réfléchis. Les traitements associés au PhysicsProcessor peuvent donc amener pour chaque faisceau à trois sous-faisceaux résultats.
Le phénomène de propagation lors des interactions est un phénomène exponentiel. Deux critères per-mettent de le maîtriser, ce sont les critères d’arrêt du modèle. Le premier concerne un aspect purement pratique, le nombre de multi-réflexion maximum prises en compte par le modèle, le second plus phy-sique est fondé sur une quantité minimale transportée par le faisceau pour considérer que celui-ci peut encore avoir un rôle significatif dans la génération du signal reçu.
Ces deux implémentations correspondent aux deux modèles génériques de propagation mis en oeuvre dans le cadre de ces travaux. Il reste deux modèles plus orientés vers les capteurs directionnels et plus particulièrement les radars de distance et l’analogie pouvant exister entre les antennes radars et les caméras.
Figure III.29 – Intersection possible entre un faisceau et une facette (coupe 2D): de gauche à droite, l’intersection représente: aucun faisceau, un faisceau, deux faisceaux, trois faisceaux, six faisceaux.