Reprise du message précédent :

Problème:
 
- la connexion maître/esclave nécessiterait au minimum un bus 64bits
- le maître devrait disposer d'une interface 512bits avec la RAM
 
=> à 150mm² il est rigoureusement impossible de caser 1024 connexions uniquement dédiées à la communication.

http://forum.hardware.fr/forum2.ph [...] w=0&nojs=0
 
Venez ici pour parler de LARRABEE ou de la puce HYDRA, ça y sera bien mieux ... ici, ce sera bêtement perdu .

Non, c'est plutôt l'inverse.
 
HD 5450 -> 640 SP + 16 TMUs (1 master chip) -> 150mm²
HD 5650 -> 1280 SP + 32 TMUs (1 master chip + 1 slave) -> 250mm²
HD 5670 -> 1920 SP + 48 TMUs (1 master chip + 2 slaves) -> 350mm²
HD 5850 -> 2560 SP + 64 TMUs (1 master chip + 3 slaves) -> 450mm²
HD 5870 -> 3200 SP + 80 TMUs (1 master chip + 4 slaves) -> 550mm²
 
Une HD 5870 serait donc l'équivalent d'un CrossFire de HD 4870-X2 fonctionnant à au moins 80% d'efficacité.
Le tout avec 5 puces d'une taille totale de 550mm², ce qui est plus petit que le G200 original (576 mm²).
 
Coût de production en baisse: 2 puces différentes permettraient d'offrir toute la gamme de carte graphique.
Petite taille, donc plus de puces par wafer, yields plus élevé, moins de perte, profit plus élevé ou prix plus bas.
 
Possibilité de mettre en marché toute la gamme de carte graphique simultanément.  
 
Défaut: Concept un peut trop avant-gardiste. AMD préfère sans doute ne pas trop s'éloigner des GPU habituels.

Regarde mon concept plus attentivement (les images aussi) -> Beyond3D
 
Mon concept utilise le bus FlexIO développé par Rambus et licencié par AMD en 2006 pour 75 millions de dollars.
 
Ce bus est capable de fonctionner à des fréquences comprises entre 400 MHz et 8 GHz.
· Le bus ne possède que 12 traces (5 en entrée/7 en sortie), soit 48 traces au total pour relier les 4 puces esclaves.
· La bande passante théorique est de 76.8 Go @ 8 GHz (32 Go en entrée/44.8 Go en sortie)
· Bande passante totale: 76.8 Go/s x 5 puces (1 interne + 4 "esclaves" ) = 384 Go/s
 
La puce maître n'à qu'à utiliser un bus de 384 bit de GDDR5 standard à 0.4ns, soit des puces à 1250 MHz (5,0 GHz effectif), pour une bande passante totale de 240 GB/s, ce qui est à mon avis amplement suffisant.
 
L'année prochaine, lors du passage au 32nm, AMD pourrai revenir à un bus de seulement 256 bit, mais en utilisant de la GDDR5 en mode différentiel, qui devrait être dispo au 1er trimestre 2010. ce qui permettrait alors de dépasser les 300 Go/s.
 
Il n'y a donc aucun problème de "pins trop nombreuses" avec mon concept.
 

 
Justement, vue comment Intel en parle ça à l'air super simple, alors pourquoi c'est si compliqué de faire faire le travail par 2 puce ?

Tout simplement pcq y'a 2 têtes qui pensent au lieu d'une seule.

J'y connais rien, mais avec un dual core il font comment ?

 
 
on peut pas dire qu il pense souvent à la meme chose pour le moment
 
la parallelisation d'un processus est pas toujours simple
 
le rendu raytracing et l encodage video en profite fort heureusement pour moi

Le concept de dual cores est vague pour une GPU, car les calculs graphiques sont disons "multithreadés" et les GPU actuels sont développés autour de ça.
Pour faire simple, le coups des Stream Processors, c'est juste de mini GPU mis à coté les un des autres et partageant un certain nombre de choses (mémoire, controleurs etc...)

Donc le Dual core est une chose bizarre, car il "suffit" de rajouter des grappe de SP dans le GPU.

Par exemple, le Larrabee est un processeur "classique" fortement multicore du fait du type de calculs qu'il fera (du graphique).

Edit : mon explication est simpliste, je le reconnais

Je crois qu'il va te falloir réviser tes cours ... il y a une grosse différence entre "coeur x86" et "shader" ...    Le premier est utilisé dans les processeurs (par exemple un Core 2 Duo contient 2 coeurs x86), et le second est utilisé dans les cartes graphiques (par exemple : la GeForce GTX 285 contient 240 shaders)
 
(amplement grilled, je m'adresse à bilbo248)

j'ai eu peur je croyais que tu parlais de moi Fantryt

D'où le fait de l'inutilité du concept de Wirmish... Pourquoi chercher à multiplier les puces et se compliquer la vie (sans compter sur les interconnexions très très dures à caser) alors que les GPU sont des gros multicores en un? L'argument des économies de taille sur les chips (plein de petits chips au lieu d'un gros) n'est pas valable puisqu'il faudrait développer deux puces au lieu d'une et tous ces chips coûteraient également très cher à produire.

Excuser mon ignorance en terme d'architecture microprocesseur.

Ben pourquoi pas a utiliser une grappe de SP pour gérer toute l'histoire de multiGPU? Comme ça tu met la carte la plus puissante en maître, et elle gère les connexion vers les autres en prenant une partie de son temps de calcul!
 
Bon il faut bien sur que les carte se branches sur le même système et non sur un truc proprio genre SLI ou cross.
 
PS : ceçi est une idée sans base technique, vous pouvais ne pas en tenir compte

mazette...
 
certain bosse pour la nasa ici pour connaitre les gpu de la sorte?  
 
chapeau en tout cas,instructif.

Je vais t'expliquer tout ça clairement avec un seul exemple.
 
(A + B) / C * (D - E) = ?
 
Si un core s'occupe de ce calcul, tout est simple.
Le proco effectue les opérations nécessaires dans l'ordre (ou pas) et on obtient le résultat.
Y'a pas de problème de synchronisation puisque le core sait à tout moment où en est rendu le calcul.
Au cours des opérations chaque sous-résultat est conservé dans des registres ou dans le cache si l'opération est complexe.
 
Imagine maintenant si 2 cores devait se partager ces différentes opérations:
· Les registres des différents cores ne peuvent communiquer directement entre-eux.
· Si le core #1 fait l'addition... alors le core #2 pourrait faire la division... n'est-ce pas ?
· Sauf que ce n'est pas si simple puisque le core #2 n'a pas accès au résultat de l'addition !
· De plus, il ne sait pas à quel moment le core #1 aura terminé l'addition.
· Et si on doit tout synchroniser entre les 2 cores, cela revient à transformer un dual-cores en un single-core ayant tout simpement plus d'unités d'exécution.
 
J'espère avoir été asser clair.

moi j ai un autres concept
 
mettre les unité shader dans les puce memoire
 
sans charier
plutot que de perdre sont temps à coller du cache au unité shader autant faire l inverse
 
avec ma vision la les puce de GDDR6 auront des unité shader intégré  
 
ça vous semble con... regardé ou on en est des capacité de puce mémoire
idem la frequence des puces mémoires
 
vous pensez vraiment que c est si con mon concept

Ouai mais ca oblige pas tous le monde a avoir les mêmes shader !
Puis c'est comme tous, y'à forcément une contrainte !

C'est vrai que j'avais jamais pensez  à comment fonctionné un dual core.
C'est plus complique que ce que je pensé.
 

 
sauf que les unité shader c est plus ou moins définit par un regroupement d industriel
bref la finalité d une unité shader reste là meme ne varie que sa "revision"
 
c est pas comme le x86 qui est possession d une seule entreprise qui à vendu des licence à 2/3 autre fabricant pour eviter les lois antitrust et se faire un peu de blé

Cesse donc de juger ce dont tu ne semble visiblement rien comprendre.
 
Pourquoi multiplier les puces:
· Permet de créer des cartes bas de gamme (1 puce) et des cartes haut de gamme (5 puces), avec la même archi.
· Simplifie le design des puces, ce qui permet de réduire le temps de développement entre 2 générations de cartes.
 
Interconnexions très très dures à caser:
· 12 traces pour chaque puce esclave, aucune pour la carte bas de gamme (1 puce maître, pas de puce esclave à relier)
· Carte vue comme étant single-GPU (pas de CrossFire), qu'elle soit équippée d'un GPU maître ou bien de 4 GPU esclaves.
· Un seul bloc mémoire à partager au lieu de 2 sur la Radeon X2.
· Scalling pratiquement linéaire à chaque ajout d'une puce esclave, tant que la BP est suffisante (limite de 4 puces esclaves).
· Bus existant depuis 2006 et qui est présentement implémenté dans la PlayStation 3 de Sony.
 
Économies de taille:
· Plus une puce est petite, plus on peut en mettre sur un wafer, et moins on en perd (puces autour de la circonférence du wafer)
· Plus une puce est petite, moins on cours le risque qu'une impureté se retrouve dedans -> meilleurs rendement.
· Plus une puce est petite, plus il est simple de débugger cette puce.
  (On peut plus facilement trouver un bug dans 600 millions de transistors que dans 2 milliards.)
 
Faudrait développer deux puces au lieu d'une:
· Actuellement ATi et nVidia doivent développer plusieurs puces afin de créer le bas, le moyen, et le haut de gamme.
  Mon concept ne nécessite le développement que d'une seule archi pour toute la gamme.
· La puce esclave est identique à la puce maître, sauf qu'on lui retire les RBEs, le contrôleur mémoire, le Tesselator, le RAMDAC, etc.
  (Autrement dit, lorsqu'on conçoit la puce maître, on conçoit automatiquement la puce esclave.)
 
Très cher à produire:
· Utilisation de 2 chaînes de production, une pour chaque puce, au lieu de 3 ou 4 avec le système de puces actuel: BDG-MDG-HDG.
· Production de millions de puces esclave -> rabais spéciaux pour des commandes importantes de puces -> économie d'échelle.
· Gestion de l'inventaire -> On commande 1 million de puces, et ensuite, selon les ventes, on les assembles en cartes BDG-MDG-HDG.
 
 
Si t'as d'autres arguments à ajouter...

ça doit avoir d autre interet
 
une gestion de l energie qui permet en mode idle d activer un minimum de puce
 
une meilleur répartition sur le pcb du dégagement calorifique

Et bien je doit dire que çà serait top, en tout cas l'idée me plait beaucoup.
Et pour les consommateurs çà serait beaucoup plus clair

J'avais pas pensé à ça, mais en effet, suffit de réfléchir quelques secondes pour trouver d'autres points positifs à mon concept.
 
Autres points positif:
· Développement d'un seul pilote simplifié pour toute la gamme.
· Permet de réserver une puce esclave pour la gestion de la physique ou de l'IA.
· Permet de "balancer" la charge entre les puces. Si une puce chauffe trop la puce maître lui envoit moins d'opérations à effectuer.
 
Et pourquoi ne pas mettre 4 sockets MXM sur la carte ?
Pour upgrader suffirait d'ajouter des GPU esclaves à 50 euros chacun.    
 
Si y'en a d'autres qui sont contre mon concept, viendez-y, je vous attend de pied ferme:

bon bah il te reste qua contacter amd au plus vite wirmish...  

L'idée n'est pas totalement absurde, mais à mon avis on aura droit à bien plus intéressant... plus tard.
 
 
Des chips "spécialisés", à l'image des voodoo 2, avec un contrôleur RAM et des unités d'exécution déportées, c'est pas jouable pour la même raison que le concept de Wirmish (12 lignes en 7I/5O c'est pas concevable, la XDR reste en 16 voire 32bits, cf. http://www.xbitlabs.com/news/memor [...] Chips.html ).
 
 
Plus tard, peut-être, avec l'eDRAM et des interconnexions dans le silicium... donc des monstres contenant réellement 4 GPU de plus d'1.5G transistors.
 
Avec 1 partition RAM par GPU et une interconnexion à très haut débit sur un bus en anneau, 1 wafer permettrait de produire 4 GPU différents :
 
- extra-light, 1 GPU solo (applications "industrielles", comme la Radeon E2400)
- light, 2 GPU
- performance, 3 GPU
- high end, 4 GPU
 
Le rendement par wafer serait donc excellent.

La 3DFX Voodoo 6000 avait bien 4 GPU VSA-100, et c'est la même chose avec la Evan & Sutherlands simFUSION 6500 qui était équippée de 4 GPU de Radeon 9800XT. Mon concept ne fait donc que reprendre ce qui a déja existé, mais en l'améliorant: Disparition du CrossFire, unification de la mémoire.
 
 
 
Gigathlon, j'ai pas trop compris en quoi l'utilisation du bus FlexIO, actuellement utilisé dans la PS3 n'est pas concevable pour une carte multi-GPU. Tu pourrais être plus clair ?
 
Mon concept permet au GPU maître d'accéder à la mémoire GDDR5 avec une bande passante de 240 GB/s (384 bit) ou 480 GB/s avec de la GDDR5 en mode différentiel (8x). Les liens avec les puces esclaves ont une bande passante de 76.8 Go/s chacun, pour un total de 384 Go/s dans le cas de mon concept de HD 5870. Cette bande passante est équivalente au taux de transfert maximum théorique des 10 caches L1 du RV770. Je ne vois donc pas pourquoi tu dis qu'il faudrait de l'eDRAM ou un bus plus important et plus rapide.

par contre je sais pas vous
 
mais j ai l impression que pas cette génération (RV870/GT300) mais la suivante
 
y aurait possibilité de remettre la memoire de la CG en barette sodimm via des slot d extension comme du temps des matrox millenium/mystique
 
prenez le cas des HD4850/HD4870
 
suffisait en gros de prendre le pcb de la HD4870 pour les 2 (à cause des connecteur 6 pins et étage d alim)
 
et soit on choisissait sa barette GDDR5 soit on prenait une barette GDDR3
 
mais d un autre coté c est moyen viable pour le Mr ati ou Mr nvidia car soudé les puce sur le pcb c est le moyen de justifié un prix plus conséquent au modele plus cher
 
quoi que vu que meme sur les modele haut de gamme maintenant les oem on leur liberté de design... qui sait

çà poserai quelque problème pour refroidir convenablement les puces non ?
 
Sinon une HD5000 a GPU interchangeable ^^

Ça c'est déja fait avec la Trinity d'Asus avec 3 slot MXM dotées de HD 3850 mobile -> LIEN

C'est vraie
Mais quand je parlais de changer de gpu c'est plutôt à l'image d'une carte mère, ou l'on insérerai, ram, gpu.

Ça ressemble un peu à un socket -> PHOTO-1, PHOTO-2

Oui

chaud à refroidir tout ça...
pourquoi pas un socket comme un processeur? la mémoire reste fixe (difficile pour agencé tout ça) mais le GPU peut être changé!
 
C'est pas pour    mais avec les GPU de Nvidia, ça doit être possible (CPU like )

part un peu en science fiction tout ca non?  

Bah... pour l'instant le RV870 c'est un peu de la science fiction non ?
Et puis, ce qui compte sur un forum c'est d'échanger des idées.

tu as bien raison.
 
mais les boite ce retrouve coincée entre l'envie des meilleur perf et économiser un max.
 
donc ca va surement finir de façons classique et non "révolutionnaire"..  

c'est intéressant à lire même si j'y comprend pas le quart de la moitié, et puis en attendant des nouvelles sur le RV870 ça passe le temps.

Y'a une chose qui doit être réglée, et je pense que tout le monde sera d'accord avec moi.
Il faut qu'ATi et nVidia trouvent un moyen pour unifier la mémoire des cartes multi-GPU.
Ils ne sont pas obligés de copier mon concept, mais ils doivent y parvenir, et le plus vite sera le mieux.
 
Imaginez une Radeon X2 ayant 4 Go de mémoire... et bien, avec les archi actuelles 2 de ces Go ne serviraient strictement à rien.
Vous imaginez le coût inutile de 2 Go de GDDR5, qui ne sert qu'à dupliquer les textures pour qu'elles soient accessibles aux 2 GPU.
 
Le seul moyen d'unifier la mémoire c'est de faire en sorte qu'une seule puce ait accès à la mémoire, ou que 2 puces puissent communiquer très rapidement entre-elles afin d'accéder à la banque mémoire de sa consoeur.
 
Et en règlant ce problème, on en règle un deuxième: On fait disparaître le CF et le SLI et la carte multi-GPU est reconnue comme une carte mono-GPU par le système d'exploitation. Terminé les problèmes de scalling, terminé les jeux qui ne fonctionnent pas en CF ou en SLI. Terminé les optimisations individuelles pour chaque jeu. Et terminé d'attendre les prochains drivers pour que le CF/SLI soit enfin fonctionnel dans un jeu qui vient tout juste de sortir sur le marché.
 
La première compagnie qui y parviendra aura un avantage extraordinaire sur les autres.

 
 
+1
 
vraiment a parfaire ce truc parce que un peu con quand même...