Qui dit congés dit forcément une tonne de vidéos à sauvegarder. Je possède 2 équipements qui font des vidéos HD un caméscope et un appareil photo.
Dans les 2 cas, le codec utilisé est le AVCHD, c’est un bon codec pour faire de la HD mais comme il doit fonctionner sur des appareils avec petit CPU embarqué il ne peut pas compresser beaucoup les vidéos. Je me dois donc de trouver un logiciel de conversion de vidéo vers des codec vidéos moderne et léger, et quoi de mieux aujourd’hui que le conteneur MP4 avec le couple de codec Video/Audio H264/AAC qui est maintenant massivement répandu.
Le travail des vidéos à toujours était pour moi quelque chose de rébarbatif, et les logiciels de conversions y sont pour beaucoup. Je pense à SUPER et autre MediaCoder qui ont des interfaces repoussant le plus courageux des débutants. Vous savez ce sont ces logiciels avec des myriades d’options plus inutiles les unes que les autres pour les béotiens de la vidéo que nous sommes qui finissent toujours par vous convertir la vidéo n’importe comment. De surcroit j’ai une carte graphiques supportant CUDA, et il serait une gageure de ne pas l’exploité ce que je ne suis jamais arrivé à faire avec ces 2 derniers.
Bref, mon besoin est simple : Je veux convertir en masse des vidéos en utilisant CUDA sans avoir à toucher des options.
Voici la seconde partie de mon article sur les GPU.
Celui-ci vous permettra de découvrir CUDA de NVIDIA
1 Présentation
CUDA ou Computer Unified Device Architecture est une librairie de développement créée par NVIDIA en 2007. Celle-ci associée à une carte graphique compatible, permet d’utiliser la puissance de calculs des GPU d’architectureG80 et plus de NVidia (à partir des GeForce 8800 et déclinaisons).
Par abus de langage nous parlerons aussi de langage CUDA.
CUDA est aussi le premier langage à exploiter l’unification des shaders : les processeurs de la carte ne sont pas différentiés en unités pour le traitement des vertex ou des fragments, chacun de ceux-ci peut être assigné à n’importe quelle tâche.
L’API CUDA supporte plusieurs langages tels que le C, le C++ et le Fortran.
Ces trois langages peuvent être utilisés simultanément pour écrire diverses fonctions exécutées par le GPU.
Il existe cependant des « wrapper », des passerelles, servant de liaison entre ces langages bas-niveau et des langages de plus haut niveaux tels que Python, Java et .Net.
CUDA est constitué d’un pilote (driver), déjà intégré aux drivers les plus récents, d’un runtime, et de quelques librairies.
Les différents composants de CUDA
Il existe 3 niveaux de programmation pour CUDA, chacune disposant de sa propre API :
– Utilisation d’une librairie externe.
Celle-ci, possède le code de toute les fonctions à exécuter par le GPU, et sert de liaison entre le programme et le GPU.
Le développeur ne peut utiliser que certaines fonctions prédéfinies, et ne peut contrôler directement le GPU.
Les deux librairies les plus connues sont CUBLAS qui offre un ensemble d’éléments pour réaliser des calculs d’algèbre linéaires sur le GPU, ainsi que CUFFT qui permet le calcul de transformée de Fourrier.
– l’API de haut niveau : l’API CUDA Runtime ou appelée plus communément C for CUDA.
Cette API est implémentée « au dessus » de l’API bas niveau. Chaque appel à une fonction du runtime est décomposé en instructions plus basiques gérées par l’API driver.
Ces 2 API sont exclusives : le programmeur doit utiliser soit l’une soit l’autre. Il est impossible de mélanger des appels de fonctions de l’une et de l’autre.
Lorsque l’on parle d’API de haut niveau, il convient de relativiser : l’API runtime reste ce que beaucoup considèreraient comme déjà de très bas niveau. Cependant elle offre des fonctions bien pratiques pour l’initialisation ou la gestion des contextes.
Cette API sera la plus couramment utilisée.
– l’API de bas niveau : l’API CUDA Driver.
Cette API est plus complexe à gérer, elle demande plus de travail pour lancer un traitement sur le GPU, mais en contrepartie elle est plus flexible, offrant un contrôle supplémentaire au programmeur qui le désire.
Cette API a l’avantage de pouvoir charger des portions de code en tant que module à partir de code binaires CUDA ou de code assembleur, et permet aussi d’inspecter les paramètres, …
Cette API est beaucoup plus difficile à écrire, à débugger et nécessite beaucoup plus de lignes de code à écrire, mais elle offre de meilleure performances.
Les API Runtime et Driver sont capables toutes les deux de communiquer avec des ressources OpenGL ou Direct3D. L’utilité est évidente : CUDA pourrait être utilisé pour générer des ressources (géométrie, textures procédurales, etc.) qui seraient ensuite passées à l’API graphique ou à l’inverse on pourrait imaginer que l’API 3D pourrait envoyer le résultat du rendu à CUDA qui serait dans ce cas utilisé pour effectuer un post traitement. Les exemples d’interactions sont nombreux et l’avantage est que les ressources restent stockées dans la mémoire RAM du GPU sans avoir à passer par le goulot d’étranglement du bus PCI-Express.
CUDA est fourni avec un « émulateur » : le code devant s’exécuter sur le GPU est en fait exécuté sur le GPU. Les performances sont alors bien moindres, mais permettent de débugger l’application et de tester celle-ci lorsqu’on ne dispose pas de GPU compatible.
Mon stage de fin d’études au Centre National d’Etudes Spatiales portant sur les GPU, je vous propose une série d’articles traitant de ce thème.
Depuis ma première publication le 07 octobre, j’ai complété mon article, en lui rajoutant quelques précisions.
1.1 Historique
1.1.1 Le CPU
Les ordinateurs personnels et les stations de travail professionnel sont des systèmes autonomes dédiés à l’exécution d’applications logicielles. Au cœur de ces systèmes se trouve un microprocesseur central, ou CPU (Central Processing Unit), qui interprète les instructions et traite les données qui constituent ces applications. C’est lui qui a la charge de l’ensemble des calculs.
1.1.2 Evolution du CPU
Dans les années 80, de nouveaux besoins sont apparus nécessitant le traitement de données de plus en plus volumineuses, notamment dans les domaines de l’imagerie, de la vidéo ou du son, encore appelé multimédia. Les principales applications à l’origine de ces besoins sont logiciels professionnels de conception assistée par ordinateur (CAO) et les jeux vidéos.
Les applications multimédia s’appuient sur des algorithmes de nature très différente des applications dites « classiques » (bureautique par exemple). Alors que ces dernières traitent peu de données mais avec une logique de traitement complexe impliquant beaucoup d’interactions, de re-bouclages et de branchement conditionnels (si… alors…), les applications multimédia nécessite d’appliquer des algorithmes plus linéaires mais à de gros volumes de données. On parle de calcul vectoriel.
Les architectures des microprocesseurs se sont donc adaptées pour traiter aux mieux ces nouvelles problématiques en proposant des fonctionnalités dédiées aux applications multimédia, sous formes d’instructions spécifiques implantées au sein du processeur : MMX pour les processeurs Intel Pentium, 3D Now ! pour les processeurs AMD Opteron. Ces nouvelles instructions, qui permettent d’appliquer la même opération à plusieurs données à la fois, ont permis d’améliorer les performances des applications faisant appel à des algorithmes vectoriels, ce qui a contribué à leur succès.
Ces nouveaux microprocesseurs ont permis d’apporter des GFLOPS [1] aux ordinateurs de bureau ainsi que des centaines de GFLOPS aux serveurs. Ces nouvelles instructions et l’augmentation de performances associée ont permis d’enrichir la qualité des applications en élargissant les fonctionnalités offertes tout en améliorant les interfaces utilisateurs. Les utilisateurs, à leur tours, habitués à ces continuels progrès exigent toujours plus d’améliorations, aussi bien sur la perception des performances que sur les effets visuels, ce qui crée un cycle positif pour l’industrie informatique.
Pour répondre au besoin croissant de performance, la plupart des développeurs de logiciels ont compté sur les évolutions du matériel pour exécuter plus rapidement leurs programmes. Ainsi le même logiciel fonctionne plus rapidement sur chaque nouvelle génération de processeurs. Malheureusement cette course s’est ralentie depuis 2003 en raison de problèmes limitant l’augmentation du nombre d’instructions qu’un CPU peut exécuter par seconde (on parle de fréquence d’horloge). Ces problèmes sont principalement liés à la miniaturisation des composants (finesse de gravure) et à l’augmentation du nombre de transistors dans un microprocesseur induisant un dégagement de chaleur de plus en plus important ainsi que des interactions électromagnétiques, entrainant engendrant une augmentation de consommation électrique.
Pour palier aux problèmes de miniaturisation, plusieurs solutions ont été trouvées :
Combiner plusieurs processeurs en un seul, les tâches à réaliser sont alors réparties entre les unités de calcul qui le composent. C’est ce que l’on appelle le « multi-cœur ». Cette nouvelle technologie a eu un impact important sur le développement logiciel.
Adjoindre un microprocesseur spécifique dédié à l’accélération des applications les plus gourmandes, à savoir les applications multimédia. Cette approche a été possible de part la spécificité algorithmique (calcul vectoriel) de ces derniers. C’est ce qui deviendra le GPU (Graphic Process Unit).
[1]GFLOPS : se lit Giga Flops. Signification : milliards d’opérations à virgule flottante par seconde.
Il s’agit de l’unité de référence pour calculer la vitesse d’un processeur.
Qui dit congés dit forcément une tonne de vidéos à sauvegarder. Je possède 2 équipements qui font des vidéos HD un caméscope et un appareil photo.