jeudi 24 juillet
April | Agenda du libre | Framasoft | Léa-Linux | Lolix | JeSuisLibre | Eyrolles | LinuxMag | Veni, Vidi, Libri | InLibroVeritas | LinuxGraphic
Faire un don ! | | style | statistiques | contactez-nous | plan | lettre d'information
Accueil :: Dépêches :: Archives :: Proposer une dépêche :: Journaux :: Forums :: Entretiens :: Suivi :: RDF

Liens connexes

Dépêche modérée par

Dépêche éditée par

: Les GPU promis à une mort prochaine ?

Posté par Ontologia (page perso, ). Modéré le 20 mai 2008.
L'année écoulée a vu poindre les prémices d'une guerre technologique et commerciale qui va prendre une importance grandissante dans les années à venir : la guerre entre les GPU et les CPU.
De simples afficheurs de triangles texturés en 1995, les cartes graphiques munies de GPU sont devenues des sortes d'énormes DSP bientôt composées d'un milliard de transistors, délivrant des performances approchant bientôt le téraFLOPS. La répartition des tâches semblait jusqu'ici bien déterminée entre le CPU, dévolu aux tâches de gestion et de décision, et le GPU se chargeant du calcul brut, en particulier graphique. Mais les quelques acteurs du marché ont récemment amorcé des mouvements les préparant à dépasser leurs frontières traditionnelles.

> Lire la dépêche (66 commentaires, moyenne: 3,6).  

Le contexte technologique pesant sur le marché des CPU l'implique quelque peu : les concepteurs de CPU, Intel et AMD ne peuvent plus faire face aux problèmes thermiques qui frappent les CPU, atteignant une taille de gravure trop fine, laissant apparaître trop de fuites de courant. De ce fait, la fréquence n'augmentant plus, le nombre critique de transistors est atteint pour exécuter plus vite les instructions, la complexité grandissante des architectures permettant de faire des incantations vaudous sur le code pour l'exécuter dans le désordre et prévoir l'arrivage de données encore coincées en mémoire, les optimisations d'efficacité deviennent difficilement envisageables.

Les fondeurs en sont maintenant réduits à multiplier les cœurs sur leur processeurs : au début deux, maintenant quatre, et l'on doit imaginer seize, trente-deux cœurs pour les années à venir... Bien qu'il semble y avoir une limite théorique de finesse de gravure à 22 nm... Sans compter tous les problèmes d'interconnexions.

Ensuite, l'achat par AMD du fabriquant de GPU ATI, qui - bien que posant quelques problèmes de trésorerie - laisse imaginer des synergies entre processeurs et GPU, à cause du contexte technologique évoqué plus haut : rien n'empêche de mettre un GPU à la place d'un cœur.

L'offensive de NVidia sur les GP-GPU (General Purpose Graphical Processor Unit), proposant ni plus ni moins que d'utiliser leur processeur (près de 15 fois plus puissant en calcul brut) pour des centres de calculs et autres super-ordinateurs, avec leur technologie CUDA, a jeté un pavé dans la mare : c'est le marché du calcul haute performance, citadelle des CPU, qui est attaqué. Fourni avec une sorte de C adapté (le shading language), NVidia met tout en oeuvre pour séduire les développeurs et leur fournir tout un environnement d'exécution ad hoc.

Intel n'est pas en reste en annonçant pour 2009 la disponibilité de Larrabee proposant AVX. Il s'agit d'un SSE dopé aux stéroïdes, doté d'un registre vectoriel haute performance travaillant sur 256 bits, avec plein d'instructions très complexes permettant même d'envisager de faire le café, la sangria ou du chiffrement AES. Les 256 bits permettent de réaliser plusieurs calculs flottants sur 64 ou 32 bits en même temps, sans devoir paralléliser le code à outrance. D'après Intel, AVX permettrait de réaliser tous les calculs graphiques sur le CPU.

Les GPU "externes" impliquent de devoir gérer le transfert d'un monceau de données dans la mémoire de la carte, avec les problèmes de lenteur afférents. De plus, et beaucoup plus que les technologies Intel, un GPU est un assemblage de petits cœurs de calculs posés les uns à côté des autres, il faut donc produire un code extrêmement parallélisé, capable d'utiliser TOUS les "threads", sans quoi, on n'atteint que quelques pour cents de l'utilisation de la puissance disponible. Un avantage, tout de même : la bande passante (mémoire <-> GPU) interne à la carte est près de 10 fois supérieure à la bande passante (mémoire <-> CPU).

Ces deux technologies vont maintenant se lancer dans une guerre de mouvement afin de convaincre ceux qui feront la différence : les développeurs.

NVidia va tenter de convaincre ceux-ci de laisser le processeur s'occuper de tâches générales de gestion, ATI/AMD va sans doute proposer une voie médiane permettant de supprimer le besoin d'externaliser le GPU sur une carte en lui laissant une place sur le die du CPU, et Intel va proposer la même voie qu'AMD, mais avec une technologie à la logique totalement différente.

Dans les deux premiers cas, il faudra paralléliser massivement le code, avec le confort d'un langage C adapté (pour NVidia du moins). La logique Intel obligera-t-elle le programmeur à produire du code en assembleur, ou au moins en C avec des intrinsics ?

L'implémentation de ces technologies dans DirectX ainsi que dans OpenGL sera déterminante, car le marché du jeu restera la justification économique majeure de la bataille.

Les limites des processeurs actuels

Depuis l'avènement des microprocesseurs, l'amélioration de la finesse de gravure et de la fréquence de fonctionnement a permis d'augmenter exponentiellement les performances.
De par la fréquence bien évidemment, mais aussi grâce aux considérables IPC (Instruction Per Cycle) qu'ont connu les processeurs.
Pour mémoire, un mov de registre à registre sur un 8086 prenait au mieux 2 cycles, ce qui est énorme pour une opération de base. L'addition prenait au mieux 3 cycles, et un jump plus de 10 cycles.

Le nombre de cycles par instruction est maintenant très bas, pour descendre en-dessous du cycle, hormis la division : on en a un aperçu dans ce dossier pour le core duo.

La montée en fréquence étant bloquée, tout comme l'IPC qui ne peut guère progresser, on en tire la conclusion qu'on est obligé de faire du multicœur...

Les limites de la finesse de gravure à prévoir

La gravure devient trop difficile, avec des rayons de gravure presque 10 fois plus gros que la finesse de gravure à atteindre, il est envisagé de passer à l'Ultra Violet Extrême, plus fin, mais beaucoup plus (trop) énergétique. La limite théorique semble être de 5 nm. Pour information, le diamètre d'un atome de carbone est d'environ 0,1 nm.

Les shading-languages

Le shading language, est une sorte de C trafiqué dans lequel ont été ajoutés des types primitifs vectoriels.

Pour éviter de longs discours, je vous invite à musarder ce bout de code, calculant une classique fractale, qui vous donnera une idée des problèmes qui se posent.

Lorsqu'on utilise ce langage, il faut quasiment oublier la programmation par boucle et utiliser la mémoire partagée afin de bien répartir le calcul qui doit en toutes circonstances utiliser les milliers de threads disponibles sur le GPU. On doit donc concevoir et fragmenter son code avec une granularité minuscule : la majorité des transistors étant dévolus aux calculs, le processeur n'est pas capable de répartir les calculs entre threads.

Cette discussion est archivée, il n'est plus possible de laisser des commentaires.

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.

CPU, GPU, autres et langue

Posté par Axioplase Ashi (page perso, ) le 20/05/2008 à 01:34. (lien). Évalué à 3.

Hum, quid des FPGA qui vont se reconfigurer pour offrir la puissance de calcul (et ses outils) adaptés en fonction de la demande de logiciel ?
Bon, c'est pas trivial, mais ça se fait.

Et moi qui croyais que les CPUs étaient amenés à mourir vu qu'on déléguait tout sur le GPU, me voilà corrigé.


Sinon, chose qui me titille. L'auteur de cette dépèche a-t-il vécu au Québec ? C'est marrant d'essayer de deviner, car je trouve le français sur DLFP très uniforme et même plutôt "parisien". Mais dans cette dépèche, j'ai tiqué sur un mot...

--
J'aime la liberté.
J'aime BSD.

Limites de la finesse de gravure

Posté par Matthieu Lagouge (Jabber id, page perso, ) le 20/05/2008 à 03:24. (lien). Évalué à 10.

Méfiance avec les limites annoncées.
De mémoire, j'ai toujours entendu une limite annoncée, qui a finalement été franchie. Le problème de la limite existe... à conditions de se restreindre beaucoup dans l'approche de la solution!

Jusqu'à maintenant, on a joué sur les matériaux, les contraintes dans les matériaux, la nature du wafer (au lieu d'une galette de silicium, on utilise du Silicon-On-Insulator, une sorte de petite galette collée sur une grande, avec un bon isolant électrique entre les deux, ce qui améliore considérablement les choses en ce qui concerne les fuites de courant...), bientôt on modifiera un peu l'architecture des transistors, et finalement, les transistors MOS tels qu'on les connait cèderont la place à une nouvelle génération de composants, plus petits, moins consommateurs d'énergie, et plus rapides!

La course à la fréquence est en panne parce que nous approchons de la période charnière, mais de nombreuses pistes sont explorées pour identifier le meilleur successeur. Le problème est qu'on a près de 50 ans d'expérience avec le MOS, la migration va être douloureuse!

Et si rien ne disparaissait ?

Posté par Morgan Delahaye-Prat (Jabber id, page perso, ) le 20/05/2008 à 03:45. (lien). Évalué à 3.

Finalement la question n'est pas de savoir si les CPU ou les GPU s'écraseront les uns les autres, car, même si aujourd'hui cela reste majoritairement apprécié au travers du jeu vidéo, ces deux types d'unités de calculs répondent à des problématiques différentes (versatilité, parallèlisation massive, respect de l'instruction set, etc.), et répondront aux nouvelles qui vont apparaitre. Par exemple AMD qui en voulant réunir les deux dans un même coeur va peut être répondre à la problématique du rapport coût/performance et/ou performance/consommation de manière beaucoup plus décente qu'Intel et son Larabee qui cherche à créer un processeur ayant pour but d'aller chasser sur le terrain de son voisin.

Je ne pense pas que l'on verra, significativement, les uns voler le marché du calcul au profit des autres, je serais même tenter de penser que c'est le début d'un nouvel élargissement des choix qui seront offerts aux développeurs et utilisateurs, donc cela restera au moins autant fourni qu'aujourd'hui.

Le CPU, limité dans son évolution

Posté par loufoque () le 20/05/2008 à 04:47. (lien). Évalué à 4.

Je suppose que déjà le système de parallélisation automatique du x86 doit prendre une certaine place sur la puce...
Si on l'enlevait et qu'on passait à du VLIW on devrait gagner une place non négligeable. Mais bon, Intel a essayé (Itanium), et le marché n'a pas suivi.

Le problème finalement, c'est surtout le support logiciel. Les cartes graphiques sont essentiellement utilisées par les pilotes pour les jeux fournis par leurs constructeurs, donc ce n'est pas vraiment problématique si leur assembleur est tellement complexe que seul le constructeur sait l'exploiter. Ce qui compte, c'est la performance.
Surtout qu'il n'y a pas de problème de compatibilité, puisque ça passe par une couche d'abstraction (OpenGL, DirectX...)

Les CPUs font face à un tout autre problème. Il y a à la fois le problème de compatibilité et celui de la simplicité. Les divers OS, compilateurs, etc. doivent être à même d'exploiter le matériel sans dépenser des milliers en recherche dessus, et les utilisateurs veulent que le travail qu'ils ont effectués jusqu'à présent fonctionne.
Pour toutes ces raisons, malheureusement, on ne peut pas se débarasser de x86 si facilement pour le remplacer par un jeu d'instruction mieux fait et qui permettrait de gagner des performances non négligeables. C'est triste quand on voit que les GPU peuvent tout se permettre puisqu'ils n'ont pas à conserver la moindre usabilité ou compatibilité avec quiconque, ce qui leur permet d'évoluer et de s'améliorer beaucoup plus.

Idéalement, on pourrait se dire qu'un GPU devrait fusionner avec le CPU pour devenir son unité de calcul vectoriel. Sauf que pour les raisons citées ci-dessus, le GPU a bien plus de potentiel, donc ce n'est pas réellement envisageable.
Le seul moyen pour que ce le soit, ce serait que le constructeur maintienne une implémentation libre d'une abstraction. Un peu comme ce que fait nvidia avec CUDA, qui permet justement d'utiliser un GPU comme un CPU limité.

(Désolé si je me répète un peu, il est tard)

Architecture Cell

Posté par YvanLeTerrible (page perso, ) le 20/05/2008 à 09:21. (lien). Évalué à 7.

Article sympa mais dommage qu'on y parle pas de l'architecture du Cell qui est en quelque sorte l'architecture unifié que veut sortir AMD :
- 1 coeur PowerPC all purpose
- 8 DSPs dédié au traitement numérique

Quelques liens :
* Un lien parlant de l'architecture fusion : http://www.presence-pc.com/actualite/amd-phenom-fusion-27471(...)
* Page sur un driver OpenGL basé sur Galium3D pour le processeur Cell : http://www.tungstengraphics.com/wiki/index.php/OpenGL_for_Ce(...)

A l'avenir, les constructeurs délégueront les traitements aux différents coeurs de la machine en fonction de la nature de ces traitements.

GPU et DSP

Posté par rewind () le 20/05/2008 à 09:54. (lien). Évalué à 6.

> les cartes graphiques munies de GPU sont devenues des sortes d'énormes DSP

Attention dans la comparaison des GPU avec des DSP. Dans l'embarqué, on a coutume de dire que les GPU sont des DSP du pauvre, dans le sens où ils sont relativement bien moins puissant que leurs homologues embarqués. Un téléphone avec un processeur et un DSP tournant à quelques centaines de MHz est capable de décoder de la vidéo HD en temps réel. On en est très loin avec les CPU et GPU desktop.

Donc le terme "énorme DSP" me semble un peu exagéré, j'aurais plutôt dit "DSP bas de gamme".

Interface logicielle

Posté par GPL (Jabber id, ) le 20/05/2008 à 10:45. (lien). Évalué à 3.

Les constructeurs de cartes 3D peuvent partir dans des directions différentes, ce qui sera important pour les codeurs sera d'avoir une interface unifiée pour programmer les GPUs et en tirer le meilleur.
Si vous suivez le développement de la nouvelle pile graphique de Linux, on commence à avoir des conflits entre différentes interfaces (ex: GEM vs TTM, Gallium3D trop "windaube"...). En effet, ce qui risque d'arriver est d'avoir des types de GPUs qui devront chacun être programmés de manière réellement différente et une interface de programmation unifiée pénaliserait certaines architectures au détriment d'autres car certaines seraient "mieux" adaptées à "l'interface".
Bref, en théorie cela ne devrait pas arriver car les constructeurs sont censés se mettre d'accord sur opengl3. Mais bon...
Prenons l'exemple de GEM et TTM, et bien ces interfaces définissent comment intéragir avec la ram de la carte graphique. Grosso modo, les GPUs semblent vouloir se mettre à gérer leur RAM comme le font nos CPUs (pagination, protection etc...). Or un logicie l(moteur) 3D qui gère vraiment beaucoup de textures, pour être performant devra être proche de la gestion de la ram vidéo (cf le moteur Id5 qui veut "streamer" des textures géantes) et des interfaces faisant abstraction du modèle de gestion mémoire seront pénalisantes.

et la virtualisation ?

Posté par Nicolas Parpandet (page perso, ) le 20/05/2008 à 13:53. (lien). Évalué à 1.

Je pense que la voie prise par Transmeta à l'époque càd la virtualisation des instructions x86 est aussi envisageable avec l'augmentation de microcode dans les processeurs, et l'on pourra au choix répartir la puissance de calcul en instruction orientées CPU ou GPU
et se débarrasser de la dépendance à x86...,

mais ce qui est clair après la disparition des cartes filles :

* réseau
* controleur
* carte son

et la course à l'intégration, la prochaine cible est clairement la carte vidéo, déjà intégrée sur la Carte Mère pour le bas de gamme et on commence à voir des GPU de qualité directement intégrés sur la CM.

AVX = Vectoriel

Posté par Ontologia (page perso, ) le 20/05/2008 à 15:39. (lien). Évalué à 3.

Nicolas Boulay me l'a souflé un peu après et je ne l'ai donc pas mis dans la news : l'intérêt d'AVX est de proposer un jeu d'instructions certes complexe mais vectoriel :
Dans des registres 256 bits on peut caser 4 flottants 64 bits, et réaliser des opération vectorielles dessus, du genre R = r1*r2 + r3*r4.
Il ya tout ce qu'il faut pour implémenter une bonne librairie vectorielle, matricielle à coup d'intrinsics.

Evidemment c'est quasiment pas parallelisable, et quand ça l'est, c'est le processeur qui va le détecter, suite aux incantations vaudous sur le code.

Conclusion : ça obligera à tâter de l'assembleur, car je vois mal le compilateur réussir à gérer ça tout seul, mis à part des cas très simple, avec des techniques comme celle de l'autovectorisation de GCC, et ça obligera surtout à penser son code de manière à aider le processeur à parraléliser tout seul, en mettant le moins possible de dépendances entre les opérations successives.
La routine quoi.

Je me demande si ça serait pas intelligent de reprendre le shading language, qui est très orienté vectoriel, et de lui faire générer de l'AVX. Ce serait très intelligent : un compilateur (avec une grosse grammaire) comme C arriverait plus facilement à mapper les calculs sur l'ensemble des opérations assembleurs proposées...

GPU vs CPU

Posté par lfmarante (page perso, ) le 20/05/2008 à 16:36. (lien). Évalué à 1.

http://www.tomshardware.com/reviews/cpu-gpu-upgrade,1928.htm(...)

Article intéressant.

Bref rien de nouveau sous les tropics, changer sa carte graphique est toujours plus avantageux en termes de puissances brute, sans parler du coût, on change plus souvent les chaussettes aux procos qu'on ne change le port graphique (ou alors c'est juste des modifs minimes, des histoires de bande passante tout ça)

Ce ci dit avec une grosse carte il faut quand même un processeur assez véloce afin que la CG développe tout son potentiel.
Généralement une assez bonne CG avec un proc moyen de gamme, ou le meilleur rapport perf/prix et vous pouvez jouer convenablement.

[+] Les développeurs font la différence ?

Posté par Mes Zigues () le 20/05/2008 à 21:04. (lien). Évalué à -1.

Je pense que ce sont Microsoft et Apple font la décision.

Revenir en haut de page

Run by Team LinuxFr.org

Cette page a été générée par Templeet en 0.2099s (dont 0.0287 de SQL).
Cette page est peut-être conforme xhtml 1.0.
Information sur le site.