Reprise du message précédent :
Perso, je sens mieux la Xbox2 sur ce coup

la xbox 2 est prevu pour le 01/04/05 , ca viendra vite

mais ya que moi qui trouves que twin snakes sur GCest beaucoup plus moche au niveau des textures que metalgearsolid2 sur PS2 ??
 
j ai les 2 hein pour dire ca j ai comparé

pas sur que ce sois le topic

exact

Madame Irma à parlé

Ah oui mon calendrier m'indique que nous sommes Vendredi  

toutes les prochaines consoles serotn multi proc
donc ca sera pas tellement +difficile de developepr dessus, y'a des outils sympas pour ca, mais ca sera plus difiile d'optimiser par contre
 
et ce sur ps3, xbox 2 ou revolution ...

Ouais enfin après la PS2, la saturn, la jaguar, et la MD, ils savent optimiser les gens now

mouais bof, a la rigueur sur saturn c'etait le + difficile mais la, la tache est + ardue avec + de processeurs (ou de cores ds un seul processeur)

la MD est "normale" par rapport aux autres

 
oui paske les unités vectorielles de la PS2, les deux proc (différents) de la jaguar et les 4 plans indépendants de la MD, c'était plus de la fiotte que 2 procs avec systemes hyperthreading qui font tout tous seuls
 
Franchement, pour moi le bi proc pose pas trop de pb, suffit de threader plus de trucs quand c'est faisable. J'ai plus peur des trucs zarbs style 4 mo de vram . là faut optimiser.

Enfin je part du principe que y'aura pas de couilles comme dans la saturn aussi hein

dans le cell en theorie il y aura 16 cores en meme temps
(donc au moins 16 threads simultanés) dans la xbox 2 au - 6 ...
 
et je peux te dire que l'optimisation d 'algorithmes sur des multiprocesseurs n'est soovent pas chose triviale

ouais, bein je vois pas quoi faire de temps de threads si tu veux mon avis, mais bon

des besoisn sont créés pour les programmeurs
ils sauront les utiliser a bon escient, mais ca va augmenter la complexité des developpements a coup sur (et donc leurs couts)

Ca devient débile
une console n'est pas un serveur Web.  
A moins qu'ils veulent utiliser des threads pour des taches en générale réservées à des copro (son, E/S, etc ...), mais bon ...

john carmack lui meme a critiqué le choix de multi proco pour les noovelles consoles ....

 
Multi-cores plutot (mais bon ca revient au même). Mais bon y'a pas que Sony qui développe des processeurs multi-cores, y'a Intel, AMD, Sun, IBM etc... Donc y'est bien gentil Johnny mais je pense que si tout les constructeurs le font c'est qu'il y a bien une bonne raison.

la raison, c'est qu'ils ont pas le choix
ils n'arrivent plus à monter en fréquence comme avant, donc multi-core pour compenser...

la coorse a la puissance ...

Mon avis, c'est que ca sert à rien.
 
C'est utile dans le cas d'applications multiples sur une machine ou gérant des accès multiples (SGBD, web, calculs distribués, compilation distribuée), mais pas dans le cadre d'un jeu.
 
Pour un jeu, on veut un ou au mieux deux processus : un qui bourrine des transformations matricielles (donc si possible de SIMD, le plus rapide possible, bien pipeliné etc ...), l'autre qui fait le reste (IA, et tous les trucs débiles)
Pour le reste, des copro font très bien le boulot, même mieux qu'un processeur (APU, GPU, puce réseau, etc ...)
 
bref, une PS3 avec 16 unités logiques, ca sert à rien. Enfin on verra Je suis impatient de voir ce que ca va donner
 
Machine idéale :
Un CPU+FPU moyen, une FPU SIMD ultra bourrine, un GPU ultra bourrin (avec là par contre plein d'unités parallèles, surtout pour les shaders. le texturing, il se démerde on s'en fou tant que le fillrate suit, idem pour la tesselation), et pour le reste, le mini syndical (réseau 100 MBps, son 5.1, entrées sorties USB2.0)
et surtout, de la ram, ce qui manque le plus à la PS2 qui en dehors de ca est bien sympa sur le papier ...

 
la raison est simple, ils n'arrive plus a augmenter autant les perfs d'un seul proc qu'avant. donc ils les multiplient.
 
edit : by snip

 
Carmack parle de son domaine, en l'occurrence les jeux vidéos et il parle en connaissance de cause vu qu'il a développé Quake III pour tirer profit des systèmes SMP. AMD, intel Sun ou IBM ont leur roadmaps adaptés aux besoins de leur client, en l'occurrence là tu parles de processeur pour stations de travail, Carmack précise juste que ce n'est pas forcément ce qu'il y a de mieux dans le domaine du jeu vidéo.

d'ailleurs opengl est utilisable que par un seul thread, d'où ces commentaires

open gl ui, mais pas des librairies surcouches d'open gl et qui sont elles utilisées en pratique

et lesquelles ?

vtk et open dx (pas sur poor cette derniere)

 
On verra bien mais jusqu'à maintenant bien que les choix technologiques de Sony ont été souvent décriés par le passé avec la PS2 (Unités vectorielles difficiles à programmer, RAM pas suffisante etc...) on peut quand même remarquer que cette dernière arrive encore à nous étonner (cf MGS3, FF12, GT4 etc...)malgré les années qui commencent à peser par rapport à la X-Box par exemple.
 
Donc je pense que ca va peut être faire pareil avec la PS3, que les developpeurs vont galérer au début jusqu'à pouvoir, une fois celle-ci maitrisée, en tirer la quintescence...

 
Pour Sony on ne peut pas critiquer pour l'instant en effet et je ne dis pas que c'est une mauvaise solution loin de là, de plus ils semblent vouloir s'orienter vers une soilution assez différente des autres où le CPU jouera un plus grand rôle. Dans une archi comme celle là ça se justifie.
 
Jusqu'à présent on peut juste dire que les systèmes multi processeurs ont souvent eu du mal à être exploités par les programmeurs. Là où Sony sera attendu ce sera au niveau des outils de dev.
 
Pour Quake c'est de l'OpenGL pur, pas de surcouche, le thrading est explicite : un thread gère toutes les commandes OpenGL et les envoie à la carte, l'autre thread se charge de la partie game logic. Un CPU opère donc comme une sorte de back end géométrique, ce qui explique aussi qu'avec les cartes récentes Quake III ne tire pas vraiment profit du SMP.

 
elle est pas kompliké la MD ya k un seul CPU !!  
 
la SFC par kontre c etait l enfer
 
 

étonnant ca.
 

koi ?

ouais le cpu "principal" de la snes est même pas 16 bit

 
oui c est un  8 bit custumisé 16 bit,  un 8/16 bit (de l apple II gs) , tres lent mais  avek plein de copro.
 
le pb c est ke les programeurs avaient tres peu d'info sur comment s'y prendre : resultat les 1er jeux, bien ke tres beau, ramaient a mort par moment  (super EDf, Rtype, GnG, F.fight etc)

pis ensuite les copros dans les cartouches, superfx et tout le bazar, encore mieux!  

oui enfin la deja ils maitrisaient deja bien la bekane.

les dernières cartouches (SA-1) remplaçaient carrément le CPU de la SNES par un nouveau (le même) mais à 10mhz

 
perso j'adore le concept de racheter un CPU pour chaque jeu

heureusement que le CPU ne valait plus rien par rapport au prix total de la cartouche
ce serait intéressant sur neo geo ça en fait

ben c etait le cas