Reprise du message précédent :
Ces 2 produits ne visent pas le même public.
 
Fusion = M Toutlemonde qui se satisfont d'un IGP.
Bulldozer = Des mecs comme nous, et qui préfèrent une carte graphique puissance, et donc hors-CPU.

Nan mais je sais bien...
 
Intel a lancé un APU pour tuer la menace CUDA dans l'oeuf.
Et AMD emboîte le pas parce qu'en comparaison directe, ils sont sur un terrain gagnant.  
Avoir un soc qui consomme peu, pour qui n'a pas besoin d'un gros proc à huit threads, c'est bien.
 
Après qu'on vienne pas nous dire qu'en GPU computing ça va tout exploser grâce a une latence réduite proc-GPU !
Ou alors faut pas sortir bulldozer.
Là AMD montre qu'ils n'y croivent pas eux-mêmes...  

Y'aura quand même un Llano avec 4 cores et un IGP de la catégorie Redwood qui sera lancé au 2e trimestre 2011.
Quand on sait qu'un système a base d'Ontario faisait tourner Alien vs Predator en DX11 lors du dernier Computex...
Et quand on sait que l'IGP du Llano sera bien plus rapide que celui de l'Ontario, on ne peut pas cracher dans la soupe.

 
Tu maintiens ?
Sur bulldozer "le CPU passe son temps à sauter des cycles ... ce qui massacre les performances" ?

 
C'est surtout une question de gestion des risques lors du développement. C'est-à-dire des risques de se foirer, de devoir reporter la sortie du produit, etc. AMD a tout à fait l'intention de sortir un APU basé sur Bulldozer, mais dans un second temps.
 
— Llano :  
 

• nouvelle finesse de gravure = risqué
• core légèrement amélioré = pratiquement aucun risque
• premier APU = très risqué
• diverses technologies de gestion de l'énergie = relativement risqué

 
— Bulldozer :
 

• nouvelle finesse de gravure = risqué
• architecture radicalement nouvelle = extrêmement risqué
• diverses technologies de gestion de l'énergie = relativement risqué

 
Alors si en plus il fallait que Bulldozer soit un APU…
 
Il faut voir aussi que faire de Bulldozer un APU n'aurait vraiment d'intérêt que pour le HPC, parce que les particuliers préfèreront une grosse carte graphique discrète. Or, Bulldozer est avant tout un produit pour serveurs (web, base de données, etc.) , le HPC, en comparaison, ne représente qu'une faible part du marché. Donc dans l'immédiat, vaut mieux que Bulldozer ne soit qu'un simple CPU.

C'est surtout que bulldozer en version APU serait beaucoup plus faible, AMD ne peut pas faire que de l'entrée de gamme....
Le marketing peut tout faire gober, mais les benchs eux ne trompent pas.
 
La question c'est:  
pour faire du HPC, tu prends un APU à n coeurs ou un processeur classique à 2*n coeurs +carte graphique en PCI-E ?

 
Désolé, mais je ne comprends pas ce que tu veux dire, là.
 
 

 
Ça dépend. D'abord, ça dépend de ton budget énergétique. Mais ça dépend surtout de la granularité des portions de code très parallèle que tu veux exécuter. Déporter les calculs vers le GPU, ça a un coût en temps d'exécution, et ce coût dépend de la "distance" entre ton CPU et ton GPU.
 
Si tu as une carte graphique en PCI-E, ça signifie que le coût est élevé, donc le GPGPU n'a de sens que si d'une part tu as beaucoup de code parallèle, et d'autre part il s'agit de gros morceaux de code. En clair, perdre N cycles à faire des transferts CPU<=>GPU vaut le coup si tu gagnes 10N cycles en exécutant ton code parallèle sur le GPU, mais si tu perds N cycles et que tu n'en gagnes que N à 2N à chaque fois parce que tes morceaux sont trop petits, alors ça n'a pas grand intérêt…
 
Et dans ce cas, vaut mieux un APU, parce que le transfert de données du CPU vers le GPU prend ~10 fois moins de temps.
 
Note au passage que le choix serait plutôt entre :
A — 1 CPU à N cores + 1 GPU à M SP
B — 2 APU avec N/2 cores et M/(2~6) SP chacun
 
L'option B étant probablement un poil moins coûteuse…

1) Je veux dire qu'un bulldozer APU à 2-3 modules serait plus faible qu'un 4 modules non APU.
 
2) Tu négliges totalement les aspects BP mémoire qui priment largement. Pour l'instant on n'envoie que des "gros morceaux" pour que ça vaille le coup.
Mais quand tu parles de faible granularité, peut-être penses-tu que les processing units pourraient un jour se substituer aux SSE ?
Alors d'une ça ne concerne pas Llano, et deuxio une instruction cablée en dure sera toujours beaucoup plus efficace.
Suffit de voire les malheurs d'Intel avec larabee, programmer dessus des drivers Dx11 s'avère infiniment plus ardu que prévu.
Sans parler de la sous-couche logicielle supplémentaire.
 
3) Une plateforme bi-proc c'est couteux (même s'il n'y a pas de raison technologique à cela).
Dans le futur on pourrait imaginer des cartes mères multiprocs milieu de gamme ( par exemple avec 2 sockets et sans PCI-E).  
Mais pas pour Llano...
On peut aussi imaginer un multi-APU uni-die, mais tu restes à N/2 coeurs.
 
4) Pour moi l'idée de l'APU c'est, dans le futur, de bloquer le nombre de coeurs à deux ou quatre, et d'utiliser le TDP libéré pour augmenter le nombre de shaders. C'est déjà prévu dans les rodmaps Intel (ivybridge).
On aurait pu faire la même chose en soudant un proc à refroisissement passif à la carte mère (comme l'ATOM), et en commercialisant séparément (et à prix plus conséquent) des IGP encastrables, refroidis par ventirad.
Sauf que ça aurait chamboulé les repères du consommateur, et ça c'est pas bon.

Je ne suis pas sûr qu'on parle complètement de la même chose…
 

 
Dans l'absolu, rien n'empêche d'avoir 4 modules et un GPU intégrés, faudrait juste augmenter l'enveloppe thermique, ou réduire la fréquence. Mais dans un cas comme dans l'autre, ça n'a pas grand intérêt pour les marchés visés, à savoir le haut de gamme client, et les serveurs.
 

 
Oui, je néglige la mémoire pour simplifier, mais aussi parce que si un APU a entre 1/6 et 1/3 des SP d'un GPU discret, une interface mémoire de 256 bits devrait être suffisante. C'est démesuré pour le marché client, mais pas pour un APU conçu spécialement pour le HPC.
 
Reste qu'en supposant que la mémoire ne pose pas de problème — et c'est une grosse supposition, je te l'accorde — la question de savoir s'il vaut mieux un APU ou CPU + GPU discret dépend beaucoup de la granularité.
 

 
Je ne pense pas, en tout cas pas complètement parce que ça serait beaucoup plus lent pour du FP scalaire. Mais ce n'est pas là où je voulais en venir. Je dis simplement que si tu as une grosse portion de code parallèle, ça vaut sûrement le coup de l'exécuter sur un GPU discret, mais pas forcément si c'est une petite portion (genre quelques milliers de cycles) parce que le temps gagné sur l'exécution sera perdu sur le transfert des données du CPU vers le GPU, et dans l'autre sens.
 
Avec un APU, ça peut être rentable parce que ce transfert se fait bien plus rapidement, et ce même si ton GPU intégré est fatalement plus petit, et même si ta bande-passante mémoire est plus faible, d'autant qu'avec un peu de bol, tes données sont peut-être en cache, surtout que si la portion de code est courte, il y a des chances que les données soient relativement peu nombreuses.
 

 
Oui le bi-CPU c'est cher, mais je parlais de HPC, pas de Llano. Donc de toute façon, le multi-socket est quasiment garanti. De plus, tu peux toujours faire un MCM (donc avec 2 dies sur un seul socket) si tu veux limiter le nombre de sockets.  
 
Quant à Llano, il est fait pour remplacer tout ce qui est entre Athlon X2 + HD 4200 et Athlon X4 + HD 5570, voire HD 5670 grand max. Si tu veux quelque chose de plus costaud, faut un GPU discret. Mais, coup de bol (enfin c'est fait exprès, bien sûr), le segment [Athlon X2 + HD 4200 à Athlon X4 + HD 5570~5670] représente l'écrasante majorité du marché PC.
 

 
Et puis les performances dans tout ce qui n'est pas Embarrassingly Parallel seraient pourries du slip, la communication CPU <-> GPU serait lente et inefficace, la gestion d'énergie sub-optimale, la plate-forme plus coûteuse, plus grosse…

 
Ou 6 modules non APU...
Une architecture se compare forcément à TDP fixé, c'est la base quoi!
 
 

 
256 bits ???
C'est pas plutôt 2*64 bits (et en DDR3 au lieu de GDR5 ) ?
 

 
Ouais mais justement, je ne vois pas trop d'exemples de calculs suffisamment complexes pour ne pas être exécutes par les SSE, et portant sur suffisamment peu de données pour que le proc aie besoin d'un retour en quelques milliers de cycles seulement.
Les calculs lourds portent sur d'énormes matrices.  
Et puis ça voudrait dire qu'on a besoin d'éxécuter des instructions x86 au milieu du calcul, très bizarre tout ça    
 

 
Dans le cas ou tu aurais raison... Moi j'attends de voire des benchs (appropriés au supposé avantage de l'APU)  à nombre de shaders égaux entre APU et carte discrète.
 

 
Ba non, gravé à finesse de gravure égale, c'est la même chose. Y'a juste un bus en plus. Et encore chez INTEL ils ont été obligés de rajouter un bus vidéo proc/southbridge qui consomme encore plus et limite la résolution d'écran (2560*1600*32bits*60Hz de débit PERMANENT, ça ferait trop). Et puis le bus southbridge, a été suprimé depuis bien longtemps sur les IGP NVIDIA.
Après pour les tarifs, ça dépend juste du constructeur. On peut vendre un southbridge 2$ ou 40$ hein! Et les northbridges IGP des cartes à 35€ sont visiblement vendus moins chers que les northbridges sans IGP pour cartes haut-de-gamme...

 
Tout à fait, c'est pour ça que je dis que ça n'a pas grand intérêt, hors HPC !
 
 

 
Sur Llano, si, mais ce que je veux dire, c'est qu'un APU destiné au HPC pourrait tout à fait pousser à 256 bits, voire plus.
 

 
Je n'ai pas d'exemple concret à te donner, mais c'est ce qui ressort quand tu en parles avec des gens qui utilisent le GPGPU pour autre chose que des problèmes EP : "je passe tellement de temps à trimballer des données entre le CPU et le GPU que j'ai du mal à obtenir des gains significatifs". Rien n'empêche d'avoir quelques grosses matrices à multiplier avant de revenir à du code séquentiel, avec plein de branchements et autres saloperies, puis à nouveau des matrices, etc. Ça doit même être fréquent.
 

 
Ça dépendra des applications, de l'importance de la bande-passante, de la granularité… Mais si le CPU est un Atom comme tu le suggères, ça sera forcément pourri !
 

 
Les processeurs modernes (Nehalem et bientôt Sandy Bridge, Llano, Bulldozer) disposent d'une gestion d'énergie très avancée avec un composant dédié sur le die (Power Control Unit ou quelque chose comme ça sur Nehalem) avec de multiples sondes (numériques chez AMD, apparemment) qui permettent de mesurer la consommation de chaque core/composant à tout instant et d'adapter les fréquences et tensions en conséquence. C'est quand même vachement plus simple à faire (ou plutôt moins compliqué) si tout est sur le même die.
 
Après, je disais que la plate-forme serait plus coûteuse en partant du principe que la solution que tu évoquais était : CPU soudé + IGP dans un socket + southbridge soudé.
 
Donc là tu as 3 puces au lieu de 2 (APU + Southbridge) donc c'est forcément plus cher à produire, refroidir, plus gros, etc. Naturellement, tu peux intégrer le southbridge à l'IGP comme NVIDIA l'a déjà fait, mais dans ce cas tu limites sévèrement les performances de ton IGP, parce que tu vas mélanger de la logique et du cache (IGP) avec tout un tas de circuits analogiques (southbridge). C'est un mélange difficile du point de vue process, et ça impose des compromis pas forcément idéaux pour les performances graphiques. Ce n'est d'ailleurs pas pour rien que faire un SoC n'a rien de simple.
 
Et puis surtout, puisque ton IGP est sur socket, il faut qu'il soit parfaitement compatible avec tous les modèles de cartes-mères disposant de ce socket, ce qui est bien entendu impossible. Ou inversement, il faut que toutes les cartes-mères suivent le même standard imposé, et qu'il en aille de même pour l'IGP… Ce qui signifie que les fabricants de cartes-mères (qui s'en plaignent déjà) ne pourront plus se différencier de la concurrence, puisque toutes les cartes-mères seront essentiellement des clones d'un design de référence. De même, les fabricants d'IGP ne pourraient pas se différencier sur la partie southbridge.

 
Ouais mais ce qui est marrant c'est que justement, chez INTEL, le quad channel est réservé aux CPU sans IGP (y compris pour ivybridge qui aura un IGP plus puissant et DX11).
Chez AMD ça pourrait évidemment être différent. Bon on verra bien leur plateforme en 22nm, de toute façon la DDR3 arrivera sans doute en fin de vie.
 

 
Je veux bien te croire.
 

 
Nan mais ce que je voulais dire c'est que la partie CPU pour APU va stagner (en gros on va rester à 4 coeurs à moins de 4 ghz), en consommant de moins en moins au gré des finesses de gravure. Il arrivera un moment ou sur les 60W d'un APU, 15W seulement seront attribués au CPU.
 
 

 
Chez Intel, les APU sont réservés au grand public, donc le quad-channel serait bien trop coûteux. Le HPC passera par Larrabee, euh pardon, Knights…
 

 
Tu n'as peut-être pas tort là-dessus, c'est d'ailleurs l'avis de Jon Stokes : http://arstechnica.com/business/ne [...] ll-gpu.ars Pour ma part, je pense que les CPU vont continuer d'évoluer un peu, via des améliorations architecturales, des fréquences en hausse et plus de cores, mais ça va probablement ralentir. D'ailleurs, ça a déjà commencé. En 65 nm on avait déjà des quad-cores, et on aurait pu s'attendre à du 8-core en 45 nm, mais il faut se contenter de 4 chez Intel et 6 chez AMD (serveurs exclus). Et encore, AMD n'a introduit les Thuban que parce qu'ils avaient du mal à lutter avec 4 cores.
 
Cela étant, je pense que le concept de "fréquence nominale" va bientôt disparaître, et de fait, il sera difficile de dire combien de W sont attribués au CPU sur un TDP de 60 W. En revanche, on pourra toujours dire quel pourcentage de surface lui est attribué sur le die… du moins dans un premier temps, avant que la fusion ne soit complète.

Bof c'est pas avant 2 ans, et de toute façon ça ne s'imposera pas...
 
Ici t'as une comparaison avec fermi :
http://www.hpcwire.com/features/Co [...] tml?page=3
Sauf que dans le tableau, ils comparent 16 unités SIMD nvidia (à double fréquence) à une unité vect16 intel  

Qu'est-ce qui te choque là-dedans, au juste ? Pour ma part je parierais plutôt sur Knights que sur Fermi(2) pour le HPC…

Ba une unité vectorielle, c'est peu couteux en transistors, mais ça manque énormément de souplesse. AMD a du mal a les remplir, mais c'est pas grave car ils en mettent 320 (vect5 en 40nm).
Du fait de la gourmandise du x86, Intel ne peux en placer que 32 ( ou 50 en 22nm). Y'a pas photo...
Et puis un bus circulaire, ça a été abandonné depuis longtemps par les concurents.  
Bref le seul atout d'Intel serait une plus grande facilité de programmation. Mais Nvidia planche sur CUDA depuis un bon bout de temps déjà, donc j'y crois pas trop...

 
Ben Larrabee contient 32 cores vec-16, donc si tu comptes comme NVIDIA compte ses "CUDA Cores", ça fait 512, comme GF100, sauf que chez Intel ils sont tous activés…
 
Quant au ring bus, ça a l'avantage d'être facilement scalable, et d'offir un débit important. Intel a aussi un avantage important par rapport à NVIDIA, et dans une légèrement moindre mesure AMD : le process de fabrication !

Je crois que tu n'a pas tout à fait compris....
Alors on reprend tout, même si on est pas dans le bon topic...
L'idée de base du GPU computing, c'est d'accélérer le traitement d'un même motif de calcul, mais appliqué a de nombreuses données.
L'ordre de traitement des données indiffère, il n'a donc pas de dépendances, et l'on peut fortement threader la chose.
 
Une SIMD AMD traite ainsi 16 threads SIMULTANEMENT, une SIMD NVIDIA 32, sans compter que la fréquence est double (plus tout à fait vrai).
Un core INTEL traite 4 threads de façon ALTERNATIVE, afin que son unité vectorielle soit la plus souvent possible utilisée. Attention, "utilisée" ne veut pas dire "remplie". Elle traitera des vecteurs de taille 1 à 16, mais on sera très souvent plus proche de 1 que de 16. Aux mieux, l'efficacité réelle d'un vect16 pourrait être le double de celle d'un vect5 (soit le qradruple d'une unité scalaire).
 
Indice de performance:
- Nvidia: 16*32*2
- AMD: 20*16*2
- INTEL:32*4

doublon

 
Oula… Alors effectivement, un core de Fermi (NVIDIA appelle ça un Simultaneous Multiprocessor, ou SM pour faire court) peut gérer simultanément 1536 threads, soit 48 warps de 32 threads chacun, et peut exécuter 2 warps en même temps… mais ça ne fait jamais que 2 instructions, puisque c'est du SIMT et il faut donc appliquer la même instruction à chaque thread au sein d'un warp. Le tout à 1,15 GHz sur Tesla.
 
Un core de Larrabee applique une instruction à 1 thread sur 16 données en même temps, ce qui n'est pas très différent, d'autant qu'il y a 32 cores, contre 16 SM (dont seulement 15 activés) sur Fermi. Et tout tourne à 1,2 GHz sur Knights Ferry…
 
Ce n'est pas le nombre de threads qui donne la mesure des performances !
 
 
PS : ce n'est pas complètement le mauvais topic, puisque les futurs APU d'AMD seront en concurrence pour le GPGPU avec ce qui naîtra de la "fusion" de Knights et, sans doute, le successeur de Rockwell.

Oui bon pour les fréquences ça dépend de la gravure, du nombre d'unité, du TDP souhaité... Donc OK partons sur une même fréquence Larrabee/ shaders TESLA.
L'histoire des 2 warps "simultanés" (en réalité alternés), je suppose que c'est pour remplir au mieux le bouzin, l'équivalent de l'hyperthreading chez INTEL.
Il n'empêche que quand tu traites 32 threads SIMULTANEMENT (avec 32 unités physiques), tu te moques que se soit sur une même instruction ou non, tu divises le temps global d'éxécution par 32 (un coeur larrabee aura lui a la traiter 32 fois)!  
Bon évidement faut que le programme se prête à 48*32 threads...
 
INTEL a peut-être espoir de fusionner des threads identiques, via compilateur, pour former de longs vecteurs.  
Dans ce cas il perdraient beaucoup en souplesse...
Bref on leur souhaite bien du courage!

 
Sur Fermi tu as bien 2 warps exécutés simultanément, chacun sur un sous-ensemble de 16 "CUDA Cores" :
 

 
Naturellement, c'est exécuté en 2 passes, mais peu importe, tu as bien 32 opérations par cycle et par SM. Throughput is king.
 
Mais comme je disais, les performances ne dépendent pas que des threads. Ce qui compte, c'est le nombre d'opérations effectuées. Sur Fermi, tu as 32 FMA par cycle et par SM, et tu as 14 SM activés. Soyons gentils avec NVIDIA et supposons qu'ils arrivent un jour à obtenir des yields suffisants pour commercialiser un GF100 complet. Ça nous fait donc :
 
32 FMA × 16 SM = 512 FMA, soit 1024 opérations puisque par convention, 1 FMA = 2 ops. Tu multiplies ça par la fréquence, disons 1,2 GHz parce qu'on a décidé d'être gentil, on a dit, et tu obtiens 1 228 GFLOPS (1 030 sur le vrai Tesla).
 
Sur Knights Ferry, chaque core est capable d'exécuter un FMA vec-16 par cycle, et il y a 32 cores à 1,2 GHz. Soit :
 
16 FMA × 32 cores = 512 FMA, soit 1024 opérations, soit… 1 228 GFLOPS à 1,2GHz.
 
Edit pour répondre à ton edit : non, Intel n'espère pas fusionner des threads, mais tout simplement les vectoriser. Un thread n'est pas intrinsèquement vec-4 ou vec-16 ou vec-50000, tout dépend de comment il est codé. Et NVIDIA a le même problème, parce que d'accord chaque "CUDA Core" exécute son propre thread, mais il faut quand même que l'instruction soit commune. Finalement ça ne change pas grand-chose par rapport à du SIMD classique (LRBni en l'occurrence).
 
 
 
Tout ça pour dire que Fermi ne crée pas plus de parallélisme que Larrabee, comme ça, par magie. Le parallélisme intrinsèque est le même, et là où Intel opte pour la vectorisation (ça consomme moins de silicium) NVIDIA préfère les threads, parce que c'est plus souple et plus transparent pour le programmeur. Et comme ils essaient de s'imposer sur un nouveau marché, qu'ils ont pratiquement créé, la souplesse a du sens…

Si tu considères qu'on peut facilement "vectoriser" des threads, et donc considérer les GFLOPS théoriques maximaux comme réellement utilisables, alors l'architecture AMD est environ 2.5 fois plus performante que celle de NVIDIA. Et en faisant des vecteurs plus longs à peu de frais, la différence se creuserait encore.
 
Sauf que ce n'est absolument pas le cas...
Pour l'anecdote, un bench qui remplit les vect5 des cartes AMD et exploite ainsi les Gflops ultra théoriques indiqués sur la boîte est considéré comme un virus par le constructeur. Il fait sauter les mosfets de l'alim, qui ne sont pas dimensionnés pour...
 
Quant-à Intel, ils n'optent pas pour du vectoriel de plein gré.
Ils sont partis sur des coeurs x86 qui sont donc carrément des coeurs de processeurs, certes simplifiés.
Avec la cache L2, ça occupe la moitié de la place d'un bloc entier chez Nvidia. Ils ont rajouté une unité vectorielle, seule solution pour augmenter la puissance théorique à peu de frais. Mais l'efficacité de l'ensemble reste douteuse.

 
Vectoriser des threads n'est pas facile, mais threader une application non plus… surtout quand il faut vectoriser ton threading ! Sur un demi-SM de Fermi tu as beau avoir 16 threads différents, si tu ne peux pas exécuter la même instruction sur les 16 threads en même temps (ce qui revient à vectoriser) ben tu peux pas exécuter sur tes 16 threads d'un coup. NVIDIA dit que ses "CUDA Cores" sont scalaires parce que ça fait classe, mais ce n'est vrai que du point de vue des threads, pas de l'exécution.
 

 
Furmark, par exemple, est effectivement considéré comme un power virus (note que sur Evergreen il ne pose pas de problème de mosfets). Mais c'est parce qu'il charge tout à fond : shaders, TMU, ROP…  Il y a de "vraies" applications GPGPU (qui, forcément, ne touchent pas aux TMU et ROP) qui s'approchent du maximum théorique. Prunedtree a réussi à faire péter la barre du teraflops sur RV770, le max théorique étant, pour rappel, de 1,2 TFLOPS: http://forum.beyond3d.com/showthread.php?t=54842 C'est loin d'être facile, mais c'est faisable.
 

 
S'ils sont partis de cores x86 c'est aussi pour avoir quelque chose de complètement programmable dès le départ. De même, s'il y a 8 Mo de cache L2 (à comparer avec 768 ko sur Fermi, de mémoire) c'est parce qu'ils ont voulu le mettre, en sachant très bien quelle taille ça ferait. L'utilisation de vecteurs est un choix, et j'irais même jusqu'à dire qu'elle est assez "normale", c'est la solution de NVIDIA qui est plutôt atypique.
 
Au passage, je ne serais pas surpris que Knights Ferry consomme un peu moins que le plus gros modèle de Tesla…

Moi je veux bien, mais comment tu compares les 320 unités (1600PU) des HD5*** aux 32 unités (512PU) de Larrabee ?
 
Edit: ok tu va me parler des nombreux threads nécessaires chez AMD...
 
N'empêche j'ai jamais entendu dire que les unités scalaires Nvidia étaient mal remplies.
La puissance réelle est très proche de la limite théorique non?

 
Ben chez AMD c'est du vec-5, ou plutôt du vec4+1 puisque seule l'unité T est capable de faire certaines opérations, et en plus c'est du VLIW. Mais en réalité, le "core", chez AMD, c'est plutôt ce qu'ils appellent les SIMD-engines (y'en a 20 dans Cypress) parce que c'est là que la logique de contrôle se trouve. Celle-ci envoie des VLIW à chacune de ses 16 unités vec-5, donc faut pas s'étonner que l'efficacité ne soit pas toujours optimale.
 
Si t'as un peu de temps devant toi, lis ça ( http://bps10.idav.ucdavis.edu/talk [...] PH2010.pdf ) c'est court et simplifié, et ça donne une petite idée du fonctionnement du GPGPU en général et de GF100 et Cypress en particulier.
 

 
C'est parce que si tu compares Fermi à tous les autres GPU, a fortiori ceux d'AMD, l'utilisation est bonne, relativement. Mais dans l'absolu, dans la grosse majorité des cas, on est bien loin des 100 %.
 
Exemple concret, parmi bien d'autres : http://www.realworldtech.com/page. [...] 001641&p=6  
Cf. "Figure 11". Comme tu vois, on est souvent loin du gain théorique.

J'avais déjà vu l'article de realword, bon il est évident que le GPU computing c'est pour du calcul lourd avec un programme dont le patern  s'y prête.
 
Le pdf est intéresant, merci. Je vais regarder ça posément.
 
 

Salut, je remonte le fil mais ça n'a rien à voir avec les annonces récentes du hot chips 22
 
Je cite cet article du 16 Juillet :

 
Le proco intel d'entrée de gamme de la génération Sandy Bridge, le double-coeur (+HT) Core i3 2100T, aurait selon une souce fuitée un TDP annoncé à 35W. Je pense qu'il sera plus musclé au niveau CPU, avec un IGP faiblard probablement, et il faudra une nouvelle carte mère à cause du changement de socket (LGA 1155).
Il faudra attendre pour voir, mais pas sûr que si on s'intéresse davantage au rapport perf / dégagement thermique, la comparaison soit en faveur du "high-end dual-core" Llano face à l'i3, certes qui sera plus coûteux (et privé du turboboost).
Il faudra aussi peser l'impact des plus que sont l'USB3 / SATA 6Gbps et de fusion.

Les I3 d'Intel se comparent aux X3 d'Xmd, question de logique.
C'est le pentium (sans HT) qui se place en face du X2.
 
Enfin bref tu auras sans doute des llano X3 basse consommation 45W, voire moins, avec une fréquence pas trop amputée.
 
Au niveau des coeurs, le rapport perfs/conso ne sera vraiment pas très éloigné de celui d'Intel pour peu que le 32nm de GF soit à la hauteur.
Au niveau des unités du gpu, la y'a vraiment pas photo...

C'est raté pour AMD... Microsoft offre le 1er APU: LIEN
 

Ouais… enfin bon, il est peut-être même pas plus puissant qu'Ontario, donc y'a pas tellement de quoi s'enflammer.

 
Latence du cache - L1 = 3 cycles
                        - L2 = 17 cycles
 
Atom - L1 = 3 cycles
        - L2 = 16 cycles
 
VIA Nano - L1 = 4 cycles
              - L2 = 24 cycles

La latence des cache est surtout primordiale pour l'ATOM qui est in-order.
 
Bon le 40 nm bulk c'est pas terrible, ça ne vaut même pas le vieux 45nm Hk d'Intel (introduit fin 2007).
AMD a t-il évoqué un éventuel die-shrink en 28nm Hk, et en quelle année?

Il n'est pas évoqué, mais il est clair que c'est prévu.
 
Selon moi ça se produira dès que les yields du 28nm de GF seront stabilisés à ~70%, et que la capacité de production sera suffisante, car les GPU risquent d'occuper le terrain, surtout la première année. Je dirais donc qu'une nouvelle version arrivera au début de 2012, mais que ce ne sera pas un simple shrink puisque le 40nm ne se "shrinque" pas en 28nm.

C'est pas une question de rendements.
Les problèmes de rendement c'est valable pour les très grosses puces (gros GPU), et encore avec le système d'unités redondantes/désactivations d'unités, ça n'est plus vraiment critique.
Pour un petit truc comme ontario, les rendements sont toujours bons.
C'est juste une histoire de planning commerciale.

Sauf que le Fusion Llano (ce topic) existe aussi en quad-core + IGP, ce qui donne une puce qu'on peut difficilement décrire comme étant petite.

Oui mais là on parlait du 28nm, donc aucun rapport avec Llano.

salut tous

Une p'tite question par rapport aux APU de AMD :

maintenant qu'on a un GPU et un CPU sur le même die et tout ça, on a plus besoin de carte fraphique alors Si ?

PS : merci zack pour le message

T'as tout compris, c'est d'ailleurs l'intérêt de Llano...

 
Bobcat est censé être facilement "synthéthisable". Ça devrait faciliter le passage à 28 nm.
 

 
Voilà, sauf si tu cherches des performances élevées. En d'autres termes, si tu mets 100+ € dans une carte graphique en plus, tu y gagneras en performances.

Le Fusion d'AMD est mieux d'être très performant pcq le Sandy Bridge est une bombe !