Reprise du message précédent :

Simple:

 
 
edit: http://www.pcworld.fr/2009/11/02/m [...] es/456391/
 

Pcworld se mouille là.
 
 
edit2:  
 

 
Manhattan en 32nm ?

Euh ... il n'y aurait pas un petit problème, là ? Il ne gêne que moi ?  
 
Il y a peu, on a appris que le successeur d'Evergreen devait se baptiser Hécatonchire . Donc, le machin Island, c'est du flan .  Ou alors AMD a décidé de le renommer ... déjà !

Ou alors les hecatonchires sont le refresh de Cypress...
 
Il semble logique qu'AMD rafraichisse Cypress et Juniper dans la première moitié de 2010, ce qui les ramènerait à des dimensions plus raisonnables de l'ordre de 120 et 250mm², alors que dans le même temps un nouveau GPU serait en phase finale de conception sur le même process.
 
Même technique que le tick-tock d'Intel appliquée aux GPU: d'abord une archi bien connue pour se faire les dents, puis une nouvelle archi une fois le process connu.

Comment pourraient-ils revenir à des dimensions plus raisonnables sur une même archi sans perte de perfs sans diminution de la finesse de gravure ?

 
Ah ? Je croyais justement qu'Hécatonchire devait être une nouvelle archi et pas une MàJ simple ...  
Genre avec des MIMD en lieu et place des SIMD ...

 
Peut-être que le 32nm de TSMC sera prêt à ce moment-là ... avec un rendement comme d'habitude très faible ... enfin, à voir . Tous les procédés de TSMC ne sont pas forcément voués à avoir un mauvais rendement ...

Si ils ne font qu'un shrink de Cypress et Juniper du 40nm au 32nm, la taille diminuera et les perfs stagneront au pire, c'est ce qu'avait fait nVidia avec le G71.
 
Après ça ils pourraient revenir à la taille actuelle de Cypress voire à celle du R600 sur le même process avec une nouvelle archi, ce qui donnerait les +50% de perfs mini qu'on peut espérer.
 
Si je mentionne la taille du R600 ça n'est pas innocent puisque la GDDR5 n'ira pas excessivement plus vite et ne sera pas plus dense dans 1 an, donc on pourrait voir un retour du bus 512bits sur le plus gros GPU.

 
Et encore, t'es généreux envers nVidia, car ils viennent de fêter leur troisième die-shrink de la même archi (ou quatrième ? J'ai pas tout suivi) avec 90nm (?) > 65nm > 55nm > 40nm . Allez, bientôt une GeForce 8 en 32nm pour supporter PhysX ?  

Non, y'a pas de G84 en 40nm
 
Niveau shrinks, nVidia n'a fait que 80 -> 65 -> 55nm avec le G84 (G84 -> G92/G94/G96/G98 -> G9x "b" ) et 65 -> 55 -> 40nm avec le GT200 (GT200 -> GT200 "b" -> GT21x). Le G80 n'a jamais subi de die shrink.
 
Le GT212 aurait dû être un GT200 en 40nm et le GT200b devait s'appeler GT206 initialement, mais visiblement nVidia a totalement abandonné les "gros" shrinks de GT200, toujours trop chers pour être compétitifs, sans réelle capacité de production et posant problème au niveau réalisation (cf. le GT215 qui n'arrivera qu'à la fin de ce mois malgré une complexité 60% moindre).

 
Ah ? Je croyais pourtant que le GT200 était trop complexe et imposant pour être décliné en versions plus "lite" . En tout cas, c'est ce qui s'est dit partout pour justifier l'existence toujours importante des GeForce 8/9 . nVidia a résolu le problème ?  En tout cas, étant donnée qu'il y avait à peu près les mêmes nombres de shaders que pour les GeForce 8 et 9, j'ai pensé qu'il s'agissait toujours de la même archi, n'ayant jamais vu de GT200 pareillement décliné .

En fait on reconnait l'architecture du GT200 sur les die shots, et accessoirement au nombre de SP: 24-48-96, tous multiples de... 24, la taille des partitions de l'archi GT200, contre 16 pour celles des G80 et G90. Le GT218 est vendu pour 16SP, mais le die shot en montrait clairement 24.
 
Après, il y a peut-être eu des évolutions dans l'équilibre calcul/texturing/blending, j'ai pas trop fouillé à vrai dire.

Il n'y a effectivement pas eu de déclinaisons MDG du GT200 en 65/55nm.
 
Pourquoi ? Parce que le GT200 est un chip Tesla, et que le décliner en MDG n'aurait pas eu d'intérêt face aux G92/G94/G96.  
 
Ils auraient été plus gros (déjà que 330mm² pour un G92 ), et pas plus perf dans les jeux.
 
L'argument de nV sur la complexité du GT200 n'est là que pour masquer le manque de compétitivité de l'archi du GT200 dans les jeux.

Avec ClearView, les logiciels se réparent eux-mêmes
 
De curieux insectes envahissent quotidiennement les ordinateurs. Classés dans l'espèce des bugs, ces créatures numériques sont coriaces, à un tel point que nous sommes souvent contraints de céder et de redémarrer nos PC. Une situation en passe de changer grâce à des chercheurs du MIT.  
 
Vous surfez tranquillement sur Firefox, jonglant entre maints onglets, et tout à coup, le navigateur s'immobilise, comme un voilier pris dans les calmes. Bien souvent un « ctrl+alt+suppr » suffit, mais il arrive encore qu'un redémarrage de la machine soit nécessaire. Face à cette menace qui rôde à chaque instant, l'utilisateur n'a d'autre recours que d'envoyer ses rapports d'erreur en croisant les doigts pour que l'éditeur du logiciel mette au point un correctif (ou patch) pour éliminer le problème. Le processus est fastidieux et est impossible à concevoir au cas par cas. Pour les éminences grises du MIT il est temps que les logiciels se réparent eux-mêmes !  
 
Quand les PC réclament leur indépendance
 
C'est sous le nom de code ClearView que le professeur Martin C. Rinard, professeur du département de l'ingénierie électrique et des sciences informatiques du MIT (Massachusetts Institute of Technology) et membre du laboratoire des sciences informatiques et d'intelligence artificielle, et son équipe ont dévoilé leur insecticide numérique miracle à même d'éliminer ces vilains bugs de nos ordinateurs. Ce logiciel, sorte de contremaître informatique, doit jauger la bonne exécution des tâches présentes dans la mémoire vive.  
 
Il s'appuie sur cinq fondamentaux, l'observation des invariants, la détection d'erreurs, l'identification des invariants défaillants, la génération d'un correctif pour renforcer les invariants et enfin l'évaluation et l'observation des tâches corrigées suivie par la création d'autant de correctifs que nécessaires.
 

 
ClearView ne requiert pas d'intervention humaine pour effectuer sa besogne. Son aptitude à l'apprentissage et sa constante remise en question des corrections qu'il applique au système sont autant d'atouts qui permettent une meilleure personnalisation du support du système de l'utilisateur. De plus, ce réparateur officie à chaud, c'est-à-dire qu'il ne nécessite pas de redémarrage du système d'exploitation de l'utilisateur ni même de redémarrage de la tâche exécutée qu'il corrige à la volée. ClearView est compatible avec les bibliothèques logicielles des systèmes X86 Windows. Cependant, Microsoft gardant jalousement le code source de son système d'exploitation, l'application est destinée à réparer les logiciels d'éditeurs tiers.  
 
Les cinq étapes du travail précitées consistent en des procédures répétées à l'infini. Tout d'abord, lors de l'apprentissage ClearView observe l'exécution et le comportement des applications dans des conditions normales. Ces observations sont collectées sous la forme de propriétés ou, selon le terme consacré, d'invariants. Plus les observations de ClearView se multiplient plus les modèles qu'il établit s'affinent.  
 
Toujours aux aguets
 
La surveillance (souvent appelée monitoring) consiste à différencier les exécutions normales des exécutions échouées. ClearView procède alors à une localisation de la source des exécutions erronées dans les librairies. Pour détecter ces erreurs, le logiciel n'est pas seul et fait appel à deux applications de surveillance qui détectent les fameux bogues. ClearView en tant que contremaitre n'agit dont pas seul mais reçoit des rapports d'erreurs de deux de ses employés. L'un est spécialisé dans les erreurs d'écriture tandis que l'autre détecte les transferts de données qui ne correspondent pas à la politique de sécurité du système.  
 
Une fois une erreur détectée par ses deux agents de terrain, ClearView met les données fraichement acquises en corrélation avec les invariants établis lors de l'étape d'observation. Une fois le recoupement d'informations effectué, ClearView propose en premier lieu un correctif de vérification pour différencier les bonnes et mauvaises exécutions. Puis l'ange gardien numérique génère un lot de correctifs pour réparer l'invariant en cause dans le dysfonctionnement de l'application. Le but est d'assurer le bon lancement de l'application et de mettre au point un correctif après la première erreur pour éviter que celle-ci ne se propage, rendant l'erreur critique.  
 
Le processus de correction effectué est un cycle sans fin. Ainsi, après avoir corrigé les défauts d'exécution d'un logiciel, ClearView n'aura de cesse de réévaluer son travail. Les éditeurs de logiciels reçoivent un rapport détaillé des diverses erreurs notifiées et ne restent donc pas totalement sur la touche. Les vilains bugs n'ont qu'à bien se tenir, à moins que ces derniers ne s'invitent dans ClearView.
 
La source
 
_____________________________________________________________________________________________________________________________
 
Personnellement, j'avais déjà imaginé un tel concept logiciel, mais étant ado on peut difficilement mettre en oeuvre comme les chercheurs du MIT qui ont plusieurs millions d'euros de budget . Bon, l'étape suivante, c'est de mettre au point un système qui cherche lui-même ses failles exploitables par les virus/ver/autres saletés, comme ça plus besoin d'antivirus et pourtant un PC qui se défend tout seul, fait ses MàJ tout seul, ne bug plus jamais quoi ...  En tout cas, un tel OS ne sera certainement pas Windaube, Microsoft gardant son code source top secret .
 
On peut imaginer aussi un PC qui, reconnaissant le matériel selon certaines propriétés, génère un pilote automatiquement pour devenir compatible ... Bon, évidemment, ça ne vaudra jamais un pilote constructeur, mais ça aura le luxe d'assurer la compatibilité de tout le matériel en toutes circonstances . Pour les fonctions avancées, il faudra soit un pilote constructeur, soit le système sera assez développé pour sortir lui-même les options avancées en fonction de ce qui est régulable softwarement .

Et personnellement je trouve que ça ressemble beaucoup au VPU recover des Catalyst et au popup d'IE quand un script tourne en rond...
 
Le problème de la solution ici proposée est qu'elle est basée sur les statistiques (recherche des invariants), donc statistiquement imparfaite (on ne peut prétendre à la perfection que si on connaît réellement le problème, les statistiques réduisant le problème à une proportion plus ou moins large de cas majoritaires).

 
Tu l'aurais préférée basée sur quoi d'autre que les statistiques, la solution ? Mh ?

Il n'y a pas de solution, tout simplement.
 
D'un point de vue théorique, "ça pète", mais du côté de la pratique c'est aussi fiable que la prédiction de branchement, et tu te doutes bien que si on pouvait prédire un branchement avec certitude, c'est qu'il y aurait un souci.

A tout problème, sa solution .
Je suis sûr qu'on finira par trouver cette fameuse solution, si nos chers scientifiques du MIT ne l'ont pas déjà fait .  
Il y a plusieurs dizaines de technologies très prometteuses comme celles-là dans le monde de l'informatique (au sens large) . Alors, pourquoi pas celle-ci ?
 
Et puis si ça marche pas maintenant, ça marchera plus tard, comme toujours .

IL n'y a que 2 solutions à ce problème:
 
- compter sur l'utilisateur pour corriger le programme ( )
- faire ce que fait M$ depuis maintenant un bon moment et générer un rapport d'erreur, qui permettra de corriger le problème à posteriori (pile d'appels + code d'erreur).
 
Il s'agit d'un problème insoluble, s'approcher de la solution nécessite d'augmenter exponentiellement la complexité de la méthode de correction et si il faut une certaine quantité de ressources pour éliminer 50% des erreurs, il en faudra le double pour arriver à 75% et ainsi de suite.
 
Comment un programme (ou matériel) pourrait-il deviner quelle est la BONNE solution? Avec ce type de correction on s'exposerait inévitablement à de nouvelles erreurs, la phase "évaluation des corrections candidates" débouchant forcément sur une boucle qui elle-même contient un saut en arrière conditionnel hors de la boucle vers une nouvelle instance de la première phase, jusqu'à monopoliser les ressources à l'infini pour éviter une boucle infinie (paradoxal, non?).

 
Le programme peut imaginer la solution ... pourquoi un PC serait-il incapable de faire une recherche de bugs ? On a rarement étudié la question, voilà pourquoi ça paraît inconcevable aujourd'hui . Mais, en fait, il pourrait très bien le faire . Il y a plein de solutions pour ça . On peut même laisser au programme le loisir de trouver la meilleure solution avec la nouvelle IA à motivation artificielle . Ce truc-là, c'est une tuerie .

Je ne sais plus si je l'avais déjà posté ou non :
**************
 
Avez-vous vu l'analyse de BSN concernant la roadmap d'AMD/ATI ?
 
A ce que j'en ai compris et d'aprés eux et leur "insistance" auprès d'AMD pour des explications, la prochaine architecture << Northern Islands >> qui va succéder à l'actuelle, utilisera surement le process 32nm et la certification DX 11.1 ; mais étant donné que les caractéristiques de dx 11.1 ne sont pas terminées, il se peut que les 5k ne le supportent pas. Les 6k seraient alors un die-shrink des 5k avec quelques améliorations dont notamment le support de dx 11.1. Enfin, d'après leurs infos, ce serait AMD japon qui aurait pondu cette roadmap sur des données erronées.
 
http://www.brightsideofnews.com/ne [...] ocess.aspx
 
Les GPU << Northern Islands >> en 32nm annoncés sur cette roadmap pour 2011 devraient en toute logique être indiqués pour la seconde moitié de l'année 2010 et produits par globalfondries.
 
Enfin, il y a une probabilité que les 5K soient compatibles dx11.1 matériellement parlant, tout dépend de Microsoft, on en saura plus prochainement.
Quant à Fudzilla, ils sèment encore plus la confusion en nous rapportant qu'AMD pourrait sauter le 32nm au profit du 28nm pour son prochain GPU... Entre AMD Japon qui aurait constitué une roadmap sur des données erronnées et fud qui en remet une couche, on ne sait plus trop à quoi s'attendre !
 

source : http://www.fudzilla.com/content/view/16299/1/

Et a-t-on idée de ce que sera DirectX 11.1, techniquement parlant ?
 
Pour le 32nm, TSMC risque d'être une nouvelle fois à la ramasse . Mauvaise nouvelle ..

DirectX 12 and DirectX 11.1
 

source : http://www.osgenius.com/directx-12-and-directx-11-1/

On peut déjà parler de DirectX 11.1, mais DirectX 12, c'est encore un peu tôt . On a encore aucune idée de ce qu'apportera cette nouvelle API, qui sortira probablement ... en même temps que Windows 8 ?  
 
Dis, super_newbie_pro, tu ne crois pas qu'il faudrait organiser un peu ce topic ? Là, toutes les news sont en vrac ...
Dur, dur, de s'y retrouver ..

mdrrr... Les news arrivent au fur et à mesure... Que veux-tu que j'y fasse ? xoD Faut suivre au fur et à mesure voire prendre le train en route lol

Merci pour mes finances, je vais pouvoir attendre la prochaine génération de cartes graphique ^^

 
 
Tu t'y es toi-même perdu . Or, tu suis davantage les news que personne, ici . Pour te citer :
 

 
Il faudrait par conséquent un premier post bien rédigé classant les news par genre .

Il est possible qu'AMD sorte un shrink de son RV870 dès le 3e trimestre 2010.

 
 
 

 
Une news très intéressante à propos du 32nm de GlobalFoundries :

Il est même "possible" qu'AMD utilise la T-RAM dans ses GPU :

C'est une possibilité, mais mieux vaut ne pas trop se faire d'illusions car il est probable qu'AMD réserve la T-RAM pour ses CPU.
 
 
Taille de la T-RAM vs SRAM :

T-Ram ? C'est quoi ça encore... erf erf tellement de nouveautés ^^ faut que j'aille fouiner sur wiki lol

La T-Ram c'est ce qui remplace la Z-RAM

 
Euh, pas exactement, c'est l'un des successeurs potentiels de la SRAM, tout simplement .
La Z-RAM était aussi l'un des candidats prometteurs, mais GF a visiblement fait son choix .
En résumé, ça permettra d'augmenter la quantité de mémoire cache, c'est ça ?

Le tableau est assez clair je pense
 
"6T" correspond à de la SRAM classique, qui se compose de 6 transistors par bit, et en gros la densité de cache pourrait effectivement être multipliée par 4... mais à ce niveau on est très proche de la DRAM.

drap'

 
Pour drapaliser faut poster une news qui n'a pas déjà été postée, qui est en rapport avec le sujet, et qui est intéressante

Ah oué, d'accord

C'est histoire d'avoir de nouvelles news, BIERMAN ..

en fait c'est un topic de journalistes sans lecteurs  

Je n'ai pas de pass-presse

 
En voilà un qui ne le sait même pas    
 
PS :

IBM simule le cerveau d’un chat
 
IBM vient de franchir une étape symbolique dans la création d’un ordinateur capable de penser comme un homme.
 
De l’homme au chat
 
IBM a simulé le cerveau d’un chat à une vitesse cent fois moins rapide que la réalité. La simulation a permis d’analyser la formation de pensées dans le cerveau et l’interaction des neurones et synapses. Pour réaliser ce test, IBM a montré une image de son logo et à regarder comment la machine arrivait à reconnaître ce que la photo représentait. En début d’année, la firme avait réussi à simuler le fonctionnement de 1 % du cerveau humain, grâce à 147 456 processeurs et 144 To de mémoire.
 
Un petit pas pour l’homme...
 
Il reste encore beaucoup de chemin à faire avant que cette technologie soit réellement exploitable, mais les ingénieurs d’IBM imaginent le jour où une machine pourra traiter et analyser un flux incroyable d’information tout en possédant les facultés cognitives lui permettant de prendre les décisions les mieux adaptées en fonction de problèmes abstraits et de raisonnements logiques.
 
Big Blue reste néanmoins encore très loin du cerveau humain qui pèse seulement un peu plus d’un kilo, et dont le cortex contient suffisamment de synapses pour retenir environ 1 000 To d’informations, soit l’équivalent de 23 400 DVD.
 
La source
 
__________________________________________________________________________________________________________________________
 
Un pas de plus pour l'Homme ou pour l'arrivée de Skynet ?

CPU:

 
 
 
PS: La construction/upgrade du plus puissant super ordinateur du monde (Basé sur des CPU AMD) -> YouTube