À 80 cores c'est pas plutôt Terascale/Polaris ? On a vu un die-shot de Larrabee avec 32 cores...
À 80 cores c'est pas plutôt Terascale/Polaris ? On a vu un die-shot de Larrabee avec 32 cores...
Oui ca ressemble a une typo .
C'est combien le max atteint sur SGEMM sur les GPUs actuels (ou futurs si qq un a acces a un Fermi )
Dernière modification par fefe ; 19/11/2009 à 01h17.
fefe - Dillon Y'Bon
Chez NV, on est a 60% du peak (MAD seuls) sur GT200, donc 425 Gflops sur GTX 285.
Côté AMD, on aurait des prototypes atteignant 880 Gflops sur 4870 (73% peak). Si ça scalait linéairement, on s'approcherait de 2 Tflops sur 5870, mais les ratio Tex/FPU et débit LDS/FPU fait que l'implémentation "optimale" devra être différente...
Pour Fermi, on aura 1 instruction load 128-bit pour 4 instructions FMA. Si les loads sont gérés par l'unité dédiée, on atteindra maxi 80% du peak (limitation au niveau du dispatch).
Ça doit donner une fourchette de 730 à 1000 Gflops sur Tesla C2050...
Ok donc pour l'instant c'est la demo la plus "haute" sachant que d'ici quelques mois des produits devraient en arriver la (pas des prototypes).
fefe - Dillon Y'Bon
Dernière modification par newbie06 ; 05/12/2009 à 15h48.
Je ne suis vraiment pas surpris, je n'ai jamais cru au modèle cohérent avec plein de coeurs, je trouve l'idée du message passing tellement plus intéressante (au moins ça me rappelle ma jeunesse ).
Larabee ne sortira pas ?
Encore une victoire de canard : http://forum.canardpc.com/showpost.p...2&postcount=30
(Y'avait un autre exemple plus pertinent avec une comparaison avec l'itanium 1 tout pourri fourni aux dev pour passer en itanium 2 performants ensuite, mais j'ai la flemme de chercher)
Mes propos n'engagent personne, même pas moi.
Aussi souple soit il, Larrabee ne pouvait clairement pas rivaliser avec la concurrence en terme de performance brute. En allant titiller le marché 3D des API graphiques Intel ne pouvait de toute façon pas espérer bcp mieux qu'un échec cuisant sur le haut de gamme.
Du côté du ray-tracing, leur démo de l'IDF dernier était loin de pouvoir faire la différence avec le ray-tracing sur GPU plus traditionnel. Il leur reste alors le calcul haute performance, ce sur quoi ils n'ont rien à mettre en face d'un NVidia qui fagocite le domaine.
Bref l'annulation du Larrabee n'est clairement pas une surprise.
Un avenir viable pour du graphique haut de gamme Intel? Pourquoi pas si le rendu software réussi à s'imposer à nouveau (fort probable). Plus d'API graphique => plus de standard de "GPU". Dans ce cas de figure, un "CPU"-like peut faire tout aussi bien (mieux?) qu'un GPU sur du code graphique, et ce que ce soit sur un CPU externalisé sur carte (Larrabee 2, Fermi3 ) ou sur un CPU classique...
D'après cette news (d'accord c'est Fudzilla ) ,Intel dément stopper Larrabee comme solution graphique et travaille jusqu'au moment ou il sera à niveau de Nvidia/Amd .
Ce n'est pas que Fudzilla, c'est le message officiel d'Intel, et c'est logique : ils ont besoin de Larrabee et ne vont pas abandonner comme ça.
Ca serait con d'investir autant dans un concept et de s'arreter alors que le premier chip n'est pas satisfaisant (surtout que historiquement aucun chip complexe n'a delivre ce qui etait attendu de lui a la premiere generation). Donc ils continuent, je dirais que jusqu'a present tout va normalement, on saura vraiment ce que vaut Larrabee a la 2 eme ou 3 eme generation, ceux qui ont cru autrement sont ceux qui ecoutent les voix de marketing .
fefe - Dillon Y'Bon
Alors j'espère que les générations 2 et 3 auront le bon goût de ne pas être cohérentes.
Tout à fait d'accord ,ce n'est pas une tentative pour creer un nouveau marché (ce qui permet d'avoir une plus grande marge de manoeuvre) mais essayer de pénétrer un marché très compétitif (et en évolution très rapide) et bipolaire (Amd-Nvidia) .
Donc pour réussir à avoir un produit viable ,ils doivent réussir à concevoir une puce performante ,pas trop complexe à produire et à programmer et sans exploser la dissipation thermique ,ce qui leur demandera quelque génération (le moins possible espérons-le) pour obtenir un résultat probant
Envoyé par Tim Sweeney
Sold is the word .whether it's sold as a Express add-in card, an integratedg raphics solution, or part of the CPU die.
fefe - Dillon Y'Bon
Bah s'il veut la cohérence à tous les niveaux, j'espère qu'il est prêt à éduquer tous ses programmeurs sur les méfaits de laisser faire ça sur un système avec un ringbus
Je trouve son discours limite fanboy, même si je suis plutôt d'accord avec certains points.
Tu peux en dire plus sur ces mefaits ? Je ne vois pas de quoi tu veux parler...
fefe - Dillon Y'Bon
Hum, je me demande s'il y a un piège
Exemple bête : je génère une texture procédurale sur P0. Cool avec la cohérence, tout le monde voit les données et peut faire ce qu'il veut avec cette texture ; enfin pas tout à fait, si je dois la modifier, chuis pas con je la locke avec un sémaphore, mais tout le monde peut la lire. Voilà j'ai stupidement saturé le ring bus parce que j'ai x processeurs qui vont lire la texture.
OK l'exemple est complètement idiot. Mon point est juste que si le placement de données n'est pas fait correctement (impliquant aussi que le traitement est placé), ça ne marche juste pas avec beaucoup de coeurs. Donc la cohérence ne m'apporte pas tant que ça (sauf peut-être des prises de sémaphore plus rapides).
Idiot ?
Bien sur que c'etait un piege , mais bon je n'etais pas sur de ce a quoi tu faisais reference.
Je pense que tu confonds coherence et consistance memoire ou alors oublie le snoop filtering et ce qui est fait de maniere generale pour traiter le trafic de coherence. La coherence est juste le fait de garantir quand tu lis une donnee que tu as la derniere version qui a ete ecrite par qui que ce soit dans le systeme. Tu as des snoop filter qui te permettent de ne snoop que si la donnee a ete demandee pour ecrire par un autre core depuis que tu as obtenu ta derniere copie, donc tu n'emets pas de snoops a chaque lecture, et une fois que ta donnee a ete modifiee il y a plein d'algorithmes intelligents de mise a jour de tes filtres qui reduisent/font disparaitre le risque de passer son temps a snoop pour rien a chaque nouvelle lecture. Qui plus est un snoop est une requete specifique et non un transfert de donnee, ce qui dans la plupart des reseaux d'interconnection transite sur des fils differents geres separement. Bien entendu si tu as une donnee a transferer ca prendra de la bande passante, mais il aurait fallu le faire de toutes facons. Donc oui le traffic de coherence prend de la bande passante, sur le reseau charge de gerer ca qui est optimise pour.
Si pour des raisons de consistance tu passes ton temps a locker/unlocker des donnees tes perfs vont s'effondrer si beaucoup de monde doit y acceder, mais c'est essentiellement un mauvais algorithme de parallelisation et pas un effet de la coherence. Le fait de travailler sur des tiles de memoire a tendance a simplifier cet aspect considerablement.
Les problemes de bande passante des ringbus est plus leur scalabilite qu'autre chose. ATI a abandonne le ringbus quand ils ont du mettre trop d'agents dessus, et ils n'etaient absolument pas coherents.
De maniere generale la simplicite de programmation qu'induit la coherence libere du temps pour reflechir a l'algorithme et au placement des taches .
fefe - Dillon Y'Bon
Des nouvelles du Siggraph Asia en VO :
http://pc.watch.impress.co.jp/docs/c...22_338322.html
La roadmap initiale :
À partir de Larrabee 1 en 2010, sortie d'une nouvelle version chaque année (2, 3, 4).
En 2014, intégration du core LRB dans les CPU mainstream.
C'est finalement Larrabee 2 qui introduira une incompatibilité dans le jeu d'instruction, même si ça n'a pas l'air de changer grand-chose pour le programmeur sur les instructions vectorielles. Enfin si jamais il n'est pas annulé entre temps.
Fermi n'est pas l'ennemi de Larrabee, c'est un allié.
Bah ouais, il contribue à faire migrer les moteurs de jeu depuis les API graphiques vers du rendu soft et de la physique, terrain favorable à LRB...
AMD devrait suivre d'ici-là.
Marrant a chaque fois qu'ils ont annonce une roadmap ils s'en sont mordu les doigts. Par exemple, comparez cette annonce a la rumeur de Charlie: http://www.semiaccurate.com/2009/08/...graphics-cpus/ .
fefe - Dillon Y'Bon
J'ai une question à la con : incompatibilité jusqu'à quel point ? Ne serait-ce pas l'occasion pour Intel de laisser tomber certaines features qu'ils se trainent depuis 30 ans et qui ont un coût astronomique (cf. le post de fefe) ? Après tout, la compatibilité binaire on s'en tape un peu sur LRB, non ?
Ils parlent d'ncompatibilite sur des instructions qui n'existent pas en x86 mais avaient ete introduites par LRB1. Vu que LRB1 ne sera fourni qu'en samples a quelques developpeurs, c'est comme dire que le jeu d'instruction de LRB1 n'a jamais existe... et que LRB2 a le seul jeu d'instruction LRB... Je doute que le sacrifice de la legacy x86 soit pres d'arriver .
fefe - Dillon Y'Bon
Ha ça ne concerne que les instructions vectorielles. Je suis bien déçu
Quelle est la justification pour conserver les aberrations de l'ISA x86 ? Niveau compilo ce serait facile de changer. J'imagine donc qu'il s'agit de réutiliser des unités existantes ?
X86 c'est comme une religion, il ne faut pas poser ce genre de questions, sinon tu risques de ne pas aimer la reponse
fefe - Dillon Y'Bon
Option 1 est plus proche de la realite qu'option 2 a mon avis. Des fois il y a des gens qui ne reflechissent pas au futur quand ils definissent une ISA...
fefe - Dillon Y'Bon
Bill Kircos à propos du projet Larrabee (et de leur futurs IGP) :
http://blogs.intel.com/technology/20...phics-rela.php