Reprise du message précédent :

Non-sens !
Un constructeur de GPU n'a pas de moteur de rendu ! Il crée des technologies pour faire fonctionner ces moteurs de rendu et qui s'accorde aux standards actuels de ces derniers, présents sur le marché, comme Unreal Engine 3, Cry Engine 3, Aurora Engine, X-Ray Engine, Renderman, Brazil, maxwell, etc..
Havok, Bullet, Euphoria, Tokamak et PhysX ne sont que des acteurs dans ce paysages, ni plus ni moins.

Pour ceux qui en doutait
 
http://www.brightsideofnews.com/ne [...] stone.aspx
 
AMD president and CEO Rory Read said: "In just one quarter, we were able to see more than a doubling of yields on 32nm, allowing us to exit 2011 having exceeded our 32nm product shipment requirements. Based on this successful ramp of 32nm HKMG, we are committed to moving ahead on 28nm with GlobalFoundries."

@celui qui aura la plus petite
Oui on en doutait

Donc Trinity en 28nm ?
/me comprend ce qu'il veut comprendre

J ai pecho ce lien chez AT...  
 
 
http://www.nordichardware.com/news [...] lding.html
 
                                A8-4500M "Trinity"  A8-4500M "Trinity"  A8-3500M "Llano"  
Floating Point Speed  1 655.51                        1 679.55          1 580.98                 + 5.47%
Integer Speed          5 214.95                        5 662.48          3 921.99                 +38.67%
TDP                          35W                                 35W                    35W

Rhô les FP

Bah, c'est mieux
Reste à savoir la clock du A8-4500M...

3.x GHz ..

2GHz de plus pour arriver quasi au même niveau

Piledriver, ça décoiffe

on s'en fou le TDP reste le même,et si la conso aussi alors j'en ai rien à battre qu'il faille 5Ghz ou2... personne ne râle quand ça arrive pour les cartes graphiques... cfr HD 7770.
 
mais bon les FP c'est clairement foireux.

Je comprends mieux la remarque de NORAD.
 
maerens, dans le fond, je suis d'accord... Mais putain, ça fait vraiment de la peine

si il faut reculer pour mieux avancer... en fin de compte je n'en suis pas si sur que ca fait de la peine? vaut t'il mieux une archis peu éfficace mais efficiente( avec un bon 32nm ) ou un archis bourrine mais qui consomme?
 
malheureusement tout le monde n'a pas des process d'alien comme chez le concurrent...
 
de toute facon trinity est destiné à un public qui recherche avant tout une basse conso, ou pour des types comme moi qui cherchent un portable d'appoint pour éviter de faire peter 300W en surfant sur HFR... alors seule les perfs/w m'interessent ici... Cependant pour Vishera ca annonce du pas terrible...

3ghz  

Je me demande même si les ingénieurs savent se qu'ils fond , on dirait qu'ils sont dans le flou total...

Car à la limite pour Bulldo je veux bien comprendre qu'il y ai un problème... mais pour faire Piledriver , pourquoi ne pas partir sur les bases du Bulldo et revoir tout se qu'il y a autour et tout les problèmes ? Sa vas pas leur prendre 4 ans pour revoir les caches foireux ni même pour augmenter d'une manière ou d'une autre l'efficiense des coeurs , je doute que les ingé' de chez AMD soit des mecs qui ni connaissent rien...mais je commence à me poser de forte question sur Bulldo'...

Pourquoi ne pas partir sur une archi' de "transition" tu reprend Bulldo pour en faire une archi' plus "conventionnel" même si il faut mettre tout les ingé' d'AMD sur le coup , on parle ici d'une archi' qui vas devoir encore être présente sur le marché pendant encore longtemps coté CPU et APU....et si ils se bougent pas le cul , AMD CPU/APU c'est mort d'ici 2014...

PS : Je dis pas que c'est facile de retravailler un design de puce en profondeur , je dis juste que y a quand même un problème quelque par....

PS 2 : Désolé pour toute les conneries que j'ai pu dire dans se message

You'll Better go away

le temps qu'ils revoient leurs caches Intel aura déja des CPU 100Gflops à 2W...
 
l'archis de transition si on peut appeler ca comme ca, tu vas l'avoir et ce sera le FX-4200, en gros un CPU avec des FPU enfin éfficaces.  
 
et pour le coup comme je le répète tant mieux que le TDP reste le même avec une fréquence doublée, au moins ça prouve que le 32nm est au taquet.

  c'est plus francais... heu pardon anglais.

t'as rêvé !

 
Sérieux les caches ça me désole...
 
Le FX-4200 ? La grande blague...bon je vais pas troller , je vais rester objectif : Les FX-4200 vont surement être du recyclage de FX-8000 , ils seront un bien meilleur choix pour les "applications" que les FX-4xxx existants , mais le TDP reste très élevé restant un choix finalement très mitigé .  
 
Perso' je trouve le 32nm mauvais mais on ne peut pas blâmer que GF , c'est aussi en grande parti à cause d'AMD qui à abusé niveau cache sur ses FX mais aussi sur le nombre de transistors et de la fréquence...

Non stop, que le process est mauvais, c'est même plus valable !

bien sur que non si la rumeur est avérée 100% du FPU sera accessible pour 1 cluster, étant donné que chaque thread, prendra siège au sein d'un module différent.
 
on évitera ainsi d'avoir un thread par module avec 20% du FPU, et 80% pour l'autre, comme c'est le cas pour les FX 41**, mais reste à voir si la rumeur est exacte.
 
ce sera peut être même possible de se le farcir en FX-8000 avec une conso de 500W

Vu qu'il y en a moins que ce qu'on croyait, je vois pas ce que tu reproches
1,2Md pour un 8 cores ( ) et 16Mo de cache, que demande le peuple ?

Avoir des FX-4xxx avec un TDP de 125W depuis le début sans baisse de conso' ni de TDP après plusieurs mois  j'appelle pas ça avoir un excellent process' , après la faute à AMD avec les problèmes de conso' de Bulldo...

EDIT : Norad >  1.2Md c'est pas que j'y crois pas....mais j'y crois pas ! Désolé mais d'abord c'était 2Md ( source officiel avant les tests )  si mais souvenirs sont bon et ensuite c'était 1.2Md ( source officiel après les tests ) , merci le service Marketing qui balance des infos de merde... , ensuite 16Mo de cache....ouais cool....sauf que les caches sont hyper mal foutu et que les 16Mo n'ont finalement pas une grande utilité....

Ben non, rien à voir avec l'efficacité. En fait, je dois être neuneu, je comprends pas : c'est un exemple au pif ?
Chaque "core" du FX-4200 aura sa FPU 128/256bits non ?

cet argument n'est pas valable, pour la simple et bonne raison, que les meilleurs yields sont réquisitionné pour Trinity, de plus il s'agit toujours de la révision B2, et à ce que je sache il y avait des TDP de 140W en PHII C2, i a fallu attendre 6 mois pour enfin voir le plafond descendre à 125W avec la C3 et y rester.
 
de plus si 4 thread sont répartit au sein de 4 modules distincts, les FPU seront plus sollicitées qu'avec 2 modules, ainsi le TDP grimpe de manière drastique, mais on arrive avec un CPU à 3,3Ghz aussi peformant qu'un FX traditionnel 4Ghz. alors le TDP de 125W je m'en fou.

étant donné que la FPU est partagée pour les 2 clusters, il y en a un des 2 qui pompe 80% de sa capacité et l'autre cluster en pompe 20... c'est l'une des faiblesse de l'archis bulldo.
 
et le seul moyen que je vois pour remédier à cela, c'est de partager 4 clusters au sein de 4 modules différents. pour ainsi utiliser la FPU à 100% de sa capacité.
 
à quand des FX-8 dans la même situation? ha oui le die d'interlagos est trop gros... mert.

La solution serait de rajouter un FPU par module...

et nous nous retrouverons ainsi avec une archis de PH II et 4 milliards(au pif) dépensés par la fenêtre.  
 
on pourrait aussi rajouter une alus par module... et diviser la cache par 2.

Statistiquement, il y a moins de 50% de code FPU. C'est quoi le problème du partage dans ce cas ? Cela a été démontré plein de fois
Et dans ce cas, c'est pas un problème de BD mais de l'attribution du "calcul" au même module

C'est déjà le cas : 1 FPU 128 bits par module et une fusion sur 2 modules pour arriver à 4 FPU 256bits sur un FX-8xxx

Je continue à y croire

Bof, ne pas oublier que c'est un quad-modules : c'est pas les FPU qui sont plus efficaces, c'est les ALU qui a sont bridées (1 seul cluster actif par module).

Ce n'est pas qu'une rumeur, sinon HFR n'aurait pas relayé.

La FPU était déjà 100% pour chaque thread... sauf en 256bit.
Pour toi la solution serait donc de virer le 2ème cluster (12% de la surface d'un module) et de multiplier par 2 le nombre de modules ? Le nombre de transistors déjà élevé va exploser, et les perf/W déjà mauvais vont être encore moins bon. Clairement une mauvaise idée. Autant repartir sur du K10/K12

 
C'est bien ça le problème...Bulldo est foiré faudra bien l'avouer un jour... le plus tôt serait le mieux  
 
J'espère que ça vas faire réfléchir AMD sur l'utilisation d'une IA pour les futurs archi'....
 

son argument indique qu'ils devraient en mettre 2 et non un fpu partagé.
 
en fait ce qui serait bien de la part d'AMD, ce serait d'obliger la FPU à être débloquée à 100% pour un thread, lorsque 1 thread est sollicité, et ainsi de suite jusque 4 threads.
 
en fait cette technique est possible avec les profils d'affinité de l'AMD overdrive. mais c'est chiant à mettre en place pour chaques exécutables. le seul problème c'est que l'on a accès que à 80% du FPU par thread( c'est un chiffre balancé +-, je sais plus trop).

je suis d'accord, mais avec cette technique on pourra réduire la fréquence
 
pour moi il faut repartir sur une archis type, 4 gros coeurs bien bourrin style K10, Sandy et des coeurs d'appoints style CELL, beaucoup se sont foutu de la gueule de ce CPU en 2005, mais intel a clairement indiqué sa volontée de s'insinuer dans ce chemin... et ont me dit dans l'oreillette que Knight corner n'est pas loin...

 
Ma non , c est cool en gros...
 
En FP c est une comparaison avec des instructions legacy , cad sans AVX , FMA  
et tutti quanti , faut voir avec du soft optimisé.
Quand aux integer , c est de ca que BD manquait pour fracasser les IB.

-ce qui est le déjà le cas depuis le début ! Bref ..

-Ça n'a jamais fonctionné comme ça et tu devrais le savoir. C'est par pass que ça fonctionne et uniquement si le point flottant fait 256 bits de longueur (AVX, double SSE 128 bits, etc .. Relis l'article d'Hfr ! Nom de dieu ).
  Dans ce cas et seulement celui-ci, c'est un coup le 'clst0', puis le 'clust1', mais si il fait aussi du FP, si sa tâche n'est pas exclusivement INT, ça arrive.
  Et pour toutes autres opérations FP c'est 2 pipe FP pour chaque Clst.
  Comme pour toutes µ-Architectures, qui consiste a utilisé à plusieurs escients, la ou les mêmes ressources disponibles (aka clustering integer caching [DEC Alpha] et l'hyper-threading [Prescott]), c'est chacun son tour.
  Sinon pourquoi crois-tu qu'il y a 2Mo de cache L2 "shared" ?

-Aucun intérêt.

-Te rappels-tu, seulement, combien de temps on se l'est farcit, le 955 125W avant d'avoir -6 moins avant son retrait du marché- un TDP de 95W ? tu peux me le dire ?

-si tu suivais un peu mieux, tu saurais que je n'ai jamais approuvé ces chiffres !

-Tu tiens ça d'où ? tu as une source ? un lien qui le prouve ? ou encore un essai de FX sans L3, voire sans L2 ? Qui étayent ou atteste de sa totale, voire (me voici indulgent) quasi totale inutilité de ces caches ?

oui c'est ça .. mais c'est pas comme ci ça n'était pas le cas auparavant !

-Connerie ! Comme si il ne se souciait pas de leur procos desktop, dont leur stock ne bouge pas !!

-Connerie .. again ! voir plus haut .. je ne vais pas répéter, non plus

-augmente de façon drastique ? Tu active tout un modules pour un thread, tu as fait le calcul de conso ? tu as vu la remarque conso que j'ai écrite sur OROCHI ? tu étais où ces 7 derniers mois

-Mais c'est quoi l'herbe à la mode, là ? Tu compare quoi, là ? au juste

Et Je fais preuve encore d'indulgence sur les inepties dites sur les TDP des DENEB, auquel je donne un élément flagrant de réponse.

Allez les enfants, restons cool, il y a de bonnes nouvelles
 
http://www.fudzilla.com/home/item/ [...] production
 
A10 and A8 shipping in Q2

On appel ça enfoncer des portes ouverts

ou alors on part sur des cores Bobcat/Jaguar@5Ghz...

J'ai pas dit le contraire, c'est simplement que là, si j'ai bien compris, elle n'est plus partagée.