Archives de catĂ©gorie : GPU

Freemake Video Converter : Convertir des vidéos gratuitement, rapidement et simplement en masse avec CUDA.

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.

Continuer la lecture de Freemake Video Converter : Convertir des vidéos gratuitement, rapidement et simplement en masse avec CUDA.

CUDA

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
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.

PrĂ©sentation d’un GPU

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.