Architectures multi-GPU et hybrides au service de l`automotive

Transcription

Architectures multi-GPU et hybrides
au service de l'automotive
AXIS / IEF - Université Paris Sud
Marius Vasiliu et l'équipe SimCode
"Smart" automotive et GPU
L'automotive est
technologique due
bouleversements :
entré
à la
dans une phase d'explosion
superposition de plusieurs
L'entrée massive sur le marché des véhicules hybrides ou
électriques
Besoin accru de sécurité et fiabilité
Optimisation des ressources de transport
Réduction des consommations énergétiques et de la pollution
Baisse de prix dramatique des capteurs ( ± "intelligents" )
L'automotive a besoin d'une puissance embarquée de
calcul de plus en plus forte, avec les limites raisonnables
de consommation (< 60-100W )
Nombre très important de projets automotives
complexity
"Smart" automotive et GPU
Pedestrian
recognition
Lane keep
assistant
Road keep
assistant
Driver assistant
Semi-auto drive
Driver
monitoring
Traffic sign
recognition
Pre-crash system
360° display reconstruction
Rear parking camera
2006
2010
2014
year
Quelles types d'architectures embarquées ?
L'expérience des projets précédents (Picar, LOVe etc.)
nous montre que l'on peut utiliser des architectures
embarquées "light" (µC, DSP, FPGA) pour quelques
fonctionnalités bien particulières mais ...
Les applications vidéo (acquisition, traitement,
affichage éventuel) demandent une bande passante
"totale" proche du Go/s.
Les traitements 3D vidéo SD demandent des centaines
de GFlops, pour la 3D sur vidéo HD il faut plus d'1 TFlops
Une mémoire d'une seconde demande 1-2 Go ...
La complexité des traitements impose rapidement une
solution embarquée "heavy" où la place des GPU et la
programmation Cuda sont essentielles.
Exemple d'application automotive :
le projet SimCode (IEF/Limsi)
Réaliser
des
véhicules
électriques
d'autonomie "intelligente" à court terme :
capables
déplacement semi-autonome d'un point A à un point B avec
intégration dans les aléas du trafic.
B
A
supervision locale et/ou à distance par réalité augmentée
Exemple d'application automotive :
le projet SimCode (IEF/Limsi)
Supervision locale et/ou à distance :
flux stéréoscopique + métadonnées envoyés à distance par
réseau WiMax+Internet ou 3G.
l'acteur distant dispose d'une réalité virtuelle augmentée
(vision 3D + indications vitesse, position, choix stratégiques
etc.) et prend des décisions "de haut niveau" :
continuer en "safe mode" (faible vitesse et sécurité maximale)
changer de direction
changer de vitesse moyenne
effectuer un dépassement, changer de voie
outrepasser une restriction ou un consigne
garer la voiture
Architecture centralisée ou distribuée ?
Architecture distribuée : robuste mais difficile à diriger
nombre variable de dispositifs, généralement associés aux
capteurs
communication et contrôle par bus (CAN ou FlexRay)
grosse variété d'architectures : µC, DSP, FPGA, ASIC
consommation individuelle faible mais le total est important
très difficile à synchroniser et à étiqueter temporellement
Architecture centralisée : souplesse et puissance
unité centrale GPU+CPU qui décide de l'activation et de la
communication avec les capteurs et les actionneurs
algorithmes souples : adaptation et activation sélective des
briques logicielles en fonction de la réalité terrain
étiquetage et synchronisation centralisées des données,
accès local pour traitement et fusion sur CPU et GPU,
tolérance aux pannes
Architecture GPU centralisée : critères
Puissance de calcul
la charge de calcul nécessaire est variable dans le temps mais
dans de situations critiques et accidentogènes c'est la
puissance maximale qui compte
cela élimine dès le départ les architectures Tegra 2.x ou 3.x
80% de la puissance demandée concerne des algorithmes
(massivement) parallèlisables Î sur GPU, mais les CPU
restent nécessaires
pour des algorithmes souples et adaptatifs la puissance
moyenne de calcul ne dépasse pas 30% de la puissance de pic
Consommation
horloges variables et gestion avancée de l'énergie
les versions GT200 et GF10x pour portables répondent bien
aux contraintes
Architecture embarquée ciblée (2010)
PC portable assurant l'ensemble des traitements (bas,
moyen et haut niveau) : 1 CPU Core2 Extreme (4 cœurs)
et 2 GPU (2 x 128 cœurs)
Core2 Extreme
µP
µP
µP
µP
chip-set
NVidia
DDR3 8Go
bus PCI Express x 8
DDR3 1Go
GTX 280M
128 PE ( 16 x 8 )
GPUs
GTX 280M
128 PE ( 16 x 8 )
GPUs
DDR3 1Go
DVI-D
Architecture embarquée ciblée (2011)
PC portable assurant l'ensemble des traitements (bas,
moyen et haut niveau) : 1 CPU Sandy Bridge (4x2 cœurs)
et 1 GPU (8 x 48 cœurs)
Sandy Bridge
DDR3 16Go
µP µP
µP µP
µP µP
µP µP
chip-set
Intel
bus PCI Express x 16
GTX 485M
384 PE ( 8 x 48 )
GPUs
DDR5 2Go
DVI-D
GTX 485M (Clevo P170HM)
Scores GPU 3DMark
Cible #2
Cible #1
( courtesy of J.S. Leitner, 1/6/2011)
Architecture de l'écosystème automotive
accéléromètres
GPS
caméras
HD Bayer
Flux
Fluxstéréo
stéréoraw
raw
Analyse
Analyseetettraitement
traitementen
en
temps
-réel
temps-réel
caméras IR
Consignes
Consignes
liaison WiMax
et/ou 3G
Arbitrage
écision
Arbitrageetetddécision
Flux
Fluxstéréo
stéréocompressé
compressé
LIDAR
vitesse,
vitesse,
direction,
direction,
frein
frein
bus CAN
odométrie,
odométrie,
état
étatetc.
etc.
Types de données dans le système
Niveau interfaces (acquisition / communication) :

flux vidéo ( 2 x 25 img/s ) : niveau gris, Bayer, YUYV, RGB

paquets lidar ( 25 paquets/s, ≅700 pts 3D/paquet )

trames CAN : commande moteur, direction, frein, retours
odométriques, charge batterie etc. ( ≅500 trames/s )

trame GPS : position, nb. satellites etc. ( 1 trame/s )

vecteurs 3D accélération ( nb. accéléromètres x 20-100/s )

commandes utilisateur (10-50 échantillons/s)
Niveau traitement

nuages de points (3D, 3D+T, 3D+T+features etc.)

pistes / trajectoires (3D+T)

cartes / matrices (de disparité, vitesse, probabilité)

arbres et listes (probabilités, features etc.)
Les échelles temporelles
de nos applications automotives
Echelle de bas niveau (<50 ms) :

Commandes et contrôle moteur, direction, frein

Synchronisation & time-stamp : accélero, caméra, lidar
Echelle de moyen niveau (50ms - 2 s) :

Durée raisonnable de garde en mémoire des données

Inspection et reconstruction de la scène,

Détection et suivi d'obstacles,

Evitement "automatique" d'obstacles
Echelle de haut niveau (2s - 30 s) :

Planification de trajectoires

Engagement de dépassement ou changement de voie

Garer le véhicule, franchir une intersection
Contraintes de communications et réaction
La bande passante montante est limitée et
(150Ko/s - 2 Mo/s) alors que le flux vidéo brut
moins 80 Mo/s
variable
est d'au
Le délai de communication est variable (correction des
erreurs, micro-commutations WiMax ou 3G, routage)
60% du temps la boucle a un retard inférieur à 500ms :
dans ces cas une "vraie" conduite à distance est
envisageable, mais ...
Il y a des moments (<2%) où la boucle de contrôle à
distance a un retard de 3s ! Les voitures doivent être
autonomes et sures pendant cet intervalle de temps.
La synchronisation et le time-stamping sont essentiels
Briques de base et algorithmes souples
Time-stamping et association de données
Conversion et rectification epipolaire des flux vidéo
Validation ou correction de calibration en temps-réel
Stereo matching et calcul de profondeur
Histogrammes U et V-disparité, détection des points et
cibles remarquables
Odométrie visuelle, fusion et validation de l'odométrie
GPS et lidar (2 échelles de temps)
Détection du plan et des bords de la route et des
obstacles (voitures, piétons, mobilier urbain)
Détection et lecture des panneaux routiers
Planification de trajectoires
Interface de communication utilisateur (compression,
transmission,
réalité
augmentée,
validation
de
commandes etc.)
Vivement l’architecture hybride !
Seulement une partie des briques méritent d’être
implantées sur GPU, les autres sont optimisées sur CPU
Critères de décision :
potentiel de parallélisation
structures de données
débit de lecture / écriture
enchainement des traitements, affinité avec d'autres briques
Le traitement irrégulier, le parcours d'arbres, de tables
d'indexation ou liste, contrôle ou lacement de kernels Î
mieux sur CPU
Le traitement d'images,
compression, décompression,
sur GPU
de nuage de points,
affichage 2D/3D Î mieux
Briques de base et algorithmes souples
Le traitement et l'activation des briques n'est pas
forcement régulier. Exemples :
Détection et lecture des panneaux routiers
Briques actives dans une action de dépassement
Briques nécessaires pour garer la voiture
Validation et correction dynamique de calibration
Les algorithmes doivent être souples
temporellement, demander le minimum d'intensité de calcul
nécessaire
spatialement, pour la vidéo, le lidar : utiliser des zones
d'intérêt de taille minimale, avec adaptation dynamique
(surveillance des extrémités de la scène et poursuite des
objets remarquables)
accorder des priorités claires entre les algorithmes
prendre les meilleurs décisions sans l'ensemble des données
Algorithmes souples et économie d'énergie
Souplesse Î diminuer la charge moyenne et
augmenter (éventuellement) les pics de charge
Comment cela se traduit en pratique ?
Gestion d'énergie de GF104 (version GTX 485M)
"Performance states" : de P0 (maximum) à P15 (min. / idle)
Accessibles par les NvAPI : GetDynamicPstatesInfoEx
Concernent plusieurs blocs architecturaux :
1. Graphic Engine (les coeurs GPU)
2. Frame Buffer (la mémoire)
3. Video Engine (les shaders)
Variation de fréquences (charge 0% Î charge 100%):
Cœurs :
50 MHz Î 580 MHz
Mémoire : 135 MHz Î 1500 MHz
Shaders : 100 MHz Î 1150 MHz
En l'absence de charge, les fréquences retombent après ≅17 s
Variation des fréquences et de la consommation de
GTX 485M pendant un pic de charge de 25 secondes
100
GPU Load [%]
50
0
0,00
10,00
20,00
30,00
40,00
50,00
60,00
70,00
80,00
1600
1400
P0
Core Clock [MHz]
1200
Memory Clock [MHz]
1000
Shader Clock [MHz]
800
P8
600
P12
400
200
P12
0
0,00
10,00
20,00
30,00
40,00
50,00
60,00
70,00
80,00
90,00
Quelle stratégie pour les systèmes multi-GPU ?
1.
Bien sur, pas d'activation du SLI
2.
Si besoin important (pic de consommation) :

3.
Si le nécessaire ne dépasse pas les 30-40% de la
puissance totale maximale :

4.
distribution équitable sur les 2 ou 3 GPU en utilisant les
techniques asynchrones (multi-threading, streams et
synchronisation sur événements)
utilisation d'un seul GPU à puissance maximale et repos des
autres en idle
Le basculement entre les 2 modes doit se faire
une stratégie de haut niveau, déclenchée par
choix de l'utilisateur et/ou l'état de la route
par
les
Comparaison entre les cibles HW (PC complet)
Critère
2* GTX 280M 1* GTX 485M
Consommation max. alim. PC
210 W
220 W
Consommation max. mesurée
110 W
130 W
Consommation moyenne
50-60 W
50-65 W
Score GPU 3DMark
9649 (SLI)
12142
Débit CPUÎ1 GPU mesuré
1542 Mo/s
3870 Mo/s
Débit GPUÎGPU mesuré
48430 Mo/s
52970 Mo/s
Débit 1 GPUÎCPU mesuré
1155 Mo/s
3649 Mo/s
Support peer-to-peer
NON
OUI mais ...
Vitesse moyenne partie GPU
100%
103-120%
Vitesse moyenne partie CPU
100%
110-140%
Stereo-matching (full, 640x480)
80 img/s
50 img/s
Pourquoi parfois une baisse de performances ?
La scalabilité des
architectures Cuda 1.x
automatique ...
performances entre les
et 2.x n'est pas forcement
Code de stereo-matching optimisée pour, sur GT200
(GTX280M) : 25ms Î 2 x 40 img/s
Le même code (recompilé dans le même version 3.2
ou 4.0) sur GF104 (GTX485M) : 20ms Î 50 img/s
1ère explication : notre code n'utilise pas assez les
384 cœurs (pas assez de blocks et de threads ...)
Mais, sur les architectures 2.x on peut lancer
plusieurs kernels en parallèle ! Si on lance 2 kernels
décalés (pour 2 paires successives) : ≈24ms/paire
donc finalement 2 x 42 img/s
Affichage stéréoscopique NVidia sur GeForce
Les scènes 3D rendues sous DirectX s'affichent
automatiquement en 3D si le mode 3DVision est actif
Mais afficher 2 flux vidéo 2D + insertion des features
pour la réalité virtuelle augmentée c'est plus
compliquée ...
Utilisation des procédures présentées par S. Gateau
(pas de doc officielle) et adaptées à notre système
Compatibilité 100% avec Cuda et les NVApi
Points essentiels :

En mode 3DVision la surface primaire et le back-buffer d'une
render target sont déjà stéréo (2 fois la largeur demandée)

Le seul accès passe par une copie StretchRect intégrale
d'une surface utilisateur contenant une signature NVidia
vers le back-buffer en question !
Affichage stéréoscopique NVidia sur GeForce
Receive /
Database
Full stream decoding
Left Video
Stream
Features
2D+
Right Video
Stream
User off-screen surface
GetDC
left
StretchRect
right
signature NVidia
Full Screen (device backbuffer)
Features
DrawPrimitive
3D
left
Present
right
Full Screen (device primary surface)
left
right
Outils d'analyse et optimisation
Au-delà des optimisations "classiques" au niveau
Cuda, de l'analyse avec le profiler ou le debugger,
pour une optimisation avancé, il faut valider et
analyser le vrai code GPU qui sera exécuté
Nous avons développé un outils qui désassemble et
analyse le code GPU (SSES) généré : CudAnalyser
Mieux que CuObjDump ou Parallel Nsight de NVidia
(interface graphique, registres symbolique)
Inspiré par CudaVis et Decuda, il se présente comme
une application autonome (.exe) qui n'a besoin
d'aucune bibliothèque spécifique (compilation
statique sous Qt)
Support 64 bits (Fermi) en cours de développement
CudAnalyser
CudAnalyser
Fonctionnalités de CudAnalyser :

L'ouverture d'un ficher *.cubin sous format texte ou binaire

Le choix des kernels qui seront désassemblés

L'affichage sélectif des adresses, du code binaire, des
étiquettes, des opcodes, des opérandes, des prédicats

L'affichage de l'utilisation des registres générales, de
condition etc.

L'exportation des listings sous format texte, RTF ...
A quoi cela sert ?

A vérifier l'application effective des options de compilation

A vérifier l'effet des inline assembleur (Cuda 4.x)

A apprécier le potentiel d'optimisation

A trouver (et contourner) d'éventuelles erreurs de nvcc
Exemple de choix d'implantation
Les 2 cameras vidéo qui partagent le FireWire
utilisent des capteurs Bayer 1292x964 et peuvent
envoyer les images sous les formats suivants :

raw (Bayer) Î 1 octets /pixel

niveau de gris Î 1 octets /pixel

YUV Î 2 octets /pixel

RGB Î 3 octets /pixel
Parcours des images :

carte FireWire

mémoire non-paginée CPU

mémoire GPU

changement éventuel de format vers RGB

rectification épipolaire

utilisation / matching / encodage / affichage
Direct GPU ?
Quel est le format qui optimise la bande passante et
la vitesse de traitement ?
1er choix : RGB

les caméras font le travail de conversion

le débit nécessaire : 2x93.4 Mo/s (> 75Mo/s : débit FW max)

il faut découper les images et renoncer à RGB
2ème choix : YUV422

les caméras travaillent mais 2 fois mois de chrominance

pour une découpe de 1200x512 : 2x30.72 Mo/s

le GPU doit convertir en RGB avant la rectification
3ème choix : niveaux de gris

on a perdu la couleur, cela ne nous intéresse pas
4ème choix : raw Bayer

les caméras vont chômer ! mais on gagne 10-15 ms ...

on a information mais le GPU devra travailler ... mais pas
plus dur que pour le 2ème choix !

pour la même bande passante on peux se payer le lux de
transmettre toute l'image : 2x31.1 Mo/s !
Que fait le GPU ?

Interpolation Bayer : plus simple que les multiplications
pour les conversion YUV Î RGB

Rectification épipolaire
Comment ?

En utilisant les textures

En utilisant pas les textures
Utilisation des textures
Utilisation des surfaces
L'interpololation sera faite
par les coeurs GPU sans
faire appel aux unités de
calcul des textures :
Le calcul est plus rapide
que l'écriture des 3 textures
précédentes !
Peut-on aller plus loin ?
Au lieu d'interpoler par pas de 1.0, on peut faire
directement la rectification épipolaire ! Il suffit de
précalculer les coefficients de la carte de déformation
en fonction des voisins existants.
Perspectives et conclusions
Dans la conception des systèmes complexes la
première impression ne pas forcement la meilleure
L'optimisation de tels systèmes dépend de beaucoup
trop de facteurs pour envisager une exploration
complète de l'espace des possibilités
Les facteurs de robustesse, consommation, coût
sont parfois aussi importants que le reste ...
Et il reste une nombre important de briques à
optimiser, pour les faire tourner en temps réel.
Envisager l'aide de NVidia pour une extension de
Direct GPU aux drivers FireWire sous Windows
"Normalisation" des stress-tests d'un véhicule semiautonome