Performances
Malgré cela, nous avons quand même choisi de mesurer le temps de calcul pour vérifier si, malgré notre implémentation naïve, il y avait un intérêt à utiliser CUDA ou si le GPU ne s’apprivoisait qu’après énormément de pratique. La machine de test est notre machine de développement : un ordinateur portable équipé d’un Core 2 Duo T5450 et d’une GeForce 8600M GT le tout tournant sous Vista. C’est bien loin d’une machine de guerre mais les résultats demeurent intéressants car il s’agit d’un cas assez peu favorable pour le GPU : il est bien pratique pour NVIDIA de montrer des accélérations conséquentes sur des systèmes équipés de GPU monstrueux et disposant d’une bande passante énorme, mais en pratique beaucoup des 70 millions de GPU CUDA équipant des PC actuellement sont nettement moins puissants que ça, notre test nous place donc dans un cas pratique.
Les résultats que nous avons obtenus sont les suivants pour le traitement d’une image de 2048x2048 :
- CPU 1 thread : 1419 ms
- CPU 2 threads : 749 ms
- CPU 4 threads : 593 ms
- GPU (8600M GT) blocs de 256 pixels : 109 ms
- GPU (8600M GT) blocs de 128 pixels : 94 ms
- GPU (8800 GTX) blocs de 128 pixels / 256 pixels : 31 ms
Plusieurs observations sont à extraire de ces résultats : tout d’abord vous noterez que nous avons été médisants car nous avons malgré tout modifié l’implémentation initiale du CPU en la threadant. Comme nous l’avons dit le code est idéal pour ce cas de figure, il suffit de décomposer l’image initiale en autant de zones que de threads. Vous noterez que l’on obtient une accélération quasiment linéaire en passant de 1 à 2 threads sur notre CPU dual core ce qui traduit bien la nature fortement parallèle de ce programme de test. De façon assez inexpliquée la version 4 threads se révèle plus rapide alors que nous nous attendions au mieux à ne voir aucune différence sur notre processeur voire même de façon plus logique à une légère perte d’efficacité du fait du surcout engendré par la création des threads supplémentaires. Comment expliquer ce résultat ? Difficile à dire, peut être que l’ordonnanceur de threads de Windows n’est pas totalement innocent là-dessous, en tout cas ce résultat était reproductible. Sur une texture aux dimensions plus réduites (512x512) le gain obtenu en threadant est beaucoup moins sensible (35% environ au lieu de 100%) et le comportement de la version 4 threads est plus logique vu qu’il n’y a aucun gain par rapport à la version 2 threads. Le GPU reste le plus rapide mais de façon moins sensible (la 8600M GT est 3 fois plus rapide que la version 2 threads).
Deuxième point remarquable l’implémentation GPU la plus lente se révèle déjà près de 6 fois plus rapide que la version CPU la plus performante. Pour un premier programme et une version triviale de l’algorithme tout cela est très encourageant. Vous remarquerez aussi que l’on obtient des résultats sensiblement meilleurs en utilisant des blocs plus petits alors qu’intuitivement on pourrait penser l’inverse. L’explication est simple : notre programme utilise 14 registres par threads. Avec des blocs de 256 threads il aurait besoin de 3584 registres par bloc et, pour saturer un multiprocesseur il faut 768 threads comme nous l’avons vu, dans notre cas 3 blocs soit : 10572 registres.
Pas de chance, un multiprocesseur ne dispose que de 8192 registres. Il ne peut donc conserver que deux blocs actifs. A l’inverse avec des blocs de 128 pixels on a besoin de 1792 registres par blocs, 8192 divisés par 1792 et arrondi à l’entier inférieur nous donne 4 blocs en cours de traitement. En pratique le nombre de threads est le même (512 par multiprocesseur alors que théoriquement il en faut 768 pour le saturer) mais le fait d’avoir plus de blocs donne une flexibilité supplémentaire au GPU lors des accès mémoire : lorsqu’une opération ayant une longue latence est exécutée, il peut lancer l’exécution des instructions sur un autre bloc le temps que les résultats soient disponibles. 4 blocs permettent sans doute de mieux masquer cette latence, d’autant que notre programme effectue plusieurs accès mémoire.
- Business,
- Carte graphique,
- Developpement,
- CUDA ,
- CPU ,
- GPU
ce qui permettrait effectivement de faire bondir le nombre d'applications se servant du GPU, ça serait un SDK qui prenne en charge les NVidia ET les ATI !
Quelqu'un pourrait m'expliquer ce qu'on veut dire par "parallèle"??
plusieurs tâche simultannée
Vikk > Lire par exemple http://www.presence-pc.com/tests/D [...] ium-D-300/ . Il s'agit de l'exécution concurrente (simultannée) de plusieurs tâches d'une application ou plusieurs applications par le processeur, plutôt que de ne disposer que d'une seule unité d'exécution.
Après les CPU et les GPU, on va voir apparaitre les APU grâce à Creative
oui ça existe depuis 30 ans les DSP, n'importe quel multieffet de gratteux en intègre un...
Après les CPU et les GPU, on va voir apparaitre les APU grâce à Creative![[:matleflou]](http://img.infos-du-net.com/forum/images/perso/matleflou.gif)
![[:vendredi]](http://img.infos-du-net.com/forum/images/perso/vendredi.gif)
à signaler qu'il existe aussi Brook+ chez AMD qui fait exactement la même chose que cuda, mais dont on parle moins, pourtant il est utilisé dans folding@home...
oui ça existe depuis 30 ans les DSP, n'importe quel multieffet de gratteux en intègre un...
NVIDIA veut qu'on utilise ses puces graphiques pour faire autre chose que de la 3D, hein.
D'où la "blague" (pffff) de l'APU pour faire autre chose que du son.
C'est dingue, quand on doit expliquer un trait d'humour ça perd tout son charme
Fedy s'est encore déchiré
Très bon article, merci.
Maintenant hypothèse: Si CUDA s'impose en tant que tel sur le marché, est ce que ça veut dire que AMD doit racheter les licences pour cette technologies et l'intégré à leur carte? Et déjà est ce que c'est possible???
En fait de ce que je comprend c'est que les cartes graphiques joueront un plus grand rôle dans nos applications quotidienne (travail, application etc...) Donc si CUDA s'impose j'imagine que les intégrateurs préférerons se système et privilégierons donc des cartes Nvidia. D'ailleurs on le voie bien avec Apple qui commence à si intéressé de prêt.
Comme dis se n'est qu'une hypothèse mais sa pourrait être aussi AMD, intel, ou encore comme dis dans l'article Microsoft...
Si c'est microsoft, c'est l'horreur ! Comme pour le directX, cela veut dire rien pour Apple, Linux et les *BSD !
Je crois que Nvidia devrait s'entendre avec AMD pour rendre leur api compatible et éviter une guerre où les développeurs seraient perdant et MS gagnant.
Fedy, bravo pour cet article que je vais lire en détail dès que j'en ai le temps !
+1
excellent article , qui montre de belles perspectives dans le futur
et qui m'a fait apprendre pas mal sur l'architecture des gpu
bravo !!
et pour amd,j'etais meme pas sur qu'ils aient deja sorti un tel truc,c'est beaucoup moins mediatisé que cuda,peut etre parce que c'est moins efficace ?
Merci pour les commentaires sur l'article ça fait plaisir
Concernant une implémentation par AMD de CUDA : outre les problèmes "juridiques" il y aurait quand même de sacrés défis techniques pour les ingénieurs d'AMD. CUDA a beau être de haut niveau, l'API donne beaucoup de détails sur le fonctionnement du GPU or les implémentations d'AMD et de NVIDIA sont extrêmement différentes. Par exemple un des problèmes serait la Shared Memory. AMD ne dispose pas d'une mémoire similaire sur ses puces, qui reposent plutôt sur des caches plus importants. Reproduire le comportement exactement de la même façon que NVIDIA pour que les implémentations soient compatibles me semblerait vraiment compliqué et même s'ils y parvenaient ça serait sans doute pas la meilleure façon de tirer parti de leurs GPU.
C'est d'ailleurs un souci aussi pour NVIDIA à l'avenir, je ne l'ai pas soulevé dans l'article mais CUDA force NVIDIA à ne pas trop s'éloigner de l'architecture introduite par le G80. Ils peuvent changer certaines choses comme le nombre de registres, le nombre de warps par SM ou ajouter des instructions (ils l'ont déjà fait sur le G84/G92), mais s'ils ne veulent pas briser la compatibilité des applications déjà écrites ils doivent respecter un certain schéma. Alors pour le moment ce n'est pas gênant car cette architecture est très efficace mais à terme est ce que ça ne sera pas pénalisant ?
merci pour la réponse^^,je me demandais également :
je lis sur certains sites que la puissance theorique du RV770 serait superieure à celle des GTX2x0 , donc meme si ils sont moins efficaces dans les jeux du fait de leur architecture, ils devraient être plus efficaces en GPGPU ?
et si le CUDA l'emporte, ne serait-il pas possible que ATI/AMD et µsoft prennent part au projet, financièrement, pour améliorer le système ? et qu'il soit portable sur tous les matériels
ça serait certainement possible : le mieux serait que directx le gère nativement comme ça la couche d'abstraction serait déjà faite
Et pour amd,j'etais meme pas sur qu'ils aient deja sorti un tel truc,c'est beaucoup moins mediatisé que cuda,peut etre parce que c'est moins efficace ?
Chez ATI, l'équivalant de CUDA, c'est CTM.
ça serait certainement possible : le mieux serait que directx le gère nativement comme ça la couche d'abstraction serait déjà faite
le mieux searit que opengl le gère directement
merci pour la réponse^^,je me demandais également :
je lis sur certains sites que la puissance theorique du RV770 serait superieure à celle des GTX2x0 , donc meme si ils sont moins efficaces dans les jeux du fait de leur architecture, ils devraient être plus efficaces en GPGPU ?
On va attendre d'en savoir plus sur les cartes avant de faire ce type de jugements
De toute façon la performance de crête n'est qu'un facteur pour différencier deux architectures, et c'est rarement le plus pertinent. L'archiecture AMD repose sur des unités VLIW, qui demandent plus d'effort au niveau du compilateur pour en tirer parti. Il y a aussi comme on l'a vu des données comme la présence de shared memory qui peut jouer énormément sur les performances dans certains algos. Bref on ne peut pas juger comme ça sur des specs non officieles. Mais en tout cas AMD prend au sérieux le GPGPU aussi.
Chez ATI, l'équivalant de CUDA, c'est CTM.
Pas vraiment... CTM est beaucoup plus bas niveau et c'est pas tout à fait la même chose. Au dessus de CTM tu as CAL (Compute Abstraction Layer) qui encapsule déjà les appels CTM dans quelque chose de moins spécifique à une famille de GPU donnée. Et enfin au niveau du programmeur "lambda" tu trouves Brook+ pour créer tes kernel et les gérer à plus haut niveau. L'ensemble de tout ça et de quelques bibliothèques forment le Stream SDK qui se rapproche plus de CUDA.
le mieux searit que opengl le gère directement
Que Khronos nous sorte déjà OpenGL 3
Et puis GL = Graphics Library donc ça n'aurait pas sa place là mais par contre Khronos pourrais proposer un OpenCL : Open Compute Library ou OpenSL Open Stream Library
Que Khronos nous sorte déjà OpenGL 3
Et puis GL = Graphics Library donc ça n'aurait pas sa place là mais par contre Khronos pourrais proposer un OpenCL : Open Compute Library ou OpenSL Open Stream Library
C'était plus lié à la remarquer sur directX qu'a une réelle demande. Je suis d'accord qu'il faudrait surtotu une autre lib haut niveau, opengl ne faisant pas la même chose.
Mince j'arrive trop tard : http://www.apple.com/pr/library/20 [...] opard.html
Apple a déjà proposé OpenCL : Open Computing Language
ATi = CTM -> CAL -> ACML + APL + Cobra + Brook+
Selon les rumeurs actuelles:
8800GTX = 518 GFLOPs
9800GTX = 648 GFLOPs
GTX 260 = 708 GFLOPs
GTX 280 = 933 GFLOPs
HD 4850 = 1000 GFLOPs
HD 4870 = 1200 GFLOPS
4870-X2 = 2400 GFLOPS
Donc, nVidia a un peu d'avance avec son CUDA, mais il n'a clairement pas la puissance de calcul des GPU d'ATi.
CUDA va être une véritable révolution pour les gros calculs massifs pouvant être bien parallélisés, comme:
- le rendu d'images 3D (avec Raytracing, Réfraction, Global Illumination et j'en passe, pour l'instant tout cela est calculé par le CPU, et ça prend booooooocoup de temps !)
- la retouche d'images en haute résolution (Adobe a déjà annoncé que le prochain Photoshop sera vitaminé à la sauce Cuda)
- l'édition de vidéos: imaginez jouer avec AfterEffect en empilant des effets complexes, et pouvoir admirer le résultat en temps réel :-)
- et surtout l'encodage de vidéos, HD ou résolution standard... Bientôt, encoder un film en Divx ne prendra plus que 5 min :-)...
Article de grande qualité que j'ai suivi avec intérêt alors que je suis totalement profane (oui un peu largué parfois, c'est normal). :-D
Bravo à son auteur et merci!
Une question me vient toutefois à l'esprit: nVidia arrive avec un GPU "x2", AMD/ATI ne va pas tarder non plus. Arrive-t-on aussi à un virage dans le monde du GPU, comme il en a été question pour les CPU's?
Très bon article, merci.
Juste une remarque ... le titre est purement absurde.
En fait le GPU permet d'accelerer l'execution des parties les plus faciles a paralleliser dans un programme et encore seulement dans le cas ou aucune dependance de donnees existe (data parallel ou doall). Par contre il restera toujours une partie sequentielle en raison de laquelle, d'apres la loi d'Amdahl, on aura un speedup borne. Sans un CPU qui ait un bon ILP et un branch predictor raisonable ca marche simplement pas ...
Le titre ne fait que poser une question qui a d'ailleurs été évoquée par le marketing de nVidia directement.
Le nombre de bloc actif ne doit pas dépasser 8, est-ce vrai pour toutes les cartes? Je dispose d'un 450 GTS avec 4 multiprocesseurs. Comment se présente l'architecture de ma carte ? Combien de bloc et de thread par multiprocesseur ? Je sais qu'on est limité à 1024 threads par bloc et 65535 blocs par dimension dans une grid lorsqu'on veut coder pour le GPU mais comment se présente cette architecture par multiprocesseur ? Comment peut on connaitre le nombre de warp actif pour une carte ?