Alors voila, si j'ais bien compris une carte graphqie c'est uen sorte de processeur dévoué a l'image ( si c'est pas ca alors ce qui suit ne peut pas avoir lieu )
Alors pourquoi ne pas faire des cartes graphiques "double core" ?
 
ps: si je dis une connerie, escusez moi mais je débute en info ^^

Le TALC du vendredi ...

Faut en avoir l'utilité ...

Déjà que celle des CPU dual core peut être discutée dans la majorité des cas, ne parlons pas d'un GPU dual core ...

Cette solution serais intéressante pour ceux qui veulent pas
 
investir dans des 8800 gtx et autres !!!Avec pour couronner le tout un  
 
overclockage diabolique ^ ^
 
A mon avis deux coeurs dans un GPU ce serait plus qi'intèressant on  
 
approche 2010 les voitures ne décolle pas d'un centimetre ^ ^

Sa existe déjà.
Va voir cette article : http://www.clubic.com/actualite-74 [...] phire.html

oui..les carte graphique avec 2gpu  existe..mais pas les gpu dual-core..

Faut aussi savoir qu'un gpu est déjà un peu "multi-core" ..  
Les pros arriveront sans doute pour argumenter ce que j'viens de dire

ouai

Effectivement si quelqun pouvait dévelloper car je comprend pa trop ^^

Pour l'instant sa n'attire pas grand monde  
 
je crois qui faut se contenter de ce quon as  
 
et donc du monocoeur GPU ^^

Pour l'aspect technique qui différencie les CPU (microprocesseur) et GPU (processeur graphique), il se résume en un mot pour notre propos : parallélisme. La grande difficulté des CPU est d'arriver à exécuter des calculs en parallèle. c'est tellement difficile que la meilleure réponse que nous avons c'est le multicore. Du côté des processeurs graphiques par contre le parallélisme est la Mecque, le Graal. C'est d'une facilité déconcertante d'en faire. La recette consiste simplement à multiplier les pipelines à pixel ou à vertex. Cette différence entre CPU et GPU est due au type de données qu'ils traitent.
 
http://www.onversity.net/cgi-bin/p [...] ob&P=a0705
 
Truc cherché rapidos sur google.

avec SLI tu peut mettre 2 carte graphique sur une carte mere qui a 2 slop pci express x16

Donc si j'ais bien compris latif 18, un multi core pour gpu serait inutile, et ce car il peut traité très facilement plusieur infos en même temps ?

oui et car les jeu , n'on pas tous l'option : duo gpu ( a par lost planet )

Autant qu'un A64 3000+.
 
Les GPU (post-G71) sont déjà plus ou moins des processeurs multi-cores asymétriques, il y a plusieurs étages dotés de fonctionnalités distinctes:
 
- un processeur de calcul massivement parallèle (là où le parallélisme d'un C2Q se limite à 4x8, un R600 est en 1x320 (8x(8x5)), un G80 est en 1x128 (8x16)
- le setup engine
- un processeur en charge du texturing
- un processeur en charge de la transformation des données en pixels
 
De leur côté, les CPU sont aussi tous plus ou moins multi-cores vu qu'ils intègrent tous CPU et FPU.

 
 
Tu parle de FPU, mais quesque c'est ?
 
 
Sinon les gpu on donc plusieur processeur qu sotn chaqun spécifié dans un domaine donc ?

La FPU est un CPU qui gère les nombres à virgule flottante, sa complexité n'a pas grand chose à voir.
 
Un GPU contient une FPU (limitée au 32bits) capable de calculer un nombre conséquent de données en parallèle (schématisée comme 8 blocs de 8 unités SIMD d'unités VLIW sur 5 donées pour le R600... ça devient vraiment tordu ) là où dans un C2D chaque core ne peut exécuter que la même instruction 8x sur des données différentes en parallèle (SIMD, via SSE)

 
Frenchement... j'ais rien compris ^^  
Je sais que tout ca c'est compliqué et maintenant je regrtte d'avoir posé la question car je me pose encore plus de questions ^^
Bref, je n'y connais rien c'est pour ca, si tu pouvais "simplifier" ca serait pas mal    
Mais merci pour tes réponces déja  

 
Rien de tel que des schémas, mais j'en ai pas sous la main
 
Quelques définitions...
 
SIMD: Single Instruction Multiple Data. On balance 1 instruction et on traite plusieurs données regroupées en paquet avec. Avantages: économique en transistors et bande passante/latence, permet théoriquement de multiplier largement le débit. Inconvénients: nécessite d'avoir un nombre important de données à traiter de la même façon, nécessite des données en paquets. Exemples: MULPD (SSE), exécutée après un PACK (SSE/3DNow).
 
VLIW: Very Long Instruction Word. Approche différente pour un résultat proche. Cette fois on a toujours 1 seule instruction pour plusieurs données, mais l'instruction peut être la composition de n'importe quelles instructions sur un nombre défini d'unités. Avantages: quelles que soient les instructions, elles sont généralement parallélisables. Inconvénients: plus complexe du fait du nombre d'instructions existantes. Utilisé de façon transparente dans des CPU.
 
 
L'idéal se situant à mon avis (ça n'engage que moi) entre les deux types d'archis, à savoir un processeur VLIW en interne capable de trouver du parallélisme dans le code et de réorganiser tout ça. C'est l'approche utilisée par AMD sur les K7/K8 mais la largeur est réduite, K10 devrait corriger un peu ça en la doublant, arrivant à la même largeur que Core (Conroe), mais ça reste "étroit".
 
Pour schématiser le fonctionnement VLIW, on peut représenter 3 bus: adresse 1, adresse 2 et instruction, un peu comme la base même d'un CPU à ceci près que la taille du bus d'instructions est fixe et d'autant plus grande que le nombre d'unités de calcul est important. Un CPU ne faisant que + et - par exemple se contenterait de 2 bits par unité de calcul: 00 étant l'instruction "no operation", 01 étant "+", 11 étant "-" et 10 étant "complément à 2". Quand on voit que K10 a une largeur de 3x128bits pour la FPU uniquement, on arrive à un maximum de 12 unités de calcul (4x32 par unité si on les sépare, mais il me semble que ça n'est pas fait), et tout ça sur un nombre d'instructions conséquent, ça peut donner une idée de la complexité de mise en oeuvre...
 
Un GPU présente peu ou prou les mêmes caractéristiques mais exploite nettement plus d'unités de calcul: de 12 au sein de K10, on passe à 120 pour un RV630 (voir R600), 160 pour un G80 (128 "généralistes" + 32 "spéciales" techniquement, regroupées en 8 blocs de 16+4 unités SIMD) et 320 pour un R600 (généralistes, dont 64 capables d'opérations "spéciales", regroupées en 8 blocs de 8 unités SIMD où chaque instruction est sous le format VLIW sur 5 données), tout ça sans compter les opérations de branchement.
 
 
La principale nuance entre CPU et GPU, c'est le type de données traitées, qui change radicalement la donne: un CPU traite tout et n'importe quoi et doit souvent le faire en priorité "temps réel", un GPU traite une quantité colossale de données à la chaîne, avec une tolérance sur la latence globalement élevée (on a besoin d'1 image tous les 1/60e de secondes, un pixel peut attendre le dernier moment pour être calculé, soit plusieurs milliers de cycles -> recherche de parallélisme facilitée). Ce qui fait que le R600 est un gros raté, à mon avis toujours, c'est tout simplement qu'AMD ou ATI, peu importe, a décidé de "généraliser" la puce, son comportement vis-à-vis de la latence est radicalement différent de ce qu'a choisi nVidia et il est "castré" au niveau de tout ce qui est réellement rendu 3D, les fameux "autres cores", qu'AMD semble être bien parti pour séparer physiquement.
 
Alors oui, on risque donc de voir des GPU multi-cores arriver, mais sans aucun rapport avec les CPU multi-cores, simplement un remake de ce qu'on avait pu voir chez 3DFX de sorte à simplifier la conception, réduire les coûts et diminuer le cycle de renouvellement. Le fond de ma pensée étant: quel intérêt de concevoir plusieurs puces utilisant les mêmes éléments (shader core, TMU, ROPs) si on ne peut pas réutiliser les masques? Actuellement, tout est dans le même die et nécessite donc 1 masque par gpu, alors qu'il serait si "simple" de faire non pas 1 masque par GPU mais 1 masque par élément de GPU... (RV610, RV630, R600 -> shader core 8x5, TMU 4x4 + ROPs 1x4, de 3 masques pour 3 GPU on passe à 2 voire 1 seul pour un nombre virtuellement infini de déclinaisons possibles tout en diminuant la surface et donc la probabilité de défaut principalement sur le haut de gamme)

Tu es ingénieur dans la conception des CPU/GPU ou quoi?

Non je crois simplement que c'est lui qui a inventé l'ordi en faite °.°