Reprise du message précédent :

 
Le problème, c'est que ces TMU avaient déjà un rendement presque optimal sur le RV770, et donc très durs à améliorer encore.
 
La seule solution à ce manque de puissance de texturing, c'est de doubler non pas le nombre de TMU, mais carrément le ratio de SP/TMU.
 
Au lieu de faire des blocs de 80SP + 4TMU comme sur le RV770, il serait logique de voir plutôt des blocs de 40SP + 4TMU, facilitant au passage les prédictions de branchement puisque les blocs sont plus petits.  

Ça serait pas mal en effet, mais on se retrouverait avec 20 blocs de cache L1 pour les TMUs.
Et pas question de réduire leur taille, donc on perd un peu d'espace... mais gagne-t-on en vitesse ?
 
L'autre petit problème c'est le ratio ALU:TEX qui est actuellement de 4:1 et qui passerait alors à 2:1.
On a pas vu un tel ratio sur les Radeons depuis des lustres.

Et le RV730 alors?
 
320SP + 32TMU en 8 blocs de 40+4

RV670 (4 blocs):
4 blocs de 16 SP 5D = 320 SP
4 Texture Units (16 TMUs) = 8 TAU, 4 TFU, et 20 TS par TU.
4 RBEs (16 ROPs) = 2 Z/Stencil par clock par RBE, 8 pixels/clock avec 4xAA
 
RV770 (10 blocs / +6 blocs vs RV670):
10 blocs de 16 SP 5D = 800 SP
10 Texture Units (40 TMUs) = 4 TAU, 4 TFU, et 16 TS par TU.
4 RBEs (16 ROPs) = 4 Z/Stencil par clock par RBE, 16 pixels/clock avec 4xAA
 
RV870 avec un bus de 384 bit (16 blocs / +6 blocs vs RV770):
16 blocs de 16 SP 5D = 1280 SP
16 Texture Units (64 TMUs) = 4 TAU, 4 TFU, et 16 TS par TU.
6 RBEs (24 ROPs) = 4 Z/Stencil par clock par RBE, 24 pixels/clock avec 4xAA
 
ARCHI     SP  TMUs ROPs
RV610:     40    4     4
RV710:     80    8    4
RV630:   120    8     4
RV670:   320   16   16
RV730:   320   32    8
RV740:   640   32   16
RV770:   800   40   16
RV870: 1280   64   24
 
Un bus de 256 bit nous donnerait ceci: RV870 (256 bit): 1280   64   16
 
Avec 256 bit on se retrouve encore avec 16 ROPs, soit le même nombre que dans le R520 (X1800) qui est sorti en octobre 2005.
Si AMD choisi d'implémenter 16 ROPs, il faudra qu'il revoit entièrement leur fonctionnement afin d'augmenter leurs performances.
Il est possible de doubler le Z/Stencil par clock (8x), mais je ne pense pas qu'il puisse traiter plus de 16 pixels/clock avec 4xAA.
 
Autre solution, mais ça serait du jamais vu sur une Radeon, serait d'avoir une fréquence différente pour les SP/TMU et les ROPs.
nVidia utilise plusieurs fréquences dans ses puces, et ce depuis plus de 3 ans, alors c'est possible qu'AMD adopte la même technique.

Je trouve toujours aussi illogique de garder le même ratio SP/TMU bancal que sur le RV770, même en améliorant un peu les TMU.
 
Si c'est comme le coup des 800SP tu vas peut être avoir raison mais j'espère pas

J'aimerais bien qu'ATi double le ratio des TMUs vs ALU mais le problème c'est que l'espace requis pour un TMUs est bien plus grand que celui nécessaire à un SP 1+4D. Et comme on débute l'ère des GPGPU/APU, les SP sont plus important que la puissance de texturing. Les SP d'ATi étant 2.6 fois plus petit que ceux du caméléon, il est évident qu'AMD veuille en profiter au maximum afin d'offrir la carte GPGPU la plus puissante du marché.
 
De plus, le Tesselator, fesant parti des specs de DX11, sera enfin implémenté sur les GeForce, ce qui fera en sorte que, comme par magie, les développeurs de jeux vont commencer à l'utiliser... même s'il est implémenté depuis des lustres dans les Radeons.
Le Tesselator permet de multiplier le nombre de vertices d'une scène, ce qui demande beaucoup de puissance de shaders (SP), sans que le texturing ne soit trop sollicité. Les rôle des SP devient donc bien plus importants que celui des TMUs.
 
C'est pour ces raisons que je persiste à croire qu'AMD ne va pas modifier son ratio d'ALU/TMU.
Je ne dis pas que cela me saisfait pleinement, mais je pense que c'est une décision qui serait tout à fait raisonnable.

 
Personnellement, je suis pas sure que ce soit un problème, pour la simple et bonne raison que 80% (voire plus) des jeux sont multi-plateformes. Or, j'ai pas l'impression que ces jeux console/PC demandent une puissance en texturing importante peut-être à cause de la faible BP ou quantité de mémoire des consoles, et au contraire mette tous dans la puissance de calcul. A ce moment, l'augmentation du nombre de SP aura peut-être beaucoup plus d'impact que l'augmentation du nombre de TMU, et ce même si l'architecture ne semble pas équilibrée.
 
 

Bonne argumentation Wirmish    
 
Il pourraient peut être mettre un ratio intermédiaire? Comme des blocs de 80SP + 5 ou 6 TMU? Je sais pas si c'est techniquement possible..

n empeche si avec toute cette puissance ils pouvaient favoriser des textures procédurales dans les jeux plutot que du bitmap
 
edit: ça serait d ailleurs interessant pour les consoles tres etriqué en memoire

Depuis le RV670 chaque TMU est directement relié à un bloc de 80 ALU.
Avec 10 blocs (800 ALU) on a 10 TMUs (4 flitering/texturing par TMU).
Pour ajouter 1 TMU il faut donc ajouter 16 blocs de SP 1+4D (80 ALU).
AMD ne devrait pas changer ce ratio... du moins ça m'étonnerait vraiment.

Tu veux dire comme dans ce démo de 177 ko ?    

 
oui visiblement
 
en tout cas je sais que du temps de win98 j avais un soft de raytracing j utilisait que ça les textures procédurales  
 
bon maintenant j ai laché pied pour plus faire de la video
 
mais en ce moment je regarde les softs pour m y remettre à la synthèse (dernierement c etait plus des dessins tech que je faisais, pas specialement besoin de texture pour ça )
 
enfin voilà quoi
fond chier avec leur texture bitmap toute pourri pour faire croire à des chose qui ne sont pas là
 
lex textures procédurales pour "les peau d animaux", les murs, le bitume, l acier, tissu etc...
enfin bref quoi  
sur le bitmap doit apporté qqs facilité genre sur le sol foutre des faux cailloux par ci par là
 
mais c est faisable en multipliant les texture procédurale
 
certe ça demande plus de boulot des devs (ne serait ce qu au niveau raccord)
 
mais la qualité du rendu n en ai que meilleur à mon gout
avec l avantage qu une texture procédurale, on s en tape de la resolution la qualité serait du meme niveau à toute les reso imaginable
 
meme si demain on veut balancer le jeu en 20000*12000
 
http://www.mapzoneeditor.com/index [...] RY.SHADERS
 
http://www.allegorithmic.com/?PAGE=PRODUCTS.substance

Pour info, le bus sera de 256 bits. Pas plus, pas moins.

tu sors ca d'ou marllt2?

c'est dangereux ce genre de question cizia  

ah bon?  
 
marlt 2 aurait des source non divulguable sur forum?      (style boit le canon avec hector ruiz?   )

 
 
clair t as souvent une réponse qui fait état de partie basse de la physiologie huamine    
 
mais suis sur qu il a volé un pcb de hd5870 à son petit chinois habituel  

Le PCB est conçu en Ontario, dans ce p'tit building -> Photo
Un p'tit canadien risque donc de mettre la main (ou les yeux) dessus bien avant un p'tit chinois.

 
sur que t es québecois ... si si je reconnais ce drapeau collé sur l arrière de ta voiture avec écris en dessous "j'aime la poutine"

Impressionnante cette démo de 177ko  

Clair, et ça rame même pas sur 9600M GT GDDR3.  

Jolie job cet demo

Rien d'étonnant en soi, le 512bits est coûteux et à l'intérêt limité vu que la ggdr 5 est là. Pour du mono gpu ça pose pas de soucis tant que la ggdr 5 monte, ce qui devrait être le cas avec le rv870 (2.2-2.4 ghz serait souhaitable). Et pour du mutli-gpu aucun soucis vu que la bp s'additionne.

une autre demo
 
http://www.ethos.no/.robert/files/demo.zip
 
moins aguicheuse mais elle est interactive (vous pouvez vous deplacer droite gauche haut bas avec les fleches du clavier Q/E rotation S/W avancé reculer)
 
j aime bien le coté "vitesse lumière "
 
 
Edit:
sinon après faut pas croire que c est pas faisable sous windows tout ça hein    
 
http://blogs.msdn.com/jgalasyn/arc [...] xture.aspx
genre le mec super étonné des perf avec le .net de microsoft

 
 
En parlant de CrossFire, est-ce qu'une date a été annoncée pour la puce Hydra d'Intel ?

Tout le monde est d'accord pour ce qui est du 512 bit ->
 
Mais pourquoi est-ce que ça devrait absolument être un bus de 256 bit ? Pourquoi pas un bus de 320 ou de 384 bit ?
Je sais bien qu'un bus de 256 bit est parfaitement adapté pour la X2, mais peut-être que c'est aussi faisable avec un bus de 384 bit.
 
Avec un bus de 384 bit il faudrait 6 ou 12 puces mémoire (768Mo/1536Mo) au lieu de 4 ou 8 (512Mo/1Go).
C'est pas un problème en ce qui concerne une carte mono-puce, mais ça peut le devenir pour une X2 de 2 Go (16 puces)
Et dans le cas d'un bus de 384 bit, il faudrait mettre 24 puces mémoire sur le PCB (3 Go de GDDR5).
 
Je sais que le PCB d'une X2 est peut-être trop chargé pour y ajouter 8 puces mémoire (4 de chaque côtés) -> PCB d'une X2
Mais si AMD parvient enfin à se débarassé du chip PLX, ça permettra de dégager asser d'espace pour les puces supplémentaires.
 
Une autre possibilité serait d'utiliser des puces GDDR5 de 1024Mb au lieu des puces de 512Mb utilisées actuelement. Samsung a déja envoyé des samples de GDDR5 1Gb à 0.4ns (5.0Gbps) à AMD en février dernier. Une RV870-X2 avec double bus de 384 bit pourrait donc se satisfaire d'une seule puce mémoire par contrôleur pour un total de 12 puces (3 Go), soit 4 puces de moins que la X2 actuelle (2 Go).
 
La production de ces puces mémoire a débuté à la fin du mois de mars. Sa disponibilité en masse serait donc prévue pour le mois prochain. Cela concorderait avec la date supposée du lancement du RV870. Ces nouvelles puces mémoire permettraient donc à AMD de passer à un bus de 384 bit sans aucun problème.
 
Mais AMD va-t-il rester sage et conserver un bus de 256 bit... ou nous faire une belle surprise et passer au 384 bit ?

Tu veux sûrement parler de la puce Hydra de Lucid dont Intel a fait la démo au dernier IDF.
 
Y'a pas de date... pas de news.
 
Lorsqu'on sait que la X2 offre 80% des perfs théoriques en haute définition, je ne suis pas certain que ce serait une bonne idée d'ajouter cette puce sur les X2 d'AMD. Autrement dit, est-ce qu'un gain maximum de 20%, dans le meilleur des cas, justifierait le coût de la puce Hydra ?
 
De plus, si Lucid fait faillite, AMD se retrouve avec une techno qui peut tomber dans les mains d'Intel ou de nVidia. Ne serait-ce pas moins risqué pour AMD de développer sa propre technologie, afin de ne dépendre de personne ?

Oui, je voulais parler de cette petite puce ...    
J'espère que, tôt ou tard, il existera une puce similaire à celle-ci à l'intérieur des cartes graphiques bi-GPU ...    les performances s'enveleront, là ...

 
s'envoler les perf ??? la fameuse puce "dans le cahier des charge bien communiqué partout"
 
si j ai bien compris passe outre la couche soft/drivers des fabricants
 
en gros si tu as disons une carte nvidia de 200 unité shader et une carte ati de 180 unité shader tout ça dans le meme PC
la puce hydra est censé montré aux dll de directx la chose comme un tout de 380 unité shader
 
dans les fait je dirait que ça sent le pipo histoire d attirer les investisseurs et donc le fric facile... mais au final je suis pas bien sur que le resultat soit probant... car un moment ou un autres doit y avoir un interpréteur de commande ou je sais pas... bref quand bien meme c est faisable  
et encore faut que intel (larabee) nivdia et ati cache pas qqs données tech ce qui serait grandement étonnant    
 
bref quand bien meme cela soit faisable techniquement ... mmmmh je suis pas certain qu au niveau soft ça donne grand chose
 
pour avoir vu qqs soit disant resultat/bench de cette solution... ça faisait plus penser à des trucs trafiqué au niveau des reglages du jeu
 
je serais bien curieux de voir une sample réel de cette fameuse puce
 
car si c est comme le nf200 de nvidia qui est plus un dongle de securité dans le CbiiiipL sur certaine plateforme et au final faute de licence qpi nvidia n'a eu autre choix que de faire juste de la vente de licence pour qqs lignes d identification dans les bios de mobo (pour X58, il est quasi certain que sur plateforme i5 nvidia va pas se laisser faire pour reussir à refourguer des nforce... va falloir que les fabricant de mobo fassent de nouveau front pour meme pas devoir mettre du nf200 sur les mobal à chipset intel sur plateforme LGA 1156)

Je dis pas que c'est pas une bonne techno, loin de là, mais ça repose sur l'ajout d'un autre niveau de pilote... qui est propriétaire à LucidLogix Technologies. Encore une fois, le fait qu'AMD ne contrôle pas ce pilote et son code source, cela revient à remettre les performances de ses cartes multi-GPU entre les mains d'une compagnie étrangère (Israël).
 
Pour ce qui est du fonctionnement, c'est asser simple, bien pensé, et ça devrait être performant, même avec 3 ou 4 GPU. Mais on va quand même attendre de voir les perfs réelle, car un CPU RISC à 225MHz avec seulement 32Ko de cache n'est peut-être pas à la hauteur de la tâche. Pour ce qui est du pilote, c'est plus compliqué puisque LucidLogix devrait obtenir des informations confidentielles d'AMD, d'Intel et de nVidia.
 

 
Moi, je vois plutôt la puce Hydra comme une puce servant à distribuer d'une façon bien meilleure les calculs .
Prenons par exemple, un bonhomme qui a une HD4870x2 : lorsque des informations arrivent jusqu'à la HD4870x2, elle se dédouble et part dans la mémoire de chacune des deux puces . Ensuite, ces deux puces vont communiquer entre elles (notamment via le pont CrossFire) et décider qui calcule quoi . Bref, la mémoire est tout simplement "gâchée", parce que les deux puces reçoivent la même information, et il y a une perte de temps énorme dûe à décider qui fait quoi . L'utilité de la puce Hydra serait de choisir qui fera quoi, et ce avant que les informations n'arrivent à la HD4870x2 . Bref, gain de temps énorme . Sans compter que la mémoire ne sera plus du tout gâchée avec ce genre de procédé ... les deux puces reçevront une information différente, calculeront des choses différentes, c'est pourquoi Intel dit que les performances augmenteront de manière linéaire : t'as une HD4870, bah si tu en ajoutes une tes Fps devraient théoriquement doubler, ce qui est loin d'être le cas actuellement .
 
Enfin, là-dedans, il y a forcément des trucs que les marketeux ont écrit, mais l'idée est bonne, et j'espère que ce qui en résultera sera performant .

Pas besoin de cette puce, je pense que le scheduler CrossFire / SLI est suffisant.
Il suffirait de créer une puce qui permet juste de "montrer" aux GPUs les deux mémoire additionné comme une seul et même mémoire.
Moins complexe donc moins chère et plus petit.

En fait c'est la couche additionnelle du driver qui s'occupera de distribuer les tâches entre les GPU. La puce Hydra ne joue que le rôle d'un pont PCIe semblable au pont PLX utilisé sur la X2. La différence c'est que l'Hydra contient un CPU RISC à 225MHz qui s'occupe de la gestion des tâches préalablement définies par le driver. Une fois toutes les tâche d'un frame complété, l'Hydra réassemble le rendu des différents GPU, pixel par pixel, et le redirige vers le frame buffer de GPU "maître", c-à-d celui sur lequel est branché le moniteur.
 

La mémoire n'est pas "gâchée" puisque ce sont les textures qui occupent la très grande majorité de l'espace mémoire. Les infos du wireframe sont compressés et n'occupe que très peu d'espace. De plus, chaque GPU doit avoir accès aux mêmes textures puisqu'ils est possible/probable qu'ils aient à y accéder à un moment ou à un autre. Cela revient à dire que même avec une puce Hydra, les textures doivent être dupliquées entre les 2 banques mémoire des GPU. Il n'y a donc pratiquement aucune économie de mémoire.
 

C'est pas Intel qui le dit mais plutôt LucidLogix.
Faudrait arrêter de parler comme si la puce Hydra appartenait à Intel.
 

Question idiote (ou pas) : Pourquoi il n'existe pas de GPU double coeur et plus comme c'est le cas sur les CPU ?

ati devais pas le faire ca?
 
sembler bien que l'idée trainer...
 

 
 
je sait pas les unité shader t appel ça comment
 
juste pour te dire larabee c est "en gros" plein de pentium 1 regroupé avec un jeu d instruction specifique en plus ans le style mmx + les transistor qui vont bien pour que les dit core "pentium" sachent communiqué entre eux (comme des xeon ou des pentium pro)
 
bref la notion de "monocore" est bien vague à ce niveau

C'est justement ce que j'ai essayé de démontrer avec mon concept -> 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, ...
 
Mon post original, là où tout à commencé, avant que mon "concept" ne se retrouve partout sur la planète -> Beyond3D
 
La mémoire n'est reliée qu'au GPU "maître", qui distribue ensuite la charge de travail entre plusieurs GPU "esclave".
De cette façon, si la carte possède 2 Go de mémoire, aucune information/texture n'est dédoublée.
En 40nm le GPU maître aurait une taille d'environ 150mm² alors que chaque GPU esclave aurait une taille d'environ 100mm².
 

Pourquoi il le font pas ?
Cout trop important ?

 
genre tu colle les rops d'une puce GT200 dans le NV I/O et c est le NV I/O qui chapotterait les "SPU"

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.