Reprise du message précédent :

 
Sauf que si nVidia tient à peu près ses promesses avec Fermi, et réussit à concevoir des compilos aussi diversifiés qu'il prétend le faire (au moins en C++ et C correctement optimisés et surtout bien documentés, ce qui reste LE terrain d'Intel), la vision à moyen terme, Intel la prend déja en pleine face. Quel intérêt de faire persister le x86 si le confort est équivalent et l'archi éprouvée au moment où Intel entrera dans la danse ? Ils admettent peut être tout simplement cette fois qu'ils ont loupé le coche, et tentent de sauver les meubles.

Tout simplement car nvidia travaille aussi à long terme et que le fermi n'est qu'une étape. C'est pas avec fermi que nvidia va tout révolutionner et nvidia ne le prétend pas, c'est juste que fermi est une étape dans cette optique et permettra de consolider nvidia dans cette direction si fermi est bon et marche.
Et c'est normal qu'intel ait du retard vu qu'ils s'y sont mis après nvidia et part de zéro. AMD est aussi en retard sur ce point pour l'instant.

INTEL a tellement d'avance niveau part de marché qu'ils peuvent se permettre d'avoir du retard et de ne pas sortir à la va vite n'importe quoi.

 
Intel a de l'avance sur le marché des CPU, mais n'a rien à mettre en face des solutions HPC et GPGPU pour le moment. Le principal danger pour Intel est de ne plus être incontournable sur leur coeur de métier en ayant pas de plateforme complète à proposer. Intel voulait imposer sa vision des choses en mettant en avant le tout x86, ils ont échoué, ce qui en plus excuse presque le retard d'AMD. Ca ne remettra pas en cause profondément leur économie, mais ça ne doit pas être agréable pour leur égo vu les moyens et les recrutements mis en oeuvre pour Laarabee et le mépris qu'ils ont affiché à l'égard de leurs concurrents, nVidia en premier chef. Faire du GPU n'est finalement pas si simple qu'ils le laissaient entendre début 2009, et la leçon est valable aussi pour nVidia qui n'a pas intérêt à rattraper les près de 40 ans d'expertise d'Intel en CPU. La documentation de CUDA a déja montré que nVidia a du chemin à faire pour plaire aux devs...donc oui, c'est pas non plus totalement gagné pour eux non plus.

Soit t'as pas tout suivi, soit t'es de mauvaise foi là quand même...
 
Ils ont clairement présenté Fermi comme une révolution, principalement grâce à sa "compatibilité avec le modèle C++" qui, techniquement, n'est pas franchement un avantage...
 
Programmer du multi-thread en C++ est certes maîtrisé par pas mal de monde, mais c'est surtout pas forcément ce qu'on fait de plus efficace et paradoxalement les Compute Shaders qui servent de base à DirectCompute ont toutes les chances d'être plus efficaces car eux nécessitent des algos adaptés aux processeurs massivement parallèles, limitant les dépendances (synchronisation) et du coup imposant presque d'exploiter au mieux la puissance de calcul.
 
D'ailleurs, le C++ n'aura pour avantage que la programmation objet, certes plus jolie (plus structuré, limite intuitif), mais pas fondamentalement différente et encore moins systématiquement au top d'un point de vue perfs.
 
 
La réussite de cette "révolution" dépendra avant tout des premières mises en oeuvres, qui devront à tout prix être proches de la perfection et donc utiliser conjointement le CPU et le GPU, sans quoi les gains apportés par le parallélisme pourraient être saccagés par des pertes dans des portions de code qui devraient être exécutées sur le CPU.

De toutes façon, le larabee était voué à l'échec vu qu'Intel ambitionnait d'abord d'être équivalent au niveau puissance à un G80 puis ils ont essayaient de promettre la puissance d'un GT200 pour un produit qui devait sortir après le GT300, c'était sur que ça n'irait pas loin.
J'ai du mal a comprendre la stratégie d'Intel sur ce coup la, ils espéraient qu'ATi et nVidia allaient les attendre gentiment sans sortir de nouveau produit ?

Le vrai problème, c'était de partir sur le x86... l'archi on s'en tape royalement depuis quelques années et au moins nVidia aura compris ça.
 
AMD aussi semble continuer dans la voie qu'ils avaient emprunté à l'époque du K5 (!), à savoir un processeur simple avec un étage de "décodage"... repris par la suite par Intel pour le Pentium Pro (P6) et qui persiste depuis lors... sauf sur Larrabee (!!).
 
Au final, Larrabee ressemble furieusement à une erreur monumentale dès son concept, et il ne serait pas étonnant qu'il soit tout simplement abandonné et non repoussé.
 
A quoi bon mettre 48 processeurs x86 compliqués quand on peut mettre 128 processeurs "simples" dans le même budget de transistors?
 
Si Fermi est un pwal over-engineered (avec une architecture plus proche du G80, qui n'était pas vraiment ridicule, il pourrait être quasiment 2x plus petit et aussi performant), Larrabee est selon toute vraisemblance tout simplement né d'une mauvaise idée, et si il est déjà mal barré alors que la guerre n'a même pas commencé, on peut d'ores et déjà l'enterrer sans gros risque d'erreur.
 
 
Edit:
 
Je suis pas le seul à penser que la "compatibilité C++" de Fermi soit un avantage tout relatif, un petit exemple ici -> http://forum.beyond3d.com/showpost [...] tcount=281 http://forum.beyond3d.com/showpost [...] tcount=287
 
Et concernant Larrabee, une réponse pleine de bon sens y a été donnée ici -> http://forum.beyond3d.com/showpost [...] tcount=288

Reste a savoir quelle la cible réelle d'Intel avec le Larabee. dans la cadre d'une puce graphique, le choix du x86 peut en effet ressembler a une erreur. Je dis bien ressembler parce que en soit l'idée n'est pas idiote : remplacer 128 processeurs simple par 48 processeur compliqué qui en font 4x plus que les simple, on arrive a un rapport de 128 pour 192 favorable a l'archi plus compliqué seulement c'était compté sur un immobilisme technique de la concurrence qui pour le coup est la veritable erreur d'Intel. Le seconde c'est de remettre en cause l'architecture générale du fonctionnement des puce graphique depuis prêt de 15 ans en jetant la rasterisation et du coup Direct3D et OpenGL en pensant que comme tu t'appelle Intel, tout le monde va suivre.
 
Ensuite si la cible était le GPGPU, le choix du x86 est nettement plus compréhensible. Ceux qui ont déjà essayer de développer avec Cuda ou encore pire avec ATi stream, savent que malgré tout leur effort pour simplifié leur utilisation, ces API reste compliqué à programmer correctement et surtout à optimiser. Le choix du x86 permet d'utilisé les nombreux outils déjà existant chez Intel pour la programmation parallèle à moindre cout. De plus le GPGPU est une techno récente qui accepterai plus facilement ce genre de changement. Reste que Intel n'a pas pris en compte son propre temps de développement ou à penser que la concurrence n'aller pas bouger.

Le souci, c'est que c'est pas 48 processeurs 3x plus puissants, mais équivalents
 
Les "processeurs" de Fermi sont 2x plus "compliqués" que ceux de Larrabee, en ce sens qu'ils traitent 2x plus de données par cycle.
 
Dur de se prononcer sur ce que nous pondra AMD fin 2010, mais si ils suivent la voie du SIMD il est fort probable qu'on ait droit à des perfs plus que doublées par rapport à Fermi si ils ne prennent pas le même travers. La puissance brute de Cypress avec l'efficacité de Fermi, c'est pas exclu en 32/28nm (50/90% de budget transistors en plus), et là Larrabee serait bon pour le musée.

Annulation
 
http://www.pcworld.fr/2009/12/07/m [...] pu/462831/
 
http://www.clubic.com/actualite-31 [...] nnule.html

En fait, si AMD arrive vraiment à produire un CPU qui intégre une unité GPGPU avec une puissance équivalente à une HD3870 (64 unités vectorielles si je ne m'abuse), et que le développement d'OCL continue son chemin, ce type de puce rendrait complètement obsolètes les plus chers des Xeon/itanium d'Intel, sur les marché serveur/workstation (d'où la compatibilité GPGPU  du Clarkdale annoncée à l'arrache et qui risque d'être assez moyenne comparée aux solutions AMD/NV)
 
Si la portabilité du code sur GPU reste facile à mettre en place, comme l'indique NV avec le C++ de Fermi (et de ce point de vue, la compatibilité x86 de LRB ne présente que peu d'intérêts vu que le développement ne se fait plus à un niveau au bas) et que les perfs correspondent vraiment à ce qui est annoncé, on se retrouverai avec des CPU généralistes qui seraient cantonnés à un rôle de "chipset" et qui passeraient la main aux GPU pour les calculs lourds et massivement parallèlisables... Dans ce type de configuration, le savoir faire historique d'Intel (à savoir l'efficacité des unités généralistes FPU/SSE) devient complètement caduque...  
 
La seule vraie question est : "quid de la facilité de programmation en GPGPU ?"
 
En tout état de cause, l'avenir est entre les mains des développeurs. Ce sont eux qui détermineront les technologies de demain, et de ce point de vue, AMD a un pied des deux côtés de la ligne...avec quand même un problème de taille : vaut-il mieux savoir faire 2 choses moyennement, ou un seule très bien ???

 
On est d'accord, quand je parlais de traité plus de donnée, c'était par rapport au G80, objectif de départ d'Intel. Sortir une archi équivalente au G80 plus de 4 ans après, c'est pas très futé.
 
Maintenant Intel à déjà des prototype fonctionnel à 128 core (pas en Larabee mais en CPU) et il n'est pas impensable que lorsqu'il auront du 22nm ils pourront monté à 256 voir plus. Quand on voit les problèmes qu'a TSMC à graver de grosse puce en 40nm, 2011 pourrait être le retour en grâce du Larabee ... ou pas
 
En ce qui concerne ATi et nVidia, il est assez difficile de se faire un avis. Les dernière génération de puce nVidia ont toujours était plus efficace que les ATi malgré un déficit flagrant de puissance brut. Alors quand j'entends partout crier à l'échec du Fermi sur les premières estimation de puissance brut, je dit wait & see. ensuite la prochaine génération d'ATi sortira t'elle vraiment fin 2010. Vu les problème financier d'AMD en ce moment, il n'est pas impossible qu'il profite un peu de leur avance pour retarder un peu la prochaine génération et ainsi amortir un peu plus le Cypress, laissant ainsi nVidia revenir dans la course.

Si les outils fournis aux programmeurs sont correctement conçus, nul doute que le GPGPU sera une tuerie . Il suffit de voir la différence entre nVidia PhysX et Physic Software pour s'en rendre compte : les unités de calcul vectorielles sont nettement plus performantes que les coeurs x86 ordinaires pour faire du calcul brut . Donc, intégrer de telles unités dans un CPU ne peut qu'accélérer l'arrivée massive du GPGPU .

Plus honnêtement, 4 SIMD 256bits à 1.5GHz sont plus intéressants que même pas 1 SIMD 128bits à 3GHz, ce qui est déjà moins glorieux...
 
Pour rappel, dans Batman AA, PhysX CPU n'augmente quasiment pas la charge CPU qui reste à un niveau ridiculement faible.
 
http://hardocp.com/article/2009/10 [...] _review/11
 
Sans PhysX, CPU load = 37% en moyenne, max 63% global et 100% sur 1 seul core.
Avec PhysX GPU, CPU load = 35% en moyenne, max 71% global et 97% sur 1 seul core (bref, idem aux erreurs de mesure près).
Avec PhysX CPU, CPU load = 39% en moyenne, max 71% global et 97% sur 1 seul core.
Avec PhysX "PPU", CPU load = 44% moyenne, max 78% global et 100% 1 core (GTS250 en plus de la GTX285).
 
Conclusion: PhysX "CPU" utilise à peine 4% du quad, soit moins de 20% d'un core, en prenant le cas le plus favorable...

Si j'ai tout suivi et non je ne suis pas de mauvaise foi.

Tu voulais qu'nvidia présente le fermi comme un produit quelconque? Non bien sur. On enjolive la réalité et on présente son produit comme une révolution. Faire le contraire serait juste du suicide commercial.

Mais le fermi n'est qu'une pierre dans l'édifice que compte construire nvidia et ne sera surement pas ce qui révolutionnera tout. C'est juste une continuité pour les 5-10 prochaines années.

 
Du point de vue du développeur le PhysX n'a rien à voir avec Cuda ou le GPGPU. Il s'agit de 2 API complètement différente et le PhysX peut être au final être exécuté sur 3 puces d'architecture différente (CPU, GPU Nvidia ou processeur PhysX Aegia).
 
Ton exemple montre l'efficacité du traitement PhysX par un GPU mais n'indique en rien si c'est facile ou non de les utiliser. Or il s'agit bien la du nerf de la guerre : la facilité d'utilisation. nVidia l'a bien compris avec des drivers plus performants et un programme d'aide au développement "The way it's mean to be played". Leurs cartes sont moins performantes en puissance brute mais mieux optimisée coté logiciel, mieux utilisée et au final plus répandue que celle d'ATi

Hum...
 
Tout comme pour le x86 a une utilité toute relative pour Larrabee, PhysX est là pour développer en abstraction de l'architecture sous-jacente, donc ça n'est pas une question de facilité d'accès puisque quelque soit la cible (CPU, GPU ou les SPU de Cell, le PPU ça n'existe plus) le code reste le même. On peut d'ailleurs se demander comment ils peuvent réussir la prouesse d'accaparer plus de temps CPU en PhysX GPU qu'en PhysX CPU sinon en bridant volontairement la runtime CPU pour faire paraître leurs GPU artificiellement plus performants, surtout quand on les voit au final reprendre le modèle de programmation des CPU sur leur nouvelle architecture "GPU".
 
Je ne pointe pas du doigt l'efficacité d'ailleurs, mais l'occupation CPU uniquement, sachant qu'en version CPU les perfs sont tout simplement désastreuses (3fps en moyenne sur les 2/3 du test, kinenveut? Et pourquoi ça donne pas 15+fps vu l'utilisation CPU minable alors que c'est visiblement parallélisable puisqu'un GPU apporte un gain?).
 
 
Le problème est tout simplement qu'on a affaire à 2 boulots totalement différents, et aussi bien Intel avec Larrabee que nVidia avec Fermi ont fait des choix douteux voire désastreux. Comment se code un chargement de registre ou comment sont gérés les threads, techniquement on s'en fout (d'ailleurs, on ne devrait pas avoir à gérer de thread pour ce qui est du calcul parallèle), ce qui importe c'est qu'on puisse faire ce qu'il y a à faire et, tant qu'à faire, le plus rapidement possible (c'est quand même le but) et le plus économiquement possible (obtenir les mêmes perfs dans un budget inférieur, c'est augmenter la performance pour le même budget). Ces 2 architectures ne répondent plus à cette seconde règle car elles reprennent des concepts qui n'ont pas vraiment lieu d'être.

Curieux en effet. À savoir : tout le code physique n'est pas parallélisable/ne peut tourner sur GPU, une bonne partie doit rester sur CPU. Donc je m'attendrai à une conso CPU par la physique en baisse, mais pas d'autant que l'on s'y attendrait. Que la conso CPU ne change pas du tout signifie soit que la physique est très loin d'être la partie bloquante et qu'on économise sur du code non significatif en perfs (donc technologie hardware inutile), ou qu'il y a quelque chose de vraiment curieux là-dessous...

 
On est d'accord. Et c'est dans se sens que vont les choix d'Intel et de nVidia pour leur architecture.
- nVidia a choisit de rendre sa puce compatible avec un langage de haut niveau (le C++) afin que les développeur puisse développer rapidement sans se soucier de la "tuyauterie". C'est le compilateur qui fait tout le travail d'optimisation. D'ailleurs aujourd'hui, les compilateurs C++ x86 sont tellement évolué qu'il est difficile de faire la différence entre du code C et du code C++ (de même qualité bien sur). Espérons que nVidia arrive a ce même résultat.
- Intel a fait le choix du x86 pour bénéficier justement de toute leur expérience en compilation mais aussi de leurs nombreuses librairie gérant déjà le parallèle et déjà employer par de nombreux développeur.
 
Au final, ce qu'ils désire tous c'est vendre leur puce, l'hégémonie coté performance n'est qu'une pub. Intel continuait à vendre 3 ou 4 fois plus de puce qu'AMD quand celui ci dominait techniquement. nVidia reste devant ATi alors que les carte ATi sont théoriquement plus performantes. Ces deux firmes ont compris que le support logiciel et technique était plus important que la performance pure de la puce. AMD reste un tres bon fabriquant de puce mais s'arrete la. Comme j'en ai parlé plus haut, via le programme "The way it's mean to be played" nVidia fait coup double (voir triple). La ou ATI se contente de fournir quelques carte au jeux labellisé ATI, nVidia offre un support quasiment gratuit et leur ingénieur sont quasiment intégrés aux équipes de dev des jeux. Ils font non seulement du lobbying auprès des boite de jeu mais en plus ils optimisent les jeux pour leur carte.
Ce qui compte le plus c'est la facilité d'utilisation de ces technologie dans les développement via les API. Si c'est accessible, elle seront utilisée par de nombreux développeur et donc les produits proposant ces techno se vendront bien. L'efficacité de l'architecture et les performance brute n'intéressent au final de les initiés et n'influent pas ou quasiment pas les volume de vente.

Ce qui est porté en Cuda (pour le moment) ce sont les solveurs fluides & tissus.
La broadphase et la nearphase restent sur le CPU.
 
Le prochain SDK majeur devrait essayer de tout faire en Cuda. (broad, near, collisions & solveurs)
 
Maintenant je me fierai pas à Batman AA pour juger l'implémentation de PhysX.
 

 
Dans beaucoup de jeux, la physique se résume à des effet de particules qui améliore le rendu du jeu mais c'est tout. Cet effet est lui quasiment totalement prix en compte par la carte. La techno n'est pas encore suffisamment répandu ni standardisé pour qu'un éditeur se permette de se privé de tout les utilisateurs d'une marque en incluant de la physique dans le gameplay du jeu.

 
Attention le boulot du compilo est plus lié à l'implémentation du CPU/GPU qu'au jeu d'instruction.
Un compilo PPro-style partagera plus de stratégies d'optimisation avec un compilo PPC qu'avec un 286 .
Dans le cas du Larrabee, toute la partie critique est liée aux instructions Larrabee.
Le x86 n'étant que du détail, et l'expérience autour du x86 tombe en partie.
 
Intel voulait garder le x86 pour avoir une courbe d'apprentissage simplifiée au début avec le Larrabee, mais comme tout le boulot est du coté des instructions Larrabee...
 
 
 
 

C'est juste le meilleur exemple qu'on ait... on y peut pas grand chose
 
Est-ce que ça n'intéresse personne, ou est-ce que c'est tout simplement inexploitable (et donc, ceux qui veulent se heurtent à des limitations telles qu'ils ne peuvent rien faire de probant), c'est à ça qu'il faut qu'on trouve une réponse.
 
De toute façon, on ne devrait plus tarder à voir des résultats intéressants en ce qui concerne le GPU computing avec l'arrivée de DX11, et quand je dis intéressants, c'est open source ou réellement optimisé (prise en compte des spécificités de chaque GPU pour l'exécution... c'est sûr que si on configure un nombre de threads fixe quelque soit le GPU on a toutes les chances d'en favoriser un en particulier).
 
Edit: y'en a des fluides dans ce Batman, c'est l'effet N°2 après la tornade qu'on voit passer qu'une fois

 
ME, Cryostasis pour les fluides ?

J'avais compris que Larabee et Terascale étaient 2 projets différents. Terascale est un "server room on a chip", avec des routeurs intégrés, et des minicores généralistes de la taille d'un K7, pour des fin de recherche :
http://arstechnica.com/business/ne [...] a-chip.ars
http://arstechnica.com/hardware/ne [...] ascale.ars
 
Larabee c'était orienté DSP, avec du minicore type pentium et des unités SIMD, abscentes du TS :
http://arstechnica.com/hardware/ne [...] um-pro.ars
 
Ensuite qu'AMD et Intel aient des objectifs comparables sur l'intégration cpu-gpu c'est normal. Pour exploiter les gravures de plus en plus fines, il y a un moment ou on change d'échelle.
Du temps du 386, il y avait un coprocesseur pour les flottants, le 387.
En passant au 486, la FPU a été intégrée on die. Cà va être pareil pour les gpu, qui sont des coprocesseurs.
 
Je vois dans le CELL d'IBM un précurseur de tout ces trucs.

En fait les 2 projets sont diamétralement opposés mais fondamentalement ils répondent bien à la même problématique.
 
D'un côté, Intel tente de faire du "cloud computing on chip", de l'autre AMD considère qu'il y a clairement 2 types de charges de calcul, et pour le coup je crois qu'AMD est pas mal dans le vrai.
 
C'est un peu ce qui m'a amené à remettre le modèle de Fermi sur le tapis, puisque d'un côté on cherche à exécuter des tâches parallèles (shaders) alors que de l'autre on complique tout pour se conformer à un langage évolué mais pas réellement adapté (C++), sans même parler de la très forte probabilité qu'on retrouve en pratique des directives/structures très typées "shaders" dans le langage, car c'est justement le principal (seul?) intérêt du GPU computing.

Non. http://www.realtimerendering.com/b [...] -larrabee/
http://jonpeddie.com/blogs/comment [...] nt-future/
 
Seule la v1 est non commercialisée au public (mais dispo aux entreprises ayant des besoins en dévs parralélisés).

An Inconvenient Truth: Intel Larrabee story revealed en 5 pages.

Some Actual Larrabee Information: Tom Forsyth, one of the many programmers and engineers on Larrabee, passed on this link to a lecture he gave at Stanford on January 6 for their weekly Computer System Colloquium class. At the beginning he gives a bit about Intel’s view of Larrabee and the effect of “cancellation”, i.e., it’s not cancelled, just the first hardware release is off

Stanford EE820 course 2010 - The Challenge of Larabee as a GPU par Tom Forsyth
Et la présentation en vidéo

Les premiers échantillons du CPU Intel 48 cœur dispo en échantillons

 
Curieux de voir la suite qu'ils vont y donner. Quand leurs usines seront prêtes pour le 22nm, peut être qu'on en ré-entendra parler pour le grand public ?

Larrabee est mort, vive Larrabee

C'est finit, circulez il n'y a rien à voir.

2ème échec pour intel sur le terrain des CG

Nvidia et ATI peuvent dormir en paix

http://blogs.intel.com/technology/ [...] s-rela.php
 

Larrabee 50 cores en 22nm :

Désormais plus orienté calcul parallélisé en général que graphisme (ce qui n'empêche pas les dévs de JV/3D de créer des moteurs de rendu dessus, mais ce produit sera-t'il accessible au grand public?)

Vous pensez qu'à terme intel pourrait être tenté par le marché des cartes graphiques grand public ?

À ma connaissance Tom Forsyth et Michael Abrash travaillent toujours chez Intel, donc... oui

 
 
Franchement non ^^
 
On jette pas l'éponge au bout de 2ans pour revenir ensuite surtout quand on est un géant comme intel avec les moyens financiers pour assoir sa position sur ce marche
 
S'ils ont changé d'avis ce n'est pas pour rien

Je ne pense pas, pour 2 raisons.
 
1. Les GPU vont peu a peu être intégrés au CPU, ca on le sait tous. Vous allez dire, qu'ils sont pas assez puissant. Oui mais ca va changer dans la décennie qui vient. AMD est sur la bonne voie. Est-il rentable de se lancer dans un marché des GPU grand public qui tend à se réduire dans l'avenir? Pas sûr.
 
2. On va vers le calcule distribué pour la 3D. Il me semble avoir lu je ne sais où une news concernant la démonstration du streaming 3D via Silverlight.
Bref que ce soit en fait votre FAI qui fasse le calcule pour vous. Jouer aux jeu comme pour la VOD quoi.
 
C'est ce que certain prévoient dans l'avenir, j'ai lu ca je ne sais plus où.

Dans toutes les news parlant de cloud ...

 
 
J'avais perdu le topic ...