Reprise du message précédent :
Ou du précalculé par autre chose rejoué

 
Cf: la démo du HD 4ooo chez les bleu...  

voui et VLC

AMD ne fait pas ça voyons d'après cocoteland
Des performances très intéressantes qu'ils disent ²

D'ailleurs bulldozer est excellent (en crypt .. seulement)

C'est un excellent presse papier dans sa boîte en ferraile

Fuck ! Le Trinity gére ça maman ! Au my god en 3 écrans c'est "fluide" bon ok le jeu est loin d'être à fond mais bon , c'est qu'un APU !

 
du calme, du calme

Pour une fois que je pense que les ingé d'AMD on enfin quelque chose de bien...et qui ma tout l'air d'avoir du ptentiel... je vais pas aller...

En tout cas on dirait que trinity commence mieux que BD ( en même temps c'est pas très difficil... )

ne confonds pas Trinity et l'archis BD.
 
mais oui Piledriver a l'air de plus en plus attrayant...

Je ne confond pas disons que comme tu le dis...pour moi Trinity mais surtout l'archi' piledriver parait plus attrayant...après je vais attendre les tests avant de faire des commentaires sur les performances car au final on sait pas grand chose niveau perf' pour Trinity ni pour Pildriver...

Après ,le lancement sera sûrement un bien meilleur lancement que celui de BD ( niveau presse\critique ) fin je l'espère

La peau de l'ours, toussa

oui enfin chez  CCL, j'ai peu être pas très bien compris, mais apparemment le proc aurai 2 gravures !
 
du 32 pour le CPU et du 28nm pour le GPU !!! oO

A mon avis, t'as pas bien compris C'est quoi ta source ?

Au fait, tu t'es penché dessus ?

CCL... lien sur la page précédente !

Ha ok, CowCotLand Effectivement, ils le disent :

Mais c'est sans doute eux qui n'ont pas bien compris

Je suis out, c'est à partir de 6 Millions d'itérations que l'issue change, mais même pas le résultat. J'y comprend rien.
C'est la première fois que je suis parfaitement dans le néant, et que je m'y sens .. inutile

HP donne des indications sur le Trinity mobile A6-4400M

Y a un mec qui a commenté la news et il dit à propos de Buldo :

" Ben justement, Mes collègues ont fait des testes sur des programmes de calculs scientifiques, tant que tu reste dans la L1, l'IPC est tout simplement bon par rapport au Phénom II. C'est quand tu tapes dans la L2 que ça s?effondre sans raisons apparent.
D'après eux s'il y a un bug, en le corrigeant c'est au moins 25% d'IPC en plus.
Par contre la L3, pas de chiffres transcendant car la L2 est trop gros pour leurs calculs."

A votre avis ça tiens la route ?

non..
-Trinity n'a pas de L3. et d'un ;
-Et de deux, ce n'est pas un bug, c'est une parité nécéssaire pour que le miss rate d'un core n'explose pas à cause des deux cluster Int présents, qui y stockent des infos sur leurs calculs. son nom, c'est le Cache Snooping, entre autres choses. Et ça ne ressemble en rien à un bug qui se corrige. C'est tout une archi à remanier dans ce sens

Il parlait de BD ( Désolé je n'ai pas précisé )

En tout cas merci pour cette précision/explication

si tu parle d'OROCHI, ce n'est pas nouveau depuis Octobre '011 on le sais, ça ..

Ouep !

Bref tout ça pour dire que des fois il faudrait que je me taise...  

 
 
ou si il y a qqch à faire en urgence se serait d'augmenter drastiquement la taille du L1 !
 
c'est dur à faire ? ... et tant soit peu que cela soit dur à faire, si cela fait gagner 20%... faut le faire quand même !!!  

Si mes souvenirs sont bon c'est comme sur le P4 un cache L1 de 16Ko ( surement pour facilité l'OC ) . Par contre j'espère que les caches vont être retravaillé en profondeur car le L2 vas presque à la même vitesse que le L3 mais surtout que dans certain cas les données sont transféré du L3 directement dans le cache L1 et ça peut provoquer un nombre plus important de cycle a cause d'une particularité des caches dont je me souviens plus ! Je vais essayer de retrouver un article qui explique bien la chose

PS : Si je dis des conneries merci de me le dire !
PS 2: Les caches seront surement très différent entre BD et Trinity !

la taille des L1 n'a rien à voir la dedans.
Leur importance prime sur le débit des instructions décodées et enregistrées pour le L1I et le flux brute des données calculées que ce soit par entier, par flottant voire par code, pour le L1D. Leur taille ne dépend que de l'orientation de l'archi "Taux de traitement par cycles élevé" ou "Taux de cycles par traitement élevé". Il existe un compromis, mais aucune simulation à l'heure actuelle n'apporte de résultats concluants, sur ce sujet.
Bref jusqu'à présent AMD avait choisit l'option 1, et à présent c'est l'option 2. Le nombre d'étage du pipeline et le cache primaire de petit taille étayant déjà bien l'orientation de cet architecture CPU.
C'est un choix. En augmenter sa taille ne ferai que dégradé la situation.

-c'est le Write-Trough dont tu veux parler ?
 
-BD et trinity ? rien que le fait qu'il n'y est plus de L3 fait déjà bien changé la donne, niveau cycles perdus.

 
http://bbs.pceva.com.cn/thread-40164-1-1.html

De toute façon, superpi, c'est overrated : AMD va nous faire de jolis slides pour dire qu'on va plus vite lorsqu'on encode en H264 ses films de vacances faits sur VHS à l'époque avec un Trinity plutôt qu'avec un Llano...
En gros, on a des FPUs 128/256 bits incapables de cracher du x87/du code non optimisé comme il faut
23.775s à 4,2GHz
26.039 à 2,9GHz
~9% de gain vs ~45% d'augmentation de fréquence

edit: si on reste dans la même enveloppe thermique, on va pas trop se plaindre
Le gain sur le GPU est raisonnable. Peut être même que ça peut être un produit intéressant.
M'enfin, ces perfs là, ça serait mieux de les avoir à 65W de TDP

ça craint vraiment s'ils n'arrivent pas à au moins égaler Llano surtout avec 1ghz de plus ...
Edit  : oups

Hein ?
 
il l'égale certainement, je crois pas que tu lis bien l'anglais...

J'ai lu trop vite, le texte est décalé.

Sauf que tu max SPI en AC, t'as une bête de course.
Tu suces à SPI, tu t'appelles AMD

J'espère que AMD bosse avec les dev' pour qu'il exploite à fond la partie graphique de l'APU car la partie CPU risque d'être encore faiblarde sur les 2 prochaines générations (voir plus ! ) ...

PS:  Je lis bien une augmentation des perf' GPU de 50% ?  
PS2 : 4.2Ghz en turbo c'est pas mal , et 3.8Ghz sans turbo'...Sauf que les résultats ne sont pas très très bon pour une telle fréquence

Tous les dev de la planète ?  
Les logiciels utilisant le GPGPU ça reste une niche et ça va pas se démocratiser si vite que ça.
D'autre part, celui qui recherche la perf sur ce genre d'appli, il se tournerait vers quel type de solution ? APU, CPU+GPU, une ferme de Tesla ? (vraies questions)

rien de surprenant..

Pas tout les devs mais par exemple les programmes pro , ou semi pro , les moteurs physique ect...  
Et pour la question je pense que c'est une bonne question , et je ne peux te donner de réponse  

 
Effectivement...

Le chipset A85X pour Trinity en détails
 

 
 
Pour une plateforme "bas de gamme" je la trouve super bien équipé !  

 
sauf que quand je me monte un pc bas de gamme, j'ai pas de quoi lui mettre 8 DD !    
 
moi du moment qu'il nous invente un driver potable qui prenne en compte le (APU+CG)ATI=  
(c'est quoi déjà le moteur physique de chez AMD ? Havok ? je sais plus... mais le GPU serai parfait pour lui ! )

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.