Reprise du message précédent :

 
Sauf que le Llano sera complètement en 32nm (ou 32nm pour le CPU et 40nm pour le GPU), alors que le Q8200 est en 45nm .
 

 
Quel diagramme ?!?
Tu pourrais le retrouver ? Merci !

qqun sait pk je reçois des mails à chaque post sur ce topic ?
ça se passe seulement sur ce topic

faut zappé cette idée de suite, parce qu'utiliser deux proceder de gravure sur un wafer c'est juste inutile, cher et sans interêt qui plus est !!!

La petite icone en haut a droite  

 
Tant mieux, il sera tout en 32nm !

La question, aujourd'hui, c'est :
Est-ce que ce sera TSMC qui produira le Llano ? (vu l'état des choses aujourd'hui, ça n'a pas l'air évident)
Si non, seras-ce UMC ou GF qui se chargera d'honorer la commande ?
 
Euh, deux questions, en fait .

Celui en page 6 là : http://phx.corporate-ir.net/Extern [...] BlPTM=&t=1
 
On voit bien qu'il est question d'abord de coupler un GPU et un CPU dans le même die, puis de les fusionner pour obtenir un nouveau type d'architecture.

a long terme c'est un truc qui va arriver, puisque la puissance de calcul de CPU et d'un GPU sont de deux mondes différents  

Les charges sont différentes, mais les calculs, eux...
 
La raison de cette fusion est très bien expliquée je trouve : trop de contraintes avec le multi-cores, du coup autant passer à un autre modèle de programmation, héritant à la fois des actuels CPU et GPU.
 
Bulldozer est une première tentative si leurs illustrations ne sont pas volontairement trompeuses, au final on devrait retrouver de plus en plus de pipelines d'exécution sous un même décodeur, et donc ni plus ni moins que le shader core d'un GPU derrière un étage de décodage...
 
C'est proche de ce que nVidia a tenté avec Fermi en fait, mais AMD a probablement plus de background sur les CPU et leurs fréquences élevées, sans oublier que la cible est beaucoup moins élitiste (y'a que le caméléon pour sortir des bestiaux de 500mm² au lieu d'attendre sagement que l'archi soit réalisable).

+1 en même temps elle bluff grave leur gross puce  

 
Je crains que le projet d'AMD ne tombe à l'eau vu comme ça ... puisqu'Intel semble bien décidé à conserver le ^m genre d'architecture, avec davantage de cores, comme le montre son prototype de 48 cores x86 .
 
Pour moi, l'architecture à laquelle AMD voudrait aboutir, c'est des cores capables de gérer les threads compliqués et en ^m temps d'avoir une haute puissance de calcul ... malheureusement, polyvalence et vélocité ne riment pas . AMD a peu de chances de réussir si là est son dessein .
 
A mes yeux, le top, ce serait par exemple un réseau de cores x86 reliés entre eux par le biai de fibre optique, chacun possédant un certain nombre de shaders dédiés et ne pouvant reçevoir d'ordres que de lui . Comme ça, les cores pourraient gérer les threads complexes et transférer la gestion des applis optimisées GPGPU aux shaders, plus véloces .
Ce serait bien, non ? Ou il vaut mieux privilégier une archi où les shaders sont disponibles pour tous les cores ?

Le dessein d'AMD a toujours été celui-là, Zack38, peut-être ne faudrait-il pas l'oublier  

Actuellement, AMD n'est pas en état d'investir assez en R&D pour aboutir au résultat escompté .
C'est sûr qu'une architecture de la sorte sera révolutionnaire, mais inutile pour le moment en tout cas . Il faudra beaucoup de travail de la part des développeurs pour que leurs applis tirent parti d'un tel CPU ...
 
Je suis assez perplexe quand je vois ça, puisque finalement, c'est le nombre qui fait la puissance . Un seul shader n'est pas très puissant . Si AMD veut fusionner un core x86 et un shader, le résultat ne sera pas vraiment satisfaisant . Et s'il faut en fusionner plusieurs, je dis pas le boulot ni la taille du die au final ...

RWT avait essayé de comprendre, sans grand succès :
http://www.realworldtech.com/page. [...] 2808015436
 

Comment as tu trouvé l'image, aucune news n'apparait sur leur site.
 

Humm je n'ai pas souvenir de prédiction de sa part antérieurement.

Les derniers étages du pipeline, situés après les unités d'exécution. Tu devrais lire ce mémento sur le pipelining
http://arstechnica.com/old/content [...] ning-1.ars
Le fait de mettre les instruction dans le désordre suppose aussi des transistors de traçabilité des instructions. On en parle rarement, mais plus un pipeline compte d'étages et plus il faut de ces transistors. C'est un des facteurs qui plombaient le p4.
 
Les 4 étapes d'exécution classiques sont :
chargement (fetch)
décodage/répartition (dispatch)
exécution proprement dite
remise dans l'ordre/écriture en mémoire

Qu'appelles tu un shader exactement ?

 
Une unité vectorielle, par exemple un "CUDA Core" .
Le genre d'unité incapable d'exécuter les instructions x86, mais pouvant gérer très rapidement (bien plus que les cores x86, d'où la naissance du GPGPU) les opérations simples .

Sitôt qu'on a compris comment est fait un CPU, on se rend compte que tout ça n'est qu'un épais brouillard dû à un manque de perspective
 
Un "shader" comme tu le dis, c'est ni plus ni moins que plusieurs unités spécialisées mises côte à côte, pour au final être activées sélectivement par le biais d'une commande.
 
Si je donne à mon unité 1 la fonction d'addition et à mon unité 2 la fonction de multiplication, en fonction de l'opcode je pourrai exécuter l'une ou l'autre des opérations.
 
Contrairement à ce que tu sembles penser, un shader processor est proche d'un CPU in order complet, et au final une HD5870 contient donc pas moins de 20 processeurs capables de réaliser de 1 à 5 opérations par cycle par paquets de 16.
 
De son côté, un GF100 est composé de 16 processeurs capables de réaliser 2 opérations par cycle sur des paquets de 16 données.
 
Si tu reprends un schéma fonctionnel de CPU 8bits, tu verras un peu mieux ce dont je parle, et tu devrais au passage t'apercevoir que quelque chose a changé depuis lors dans nos chers CPU, et pas forcément dans le bon sens (à l'origine, le contrôleur mémoire en faisait directement partie...)

Si on réfléchit un peu, on se rend compte que l'écriture en mémoire est directe, puisque les instructions sont exécutées dans un ordre qui ne permet aucune confusion. Si un branchement a été mal prédit, le pipeline est simplement invalidé et re-rempli quand arrive la vérification, qui a quand même lieu avant l'obtention du premier résultat de la "mauvaise branche", tout du moins c'est comme ça que je l'ai compris.

Tu as raison, c'est bien expliqué ici, avec le système de queues :
http://en.wikipedia.org/wiki/Out_of_order_execution

D'ailleurs ça me fait repenser à cette hypothèse sur la convergence/divergence des threads potentiellement rendue possible par le décodeur global...
 
X threads sont envoyés au décodeur, qui mélange le tout et transforme ça en instructions "natives" (pas des µOps mais des "fronts de µOps" pour remplir les différents pipelines). Il est tout à fait possible d'augmenter sensiblement les perfs avec ce type de réorganisation et au final 1 seul des "cores" du module Bulldozer pourrait exécuter les X threads entrants, ou les 2 si nécessaire, sans jamais subir de pénalité contrairement au SMT.
 
Reste qu'ils doivent aussi améliorer les performances de leurs caches.

Le truc pour améliorer les perfs de traitement des macro-ops -> micro-ops, c'est d'utiliser la fusion de micro-ops et de macro-ops.
 
micro-ops: oad reg1,[mem32]
               add reg2,reg1
  fusion -> add reg1,[mem32]
 
macro-ops: cmp eax,[mem32]
                jne target
   fusion -> cmpjne eax,[mem32],target
 

Le tirage dans les pattes n'est pas une méthode productive, cher meussieu    

les Shaders sont des sous-programmes x86 codés en 32, 64 ou même 128 bits, afin d'être traiter par des processeur "super-scalaire" (sisi   ). Bon la on s'égare du bulldo'    
 
 
 

Je veux pas faire de la peine à ceux qui pensent que les SP d'un GPU ne sont pas d'une grande utilité pour un CPU, mais suffit de voir le super-ordinateur chinois doté de 2560 Radeon HD 4870 X2 pour comprendre que c'est la voie du futur. Sans compter que les chinois peuvent remplacer ces X2 par des HD 5970 pour doubler la puissance de calcul GPU sans consommer d'avantage, et avoir en prime l'OpenCL sur les Compute Shaders.
 
Un petit vidéo: ICI

Bon, je pense qu'il serait temps qu'on reparle un peu du petit Bulldozer...
 
AMD Valencia/Zambezi 8-Core (4 modules "Bulldozer" -> 8 INT / 4 FP)
 

trop petit

Oh my god !  
 
Il se pourrait que le 32nm de GlobalFoundries soit pire que le 65nm d'AMD !
 

Agena II le retour  

@NORADII
Pour rebondir sur l'histoire des fréquences qui plafonnent (le power wall : http://en.wikipedia.org/wiki/Multi [...] incentives ) et du multi thread, on pourrait ajouter qu'une certaine limite semble atteinte dans l'ILP (instruction level parallelism), et que cela oblige à passer à une échelle plus grande, le parallèlisme des threads, en tout cas pour les entiers (code riche en branches).
Parce qu'au lieu de rajouter des cores, on pourrait rajouter plus d'ALUs, mais il y a une limite aux performances, du fait que les ALUs glandent souvent lorsqu'elles sont en surnombre. D'où le SMT, et autre multitreadage.
 
Je vois le buldozer comme une approche intermédiaire entre l'ajout de cores complet et l'ajout d'ALUs. Cà n'a jamais été fait et il sera intéressant de voir le gain de performances.
 
@ TLM :
Si les GPU sont efficaces, c'est qu'ils s'occupent d'un code avec peu de branches. On aura toujours besoin de matériel généraliste à côté. Les GPU sont un gros plus pour les calculs "données intensifs", mais pour compiler un prog ou faire une IA, bah y a de la branche, du logique itou

Ohh my god !!!! bon ben faudra attendre le Bulldozer 2 alors comme ce fut le cas pour le premier Phenom

J'espère que c'est une plaisanterie ...  
Je redoutais ce facteur d'échec ... mais wirmish m'avait toujours affirmé le contraire .
 
Si le BD est une réussite architecturale, ça limitera peut-être la casse ...  
Parce que les Agena avaient un process moisi et une architecture largement perfectible .
BD n'aura que le process pourri . On progresse .

J'ai pas l'impression que ça soit particulièrement problématique avant un moment, et c'est ce qu'on retire des réponses des représentants d'IBM, qui disent grosso merdo "ça peut poser problème à l'avenir, mais on ne sait pas encore ce qu'il se passera et on devra probablement changer le process radicalement d'ici au 15nm, on conservera notre approche jusqu'au 28nm et on avisera pour les process suivants".
 
Donc pour résumer :
 
- problème impactant peu le 32nm
- changement radical à envisager pour le 22nm (dernier node avant le 15nm)
 
Il est même possible que cette approche soit la base du process 15nm malgré des prévisions à moyen terme péssimistes.

C'est IBM qui développe le process, alors moi je leur ai fait confiance.
Sauf que la news indique que GF, Chartered, Qualcomm, Toshiba, et quelques autres, ne sont pas satisfait des premiers échantillons.
Pourtant IBM continue de dire que le Gate First est plus simple...
J'ai maintenant tendance à croire GF au lieu d'IBM.
 
Reste plus qu'à prier.

"La vérité seule, le temps venu, nous dira quid de la raison ou du tort"

 
Fort heureusement, il reste encore bien six mois avant que le procédé ne soit officiellement prêt et utilisable à grande échelle .
Donc, pas la peine de s'alarmer pour le moment . Si d'ici quatre ou cinq mois les fondeurs ne sont toujours pas satisfaits de la qualité du procédé, le Bulldozer aura un handicap non-négligeable par rapport à son concurrent . J'espère que ce ne sera pas le cas .

Ca fait cb de temps que Intel n'a pas foiré un process ?
 
AMD n'a vraiment pas besoin d'un handicap vu son état financier... Et il en ont déjà avec TSMC...

En fin de 1999 à 2000 avec le 0,18µm et la transition aluminium --> cuivre pour les interconnexions.  
 
Quand pour faire l'évolution de son Pentium III (avec le cache L2 intégré à la puce), Intel s'est heurté à des rendements pas terribles au départ, et du mal à monter en fréquence. En face AMD, parti avec un peu de délai comme d'habitude (mais moins que les longs mois actuels) turbinait son Athlon 0,18µm à cadence de combat, 100 MHz par 100 MHz pour passer la barre du GHz avant Intel. AMD a très bien géré la transition aluminium --> cuivre, avec de bons rendements dès le départ.
 
Voilà deux processeurs qui, outre des performances comparables à fréquence égale ont joué du coude-à coude tout du long. Sauf que le Pentium 3 s'est vautré en poussant à 1,13 GHz, alors que l'Athlon Thunderbird a vaillamment atteint 1,4GHz. Et même 1,7 GHz pour l'Athlon XP en 0,18µm.  
   
 
 
Il aura fallu attendre le 0,13µm pour voir Intel reprendre les devants avec le P4.
Mais c'est le seul cas où c'est arrivé.
 

et la suprématie intellienne dura du P4 au Gulftown supplanté de loin par le vaillant Bulldozer  

Vente, peau de l'ours, tout ça...

Une autre news...

Je MàJ, merci