Reprise du message précédent :
 

C'est expliqué en 3 lignes quelque part au milieu d'un foutoir indigeste typique des brevets, l'agencement physique au sein du die de RAM est remanié pour limiter la longueur/complexité des traces, mais fondamentalement y'a rien de nouveau, les mêmes blocs sont utilisés de la même façon, simplement agencés différemment.
 
Edit: page 8, section 0038. Les 2 sections antérieures résument la problématique et l'objectif, c'est à dire la totalité des 10 pages.

Ne nous éloignons pas trop du topic.
 
Mon petit écart sur la DRAM c'était que pour répondre à Gigathlon et au problème de bande passante qu'il a soulevé à la page précédente.

C'est clair que l'APU a du potentiel, maintenant il faut voir si il va se concrétiser...

 
AMD va dévoiler son Fusion demain au Computex !
 

DÉVOILEMENT DU FUSION
(Bah oui, en asie c'est déja demain!)
 
 
Quelques posters sur les murs :
· "The best it's ever been"
· "Responsive power make media rich ..."
 
"Good morning ladies and gentlemen... bla bla bla..."
 

 
NOTE: La musique de style "ascenseur" me tape sur les nerfs...
 
Bon ça y est, c'est commencé, avec 10 minutes de retard.
Elle est jolie la demoiselle qui parle au micro.
 
Y'a 2 zigotos qui frappent sur des tambours.
Un 3e se met à frapper un gros tambour sur le mur.
Un peu de flûte... et une jolie bouche.
 

 
Quelques slides qu'on va bientôt retrouver dans un PDF.
 

11 millions de GPU DX11 ont été vendus.
Bof, y'a pas de quoi fouetter un chat.
Surtout quand on sait qu'il se vend +400 millions de GPU par année.
 
Une PUB -> LIEN
 
Rick Bergman arrive enfin...
 
Slide à propos de l'APU Ontario :

Des samples de l'Ontario sont présentés dans une salle privée.
 
C'est officiel, le Llano sera dispo au 1T 2011.
 
On a la visite d'un mec de Microsoft.

 
Démo de l'Ontario avec Alien vs Predator en DX11 -> LIEN
 
· Démo d'une lecture BlueRay en 3D.
· Démo EyeFinity avec 3 moniteur à partir d'un portable.
· Démo EyeFinity avec 5 moniteurs.
 
C'est fini.
Bof, bof.
 
Le marketing c'est pas le point fort d'AMD...

Outre le passage sur AvP, qui est assez ridicule soit dit en passant... tes 400M de GPU ça intègrerait pas les IGP par hasard?

Et oui. Mais, bon, vois-ça comme tu veux, mais le Llano c'est aussi un IGP non ?
 
 
Note: À l'heure qu'il est, seul HFR a écrit une news sur Fusion -> ICI

Il a été trop gentil le Tridam, la présentation était quand même risible
 
Déjà, une vid d'AvP qui rame clairement même si c'est pas là que j'attend ces APU, et pour finir, parler d'un bouleversement de l'industrie en reprenant le "modèle" Intel pour Sandy Bridge (heureusement, ils n'ont pas repris l'échange de mails comme un truc que l'APU améliorera ), citant uniquement le visionnage de vidéos et l'upload d'images sur le net...

Le vidéo rame car je l'ai filmé en 10 FPS.
 
D'un côté AMD a montré que son Llano peut faire tourner AvP en DX11 à 20~30 FPS.
De l'autre côté Intel a montré que son Sandybridge fesait tourner le début de Mass Effect 2.
 
C'est donc pas gagné pour AMD.

J'ai pas regardé que la tienne

T'as un lien HD pour nos copains ?
V'la le lien -> YouTube
 
 
Mise à jour:
 
     L'APU qui fait tourner AvP c'est le petit Ontario pour netbook.
     Ça fait tout une différence !

 
     Confirmation officielle par AMD :

AMD Fusion (Ontario ou Llano) et Internet Explorer : VIDEO
 
CPU : ~1 FPS
APU : ~55 FPS

Bon arrétez vos histoires d'APU révolutionnaires.
Tout le monde ici c'est que c'est un nouveau nom commercial pour dire gpu en plus du cpu, et toi le premier Wirmish.
Qu'on puisse faire du gpu-gpu computing sur un gpu, ça n'a rien de nouveau, c'est comme ça depuis plusieurs années.
Si vous voulez un APU, il suffit d'acheter un processeur Atom et voilou.

Faut bien commencer quelque part...
 

 
... pour qu'un jour, pas trop lointain, le mot "APU" gagne tout son sens.

C'est pas tout à fait exact, mais c'est clair que pour le moment on ne peut pas parler de révolution comme l'a fait le PR d'AMD...
 
Le concept "APU", c'est pas "juste un CPU et un GPU dans le même die", mais mettre ces 2 composants en symbiose. Est-ce que cette première itération sera convaincante, c'est pour le moment impossible à dire, mais le potentiel est là.
 
La prochaine étape a été annoncée pour 2015 et devrait consister en une fusion des 2 archis 2011 (Bulldozer et Llano, des SIMD de GPU côtoyant sinon remplaçant la FPU), Intel va également dans cette direction d'ailleurs à en croire les derniers slides.

 
Tu peux expliciter le concept de "symbiose" ? Un gpu non APU fonctionne-t-il en parasite du CPU?
Bon sérieusement, à part réduire un peu  les latences d'accès en mémoire, aucun autre intérêt.
 
Au niveau logiciel, c'est sure qu'ils faut qu'ils bossent, ils ont pas mal de retard sur CUDA.
 
L'idée de dispatcher les SIMD aux coeurs des CPU ne me paraît pas bonne.
Si chaque coeur dispose de x et seulement x SIMD attitrées, c'est pas un système très souple.  
Certaines seront sous utilisées tandis que d'autres seraient insuffisantes.

On est pas dans Stargate ici, le terme symbiose n'a aucun lien avec le fait de parasiter un hôte, c'est même tout l'inverse...
 
Le terme symbiose est défini comme 2 organismes profitant chacun l'un de l'autre, sans contrepartie à l'inverse du parasitisme. L'intestin est par exemple un milieu symbiotique où diverses bactéries nous permettent de digérer ce qui sinon irait direct au centre de retraitement des eaux.
 
Actuellement, le GPGPU requiert beaucoup de transferts CPU <-> GPU, l'APU est sensé permettre le GPGPU sans avoir ce défaut (dans un premier temps), puis de rendre la chose transparente (2015, si ça ne fait pas long feu).
 
Pour la 2e génération, il pourrait simplement s'agir d'une extension de l'ISA pour prendre en compte la criticité d'une tâche (critique = séquentiel = CPU, pas critique = IGP), que ça soit par une instruction (ou une suite d'instructions) précise qui indique un changement de "politique" local (façon SSE) ou des instructions "en double" selon l'unité de traîtement préférée.

 
J'ai dit le contraire?  
 

 
Absolument pas d'accord, ça c'est du discourt de marketeux INTEL/AMD.
La vérité c'est que la bande passante CPU/GPU est totalement surdimensionnée, y compris pour les GPU haut de gamme, donc pour un IGP...
Par contre le CPU a beaucoup de boulot pour préparer les données pour le gpu (via les drivers). Mais ça on y peut pas grand chose...
 

 
Je suis pas compétent pour ça.

Malgré tout, on peut observer que les infos Llano qui sont données indirectement sont plutôt bonnes . En effet, si Ontario, la version netbook de Llano, arrive à faire fonctionner AvP à 30ips, que dire de la version desktop ? Les résultats doivent être encore meilleurs, ça ne fait aucun doute .
 
Vivement la suite

Le fait est que le "boulot pour préparer" peut en grande partie être composé du simple temps de transfert.
 
Le sample BasicCompute11 du SDK DirectX par exemple transfère 2 tableaux de 1024 éléments (1 uint + 1 float), effectue 2 opérations sur chaque couple d'éléments (tableau1[x].i+tableau2[x].i et tableau1[x].f+tableau2[x].f) et récupère un 3e tableau de 1024 éléments.
 
Bilan: transfert hôte -> GPU de 2048*8=16384 octets, transferts GPU -> hôte de 1024*8=8192 octets, le tout pour 2048 opérations (soit 12 octets par flop en simplifiant très peu)... c'est tout simplement énorme, et même si ça n'est pas une charge type pour le GPU elle n'en reste pas moins possible et une charge pratique peut par exemple tourner à 1 octet/flop, ce qui reste énorme.
 
Unifier l'espace mémoire CPU/GPU permet de réaliser la même tâche sans le moindre transfert, un pointeur est mis à jour et les données peuvent être accédées directement.

Je pense que dans ton exemple, le CPU communique au GPU l'adresse mémoire des deux tableaux de données et l'opération à faire. C'est tout. Au gpu d'aller chercher tout ça en RAM, d'où le besoin de BP mémoire.
 
Au passage pour des opérations aussi simples, un CPU à plusieurs GHz n'a pas vraiment besoin de la puissance d'un gpu.  
Le cell paraît parfaitement adapté pour un tel traitement léger de données.

Que le GPU aille chercher en RAM ou qu'on lui envoie, quelque part c'est du pareil au même
 
Après, pour des cas pratiques il faudrait décortiquer le code résultant d'un shader plus intéressant, mais il restera toujours ces inutiles transferts qui n'existeront pas sur Llano et Ontario, tout du moins si les représentants d'AMD n'ont pas tout simplement menti.

 
Ba non dans un cas ça dépend de la bande passante mémoire ( partagée*), dans l'autre du bus hypertransport (celui que l'on veut supprimer parceque soit disant ça va tout changer).
 
Bon comme chez AMD le contrôleur mémoire est dans le CPU, tu as raison, il faut de toute façon passer par l'hypertransport. Le truc c'est que la DDR3 à une BP de 10Go/s alors que l'hypertransport peut lui encaisser 40go/s.
dans ton exemple, pour exploiter à fond les flops de ton gpu, il faudrait peut-être de la DDR7 en hexa channel . Et là oui l'hypertransport serait trop juste. Bref c'est pas pour rien que les cartes graphiques ont des gros bus mémoire....
 
Certes pour la consommation c'est jamais mauvais d'intégrer un bus sur le die. Le problème c'est que chez Intel ça les oblige à en créer un autre (sortie vidéo), qui lui transporte beaucoup plus de données, et donc consomme plus.
 
Après pour les "promesses" d'AMD, ba oui un IGP de 240-480 shaders en 32nm Hk, ça va pulvériser tout IGP existant  (les précédents sont à 40-80 shaders en 55nm!) sans consommer trop, mais ça c'est du à l'évolution des finesses de gravure, pas à une "révolution" architecturale...
 
* rapprocher l'IGP du contrôleur mémoire, c'est bon pour la latence, mais ça empêche de pouvoir câbler une puce de GDR5 en sideport beaucoup plus efficace.

Le vrai problème c'est pas la bande passante mais la latence.
 
Il faut synchroniser les "discussions" entre le CPU et le GPU, car si le CPU passe son temps à sauter des cycles parce qu'il attend les données du GPU et vice-versa, alors ce qui aurait dû nécessiter 100000 cycles, dans le meilleur des mondes, en prend alors 10 fois plus. Le CPU n'est pas synchro avec le GPU, et les communications entre les 2 passent par trop d'étapes (cache L1/L2, contrôleur HyperTransport 3, contrôleur PCIe), ce qui massacre les performances. Il faut donc éliminer ces intermédiaires, ou trouver un moyen d'optimiser les échanges CPU/GPU.

Ok je comprends ce que tu veux dire.
 
Mais apriori on utilise le gpu soit:
- pour un calcul très lourd ( puissance du gpu en facteur limitant)
- pour un calcul portant sur de très nombreuses données (BP mémoire limitante)
- généralement les deux.
 
Pour la petite intendance, le CPU se débrouille tout seul avec ses ALU et FPU, sinon ça devient un enfer à programmer.

Sauf que Llano est loin d'être l'aboutissement du projet Fusion : c'en est le début . AMD va donc tâcher, à partir de cet APU, de développer les outils permettant de tirer parti d'une telle architecture ... un peu comme Intel commence déjà à envisager la programmation très massivement multicore (avec ses CPUs à 48 ou 50 core) .

Un core de Llano :
 

Pas delL3 ?

C'est juste un core pas un die complet.

Ah, pardon j'avais pas vu. Et effectivement il manque la partie GPU

 
Par ailleurs, le die révèle 1Mo de mémoire cache L2, mais cette information reste à prendre avec des pincettes : en effet, ça paraît être une bonne quantité de mémoire cache L2 pour un Llano dualcore, mais je pense que les quadcore seront équipés de 512Ko de mémoire cache L2 par core .

Ah, dans ce cas le die ne serai pas le même

Si y'a pas de L3, le L2 ne bougera pas
 
Sans compter qu'il est assez peu probable que Llano ait un L3 d'après les infos qu'on a.

S'il n'y a pas de mémoire cache L3 . Mais là-dessus, on n'a pas beaucoup d'infos, justement ...
 
Je crois me souvenir qu'AMD avait un jour parlé de L3 partagé entre le CPU et le GPU pour Llano ! Ou alors peut-être que j'imagine hum hum

Ba 1Mo de cache L2 et pas de L3 (qui ne sert pas à grand chose), c'est les infos qui ont toujours circulé.
En fait je crois qu'AMD double la L2, plus pour économiser de la BP pour le GPU que pour améliorer les perfs du CPU.
Enfin bref c'est plutôt logique.

Sauf erreur de ma part, les Phenom II profitent bien de leur cache L3 . Pourquoi en priver Llano ? Malgré le gros cache L2, ça pourrait être intéressant pour les modèles quadcore . C'est pour ça que je pense à deux die différents, l'un avec 1Mo de L2 par core et pas de L3, et l'autre avec 512Ko de L2 et un L3 . Evidemment, les ALU GPU seront en quantité différentes entre les deux die, histoire de marquer la différence entre les deux ... bref, comme le die Sempron et le die Athlon II X3, quoi .

La version de Llano qui a été montrée pour le moment n'a pas de cache L3, ce qui n'a rien de surprenant pour un produit "mainstream" et dispose de 1 Mo de L2 par core, soit 4 Mo. Il y aura peut-être une version dual-core (pas sûr du tout) mais très probablement pas de version plus haut de gamme avec un cache L3.
 
Le cache L3 fera peut-être un retour en 2012 avec un APU basé sur Bulldozer...

+1 Ca n'a rien d'étonnant

Pourtant, les actuels quadcore d'AMD ont bien un cache L3 .
Pourquoi pas Llano ?