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.
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.
Aller plus loin
- L'annonce de Larrabee par Intel (13 clics)
- Le guide de référence d'AVX (5 clics)
- Une description du fonctionnement des derniers GPU NVidia (14 clics)
- Un tutoriel expliquant comment optimiser avec SSE (10 clics)
- Une fractale de mandelbrot en shading language (6 clics)
# CPU, GPU, autres et langue
Posté par Axioplase ıɥs∀ (site web personnel) . Évalué à 3.
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...
[^] # Re: CPU, GPU, autres et langue
Posté par Ontologia (site web personnel) . Évalué à 2.
Quel mot ?
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: CPU, GPU, autres et langue
Posté par Graveen . Évalué à 1.
[^] # Re: CPU, GPU, autres et langue
Posté par Perthmâd (site web personnel) . Évalué à 3.
M'enfin, vive les jargons et le droit à jaspiner l'argomuche dans son idiolecte propre !
[^] # Re: CPU, GPU, autres et langue
Posté par NickNolte . Évalué à 2.
M'enfin, vive les jargons et le droit à jaspiner l'argomuche dans son idiolecte propre !Je préfère 10³ fois cela au franglais!
J'ai encore vu récemment un gugus écrire "shutdowner" à quelques octects de là! Faut y aller, pour sortir une telle mixture.
[^] # Re: CPU, GPU, autres et langue
Posté par Nicolas Boulay (site web personnel) . Évalué à 6.
Bon, c'est pas trivial, mais ça se fait.
Les FPGA ont de gammes de fréquences autour de 100 Mhz et des prix autour de 1000€ (pour les plus gros vraiment capable de quelques choses) et il chauffe beaucoup.
Ce n'est simplement pas compétitif.
"La première sécurité est la liberté"
# Limites de la finesse de gravure
Posté par Maclag . Évalué à 10.
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!
[^] # Re: Limites de la finesse de gravure
Posté par Neije . Évalué à 4.
Ce n'est pas parce que les choses sont difficiles que nous n'osons pas. C'est parce que nous n'osons pas qu'elles sont difficiles. - Sénéque
[^] # Re: Limites de la finesse de gravure
Posté par Ontologia (site web personnel) . Évalué à 2.
Je pense aussi qu'il vont y arriver, mais moins vite, et moins facilement.
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: Limites de la finesse de gravure
Posté par Nicolas Boulay (site web personnel) . Évalué à 9.
Il y a donc une marge énorme sur la manière de dessiner les transistors.
"La première sécurité est la liberté"
[^] # Re: Limites de la finesse de gravure
Posté par Amine Mokhtari . Évalué à 3.
et pour cause, des travaux de recherche sont menés afin de réaliser des nano-transistors à la chaine (On sait les faires en petite contité mais il ya des problème lors du passage à l'echelle. on ne controle pas totalement le processus).
Voilà un liens qui en dit plus: Les nanotransistors, être ou ne pas être en CMOS sur silicium ? (http://www.cea.fr/var/plain/storage/original/application/223(...)
mais sa avance, y'a qu'à voir les progrès faits ces derniers temps :IBM fait un nouveau pas vers la production de nanotransistors (http://www.vnunet.fr/fr/news/2008/03/11/ibm_fait_un_nouveau_(...)
# Et si rien ne disparaissait ?
Posté par Badeu . Évalué à 3.
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.
[^] # Re: Et si rien ne disparaissait ?
Posté par B16F4RV4RD1N . Évalué à 8.
Sinon bravo pour ce bel article Ontologia, écrit clairement mais de façon précise !
Only wimps use tape backup: real men just upload their important stuff on megaupload, and let the rest of the world ~~mirror~~ link to it
[^] # Re: Et si rien ne disparaissait ?
Posté par dinomasque . Évalué à 3.
Il y a une dizaine d'années les jeux vidéos proposaient (souvent via des patches) un binaire pour chaque modèle de puce accélératrice 3D (jusqu'au jour ou Microsoft a proposé Direct3D pour rendre tous les jeux compatibles avec toutes les cartes 3D).
BeOS le faisait il y a 20 ans !
[^] # Re: Et si rien ne disparaissait ?
Posté par ragoutoutou . Évalué à 10.
[^] # Re: Et si rien ne disparaissait ?
Posté par Zenitram (site web personnel) . Évalué à 2.
Hum... On refait l'histoire... Et toujours pour dénigrer MS quand on peut, même quand ce n'est pas vrai.
Direct3D a... Comblé un trou. Il n'a pas concurrencé OpenGL, du moins dans ses premières versions
En effet, OpenGL était hors-course par rapport au besoin, du fait que OpenGL imposait que tout soit fait en hard, et que les GPU (pour jouer, pas cher!) de l'époque n'était pas capables d'être compatible avec tout OpenGL.
Donc bien que OpenGL proposait ça avant Direct3D, OpenGL ne pouvait être un prétendant pour répondre au besoin faute de modularité.
Direct3D a eu le succès qu'il a eu pas par le monopole de MS, mais parce qu'il y avait un manque : une API de programmation de GPU pour GPU pas cher!
Ensuite, pas de portage sur un autre OS juste parce que ce n'est pas son business.
Si OpenGL (ou un autre) avait proposé une API permettant de faire des choses en soft quand le GPU n'était pas capable de le faire, l'histoire aurait peut-être changé... Mais je me répète, MS a juste profité d'un manque de ses concurrents, il n'a pas essayé de contrer OpenGL puisqu'il était hors course pour ce sujet de lui-même. Tout ce qu'on peut dire c'est que quand les GPU ont été suffisants puissants pour être compatible OpenGL, MS a profité de sa position gagnée précédemment pour continuer sur sa lancé plutôt que de se dire "OK, Maintenant les bases obligatoires de Direct3D sont celles d'OpenGL, on passe sur OpenGL".
Il faut juste se dire que si un organisme de normalisation multi-OS avait fait une API qui réponde au besoin des constructeurs de GPU de l'époque, on n'en serait peut-être pas la... Ben oui, il ne faut pas en vouloir à MS qui ne fait que profiter des failles, mais aux autres qui n'ont pas su proposer un truc au bon moment...
[^] # Re: Et si rien ne disparaissait ?
Posté par reno . Évalué à 9.
*N'importe quoi*: Mesa une implémentation purement logicielle d'OpenGL existe depuis 1993, Microsoft a acheté l'entreprise qui a fait Direct3D en 1995.
OpenGL est une API pour faire des rendus 2D/3D, c'est l'API et le résultat qui sont spécifiés mais ou est fait le rendu, ça ne l'est pas!
Ton API multi-OS c'est OpenGL, je suis d'accord avec ragoutoutou que Direct3D est un moyen pour Microsoft de lier les jeux avec leur propre API pour diminuer la concurrence (Apple avait fait la même chose, sans succès): il a fallut attendre DirectX 9 pour que J Carmack considère que l'API de Direct3D soit aussi bonne que celle d'OpenGL..
[^] # Re: Et si rien ne disparaissait ?
Posté par Zenitram (site web personnel) . Évalué à 1.
Peut-être. Et?
Ce qui manquait était une implémentation moitié soft, moitié hard (fait par le GPU ponc!).
J'ai toujours vu des drivers OpenGL pour des cartes qui pouvaient tout faire.
Je n'ai jamais vu de drivers OpenGL pour des cartes qui ne pouvaient pas tout faire.
Et dans tous les cas, il faut se demander pourquoi les programmeurs ont choisi Direct3D à la place d'OpenGL pour programmer : On pouvait très bien programmer en DirectX pour tout sauf la 3D et programmer la 3D en OpenGL, si Direct3D s'est imposé, c'est peut-être parce qu'il avait un avantage non? Le poids de MS? Si OpenGL était présent, poids ou pas, le programmeur avait le choix... Donc il devait manquer quelque chose à OpenGL...
[^] # Re: Et si rien ne disparaissait ?
Posté par dinomasque . Évalué à 5.
BeOS le faisait il y a 20 ans !
[^] # Re: Et si rien ne disparaissait ?
Posté par reno . Évalué à 5.
Les fabriquants de cartes graphiques ont tout intérêt à avoir des *très bonnes* relations avec MS, ce qui lui a permis de pousser les driver Direct3D.
Pour ce qui est des programmeur de jeux:
- MS a investi dans certains jeux, réaliser bien entendu avec Direct3D
- pour les autres, je pense que c'est la certification des driver Direct3D par Microsoft qui a penché beaucoup dans la balance.
Bref, ce qu'il manquait à OpenGL, c'est l'appui de Microsoft et c'est tout.. Pas la peine de chercher des points techniques fantômes pour lequel Direct3D l'aurait emporté..
Et la raison pour laquelle MS a poussé Direct3D et pas OpenGL, c'est tout simplement pour verrouiller les jeux, c'est tout simple.
[^] # Re: Et si rien ne disparaissait ?
Posté par tarlack . Évalué à 2.
et vivement que les cartes physiques programmables arrivent, ca fera un troisieme type d'unité de calcul efficace pour une autre classe de problemes, ca sera bien en conjonction avec ce qu'on a deja !
[^] # Re: Et si rien ne disparaissait ?
Posté par Julien . Évalué à 4.
Il me semblerait logique que les deux se prêtent au parallélisme massif ... J'ai même cru entendre qu'elles arrivaient trop tard (les cartes physiques) et qu'avec les cartes graphiques programmables, leur valeur ajoutée était ridicule.
[^] # Re: Et si rien ne disparaissait ?
Posté par Jean Roc Morreale . Évalué à 4.
# Le CPU, limité dans son évolution
Posté par loufoque . Évalué à 4.
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)
[^] # Re: Le CPU, limité dans son évolution
Posté par reno . Évalué à 2.
Bof, pas tant que ça maintenant (en pourcentage), c'est pour ça que les x86 ont finis par rattrapper les RISCs..
Je pense que les scientifiques vont être très, très satisfait d'avoir l'AVX, les calculs scientifiques se faisant sur 64bit de précision en général.
>Si on l'enlevait et qu'on passait à du VLIW on devrait gagner une place non négligeable
Pour les VLIW, il reste le probleme du compilateur, a part pour du code tres regulier un VLIW n'est pas exploité au mieux donc ce n'est pas du tout évident que le VLIW soit la bonne voie: le POWER est tout à fait compétitif par rapport a l'Itanium.
[^] # Re: Le CPU, limité dans son évolution
Posté par briaeros007 . Évalué à 2.
En réalité (en ce qui concerne AMD en tout cas) les processeurs X86 SONT des RISC, avec une couche de ré écriture du code au mileu.
[^] # Re: Le CPU, limité dans son évolution
Posté par Nicolas Boulay (site web personnel) . Évalué à 5.
Au début, le RISC correspondait à une architecture load/store (load/store clairement séparer des opérations ALU, avec donc moins de mode d'adressage et un pipeline plus court). En général, le RISC a une taille d'instruction fixe (32 bits en général) pour simplifier le décodage et le pipeline.
Donc le x86 est du vrai CISC bien complexe et ne sera jamais du RISC quelques soit la micro architecture en dessous.
D'ailleurs, ARM avec son thumb2 est entrain de devenir de plus en plus CISC avec des instructions de tailles 16 ou 32 bits.
"La première sécurité est la liberté"
[^] # Re: Le CPU, limité dans son évolution
Posté par briaeros007 . Évalué à 3.
Mais les processeurs AMD x86 reposent sur un coeur RISC. C'est tout ce que je voulais dire.
[^] # Re: Le CPU, limité dans son évolution
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
Je sais que les x86 transforme les instructions en µinstructions voire en suite de µinstructions mais on est plus proche du vliw que du risc. Pour le pentium 4, on parlait de 118 bits ce qui réduisait de beaucoup le cache L1 instructions.
"La première sécurité est la liberté"
[^] # Re: Le CPU, limité dans son évolution
Posté par Hank Lords . Évalué à 1.
Ah ben oui mais vu qu'on a besoin de moins d'instructions pour effectuer une tache ca compense :) (En réalité je n'en sais rien et je pense que non, il y'a probablement des papiers tres pointus sur ce sujet quelque part sur l'ieee).
[^] # Re: Le CPU, limité dans son évolution
Posté par auve . Évalué à 2.
Ce ne serait pas plutôt un problème de compilateurs, au niveau de l'ILP que ces derniers arrivent à extraire, ou pire, de l'ILP intrinsèquement présent dans la plupart des programmes (HPC exclu...) ?
[^] # Re: Le CPU, limité dans son évolution
Posté par Juke (site web personnel) . Évalué à 10.
[^] # Re: Le CPU, limité dans son évolution
Posté par BAud (site web personnel) . Évalué à 9.
[^] # Re: Le CPU, limité dans son évolution
Posté par Julien . Évalué à 5.
Je m'explique : le OoO revient à transformer l'assembleur du binaire en un code plus finement découpé : le microcode. Ce microcode est stocké dans un "pool" dans le processeur et chaque instruction est exécutée dans le désordre (out of order) dès que ses dépendances sont satisfaites.
Une partie du processeur est donc destinée à la gestion de ce mécanisme : traduction, gestion des dépendances, etc ...
Dans le cas du bytecode, on ajoute une étape de transformation. Le bytecode est soit interprété, soit transformé en code assembleur pendant l'exécution (JIT). Il me semble que cette étape ressemble fortement à ce qui se fait pour le OoO, mais à une échelle plus large.
On pourrait donc imaginer une architecture où un coeur est destiné à la gestion de ce bytecode (exécution de la VM) et où les autres coeurs exécutent le résultat. Cette solution permettrait de tirer partie de coeurs hétérogènes : 1CPU OoO classique pour l'interprétation, un GPU pour ce qui se parallélise facilement, un VLIW pour ce qui a été JITé, un FPGA pour les tâches très répétitives, etc ...
Enfin, je divague ...
[^] # Re: Le CPU, limité dans son évolution
Posté par chimay . Évalué à 1.
* compatibilité x86 (ce qui permettrait de s'en affranchir dans les autres coeurs)
* opérations graphiques
* ...
enfin, je n'y connais pas grand chose :)
[^] # Re: Le CPU, limité dans son évolution
Posté par chimay . Évalué à 1.
* traitement vectoriel
etc
on peut tout imaginer
# Architecture Cell
Posté par YvanLeTerrible . Évalué à 7.
- 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.
[^] # Re: Architecture Cell
Posté par patrick_g (site web personnel) . Évalué à 10.
[^] # Re: Architecture Cell
Posté par briaeros007 . Évalué à 6.
[^] # Re: Architecture Cell
Posté par nimch . Évalué à 4.
# GPU et DSP
Posté par rewind (Mastodon) . Évalué à 6.
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".
[^] # Re: GPU et DSP
Posté par krumtrash . Évalué à 1.
Ca m'étonnerais quelque peu, qu'un DSP de mobile consommant quelques milliwatts soit "plus mieux" que les monstres de Nvidia et ATI en terme de patate brut.
Et il na faut pas oublier les multiples couches (OS/API/driver) qui doivent être bien minimisé sur mobile.
[^] # Re: GPU et DSP
Posté par Stibb . Évalué à 3.
Surtout dans les STB de salon où la petite puce a un "petit" coeur DSP qui peut décoder 2 flux 1080p, sans chauffer (pas de ventillateur). Seul les dernières cartes graphiques peuvent le faire, et encore, si elles ont les accélérateurs hardware de décodage H.264 par exemple.
Accélérateurs qui sont biensûr présent dans le DSP de la STB, évidement...
[^] # Re: GPU et DSP
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Si on ne regarde pas les shaders qui pourrait être des x86 avec des instructions en plus, il reste le pipeline de coloration des triangles qui lui demande une puissance énorme mais qui se réalise très bien en hardware avec plein de multiplier et d'additionneur.
Dans le projet open-graphics, la question revient souvent dans l'utilisation de dsp mais la réponse est toujours la même : cela sera bien trop lent.
"La première sécurité est la liberté"
[^] # Re: GPU et DSP
Posté par Maclag . Évalué à 3.
Les DSP dans l'embarqué sont très spécialisés. Ca veut dire qu'ils nécessitent une conception bien particulière qui leur permettra de faire UNE tâche très rapidement.
Un DSP embarqué qui décode des flux HD le fait certainement très bien, si je lui balance les calculs d'applications de textures et autres joyeusetés gérées par les cartes graphiques, il va tomber à genou.
On peut faire la même comparaison avec les décodeurs mp3/autre ajoutés sur certaines cartes sons il y a quelques années, et dire que les DSP de carte son c'est vraiment bas de gamme parce que le décodeur mp3 il le fait vachement mieux.
Certes, mais le décodeur mp3, il ne fait que décoder des mp3 et rien d'autre...
[^] # Re: GPU et DSP
Posté par Zenitram (site web personnel) . Évalué à 4.
Je veux une démonstration : parce que bon, si tu parle de "HD" avec un truc en 512*288 (le "TVHD" du téléphone) forcement le DSP du téléphone va suivre... Mais si c'est pour décoder du 1920*1080 (un vrai TVHD qu'un GPU sait décoder), j'ai peur que ton DSP de téléphone ai du mal...
Je dirai plutôt que les GPU sont devenus des DSP multi-fonctions (entre un DSP de téléphone sachant faire une chose très bien, mais hors de question de faire autre chose que cette unique chose, et un CPU qui fait tout mais lentement), mais pas des DSP bas de gamme (vu que les DSP que tu cites en exemple sont pauvres, très pauvres en fonctionnalités)
[^] # Re: GPU et DSP
Posté par rewind (Mastodon) . Évalué à 3.
Un processeur mobile (dans un téléphone) qui tourne à 400Mhz et qui encode et décode du MPEG-4 en temps réel jusqu'au VGA (640x480) à 30fps, du WMA, du H264 (jusqu'au QVGA (320x240)), du JPEG et qui fait de l'audio en prime.... "très pauvres en fonctionnalités" ? Je passerai sur l'argument du 1920x1080 sur un téléphone, je dirais que vu la taille des écrans, c'est loin d'être nécessaire.
http://www.st.com/stonline/products/families/mobile/processo(...)
Un autre exemple dans des set-top-box, un processeur à 266MHz et deux DSP à 400Mhz, ça décode du H264 High Profile et du MPEG-2 en HD (jusqu'à 1080i) et toujours en prime, tu as le son...
http://www.st.com/stonline/products/literature/bd/11102.htm
Maintenant, j'aimerais bien qu'on me montre des couples CPU/GPU qui font le même genre de chose à de telles vitesses.
[^] # Re: GPU et DSP
Posté par Zenitram (site web personnel) . Évalué à 4.
Oui un DSP de téléphone sait faire des choses, mais beaucoup moins qu'un GPU qui lui sait faire du 1080p!
Pour les set-to-box, le DSP sait décoder du H264, bien... Mais sait-il faire autre chose? non!
Tu donne des exemples, mais n'a pas lu en entier l'argumentation : les DSP savent faire des choses, mais très peu de choses, ils sont hyper spécialisé, un GPU est moins spécialisé, sait faire plus de choses...
Maintenant, j'aimerais bien qu'on me montre des couples CPU/GPU qui font le même genre de chose à de telles vitesses.
Et moi j'aimerai bien voir tes DSP faire autre chose que décoder du H264. Ils ne savent pas.
Les DSP donnés en exemples sont "pauvres" en fonctionnalités.
Un GPU est entre un DSP et un CPU... Mais n'est certainement pas un DSP bas de gamme, du fait de sa polyvalence, absente d'un DSP...
[^] # Re: GPU et DSP
Posté par rewind (Mastodon) . Évalué à 2.
D'ailleurs, ces DSP se programment en C, pas dans un langage restreint. Alors tout ce qu'il est possible de faire en C, il est possible de le faire tourner sur un DSP. Et je peux t'assurer qu'on peut leur faire faire n'importe quoi !
Tu dis qu'un GPU sait faire du 1080p, je peux te dire qu'un CPU sait faire du 1080p aussi, ça n'en fait pas un semblant de DSP pour autant.
[^] # Re: GPU et DSP
Posté par Nicolas Boulay (site web personnel) . Évalué à 2.
"La première sécurité est la liberté"
# Interface logicielle
Posté par GPL . Évalué à 3.
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.
[^] # Re: Interface logicielle
Posté par reno . Évalué à 2.
http://www.phoronix.com/scan.php?page=news_item&px=NjQ3N(...)
[^] # Re: Interface logicielle
Posté par reno . Évalué à 2.
http://aseigo.blogspot.com/2008/05/i915-and-gem.html
[^] # Re: Interface logicielle
Posté par GPL . Évalué à 2.
Il faudrait les tester sur des architectures AMD et NVIDIA...
De plus il semblerait qu'AMD soit sur le point d'ajouter de nombreuses nouveautés à la gestion de le ram vidéo de leur GPU.
Il faudrait savoir comment les futurs GPUs vont gérés leur mémoires et voir si c'est généralisable sans pénaliser certains dans 1 et 1 seule interface.
Sinon, il va falloir plusieurs interfaces bas niveau dont les clientes seront les interfaces de plus haut niveau.
On va me dire que c'est du bon sens...
[^] # Re: Interface logicielle
Posté par Zenitram (site web personnel) . Évalué à 2.
Genre la méthode actuelle des GPU (dessin par triangle) et son API qui va bien a supprimé la puissance d'une autre méthode : Voxel (qui si c'est fait en CPU brut est plus performant, mais voila, d'un coté le CPU qui fait tout, de l'autre une armée de GPU qui fait le calcul...)?
# et la virtualisation ?
Posté par Old Geek . Évalué à 1.
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 (site web personnel) . Évalué à 3.
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...
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # AVX = SSE++
Posté par reno . Évalué à 2.
Sinon tu parlais de compilation: AVX a des instructions a 3 registres (voire 4 pour la multiplication-addition) contrairement au SSE qui modifiait une des sources, ce qui devrait simplifier pas mal le travail du compilateur|programmeur au niveau de la gestion des registres.
[^] # Re: AVX = SSE++
Posté par Troy McClure (site web personnel) . Évalué à 3.
[^] # Re: AVX = SSE++
Posté par reno . Évalué à 2.
256bit = 4*64bit: ça va faire plaisir aux scientifiques qui utilisent des flottants sur 64b et non pas 32b comme pour les jeux.
[^] # Re: AVX = SSE++
Posté par Ontologia (site web personnel) . Évalué à 2.
Admettons qu'ils consacrent un coeur à leur AVX :
On a 15 registres 256 bits. En admettant qu'ils arrivent à faire exécuter toutes les opérations en un cycle, avec la possibilité d'exécuter plusieurs opérations en même temps, à condition qu'il n'y ai bien sûr pas dépendance entre données, je suis pas sûr qu'on puisse aller loin.
Si on l'utilise pour des opération à 3 opérandes (opération simple genre r = a*b +c), on pourra exécuter 15/3 opérations en même temps. SI l'on suppose qu'il exécute son opération en un cycle.
A 3 Ghz, ça nous fais 3.10^9*5 opérations.
r = a*b+c => 2 opérations simples
Soit 3.10^10 opérations, soit 10 Gflops
On est loin des 500 Gflops atteint par un GPU....
« Il n’y a pas de choix démocratiques contre les Traités européens » - Jean-Claude Junker
[^] # Re: AVX = SSE++
Posté par Troy McClure (site web personnel) . Évalué à 1.
En fait, http://arstechnica.com/news.ars/post/20080429-in-depth-intel(...) précise que pour larrabee c'est un autre jeu d'instruction vectorielles qui devrait etre utilisé avec des vecteurs 2 fois plus longs (16 float)
[^] # Re: AVX = SSE++
Posté par reno . Évalué à 2.
Non, je pense que chaque coeur aura son AVX comme a l'heure actuelle chaque coeur a son SSE.
>On a 15 registres 256 bits. En admettant qu'ils arrivent à faire exécuter toutes les opérations en un cycle, avec la possibilité d'exécuter plusieurs opérations en même temps
En général sur chaque coeur une seule operation SIMD est faite a un moment, par contre on peut avoir un load/store et un calcul entier en parallele.
Tes caculs de FLOPS sont plutôt mal fichu, le calcul est:
nombre de coeur * nombre instruction flottante en // par coeur * frequence.
Le nombre de registre n'a rien a voir la dedans..
4 coeur * 4 (a priori) * 3GHz ~= 50 GFlops
Mais bon ce nombre (tout comme celui des GPU) ne veut pas dire grand chose: les performances de la mémoire, des caches ont une grande importance en pratique, ainsi que la facilité de programmation.
Les GPUs sont plus puissantes, mais beaucoup plus dure a programmer donc les unités SIMD ont une niche non-négligeable: c'est beaucoup plus simple de faire un ensemble de librairie de calculs pour SSE (et plus tard AVX )(ça existe déjà d'ailleurs) que pour les GPU (a ma connaissance une libraire n'existe pas encore je crois)..
# GPU vs CPU
Posté par lfmarante . Évalué à 1.
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.
[^] # Re: GPU vs CPU
Posté par Nicolas Boulay (site web personnel) . Évalué à 3.
Pour un GPU, il peut y avoir plusieurs ordre de grandeur de perf. (au moins 1 en tout cas, donc un rapport 10) entre le moyen et le haut de gamme.
"La première sécurité est la liberté"
# Les développeurs font la différence ?
Posté par Mes Zigues . Évalué à -1.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.