pour carbonboss
-------------------------- CPU ----------------------------
--> Le processeur de la 360 a été conçu pour donner aux developpeurs la puissance dont ils ont besoin réellement, dans une forme facile d´utilisation. Le cell a une puissance de calcul en virgule flottante impressionnante limitée pour des jeux.
-->La majorité du code d’1 jeu est un mélange de nombres entiers, à virgule flottante, et de vecteur, avec un bon nombre de branches et d´accès mémoire aléatoires. Ce code est mieux manipulé par un « general purpose CPU » avec du cache, un « branche predictor », et une « vector unit ».
-->Les 7 SPEs n’ont pas de cache, pas d’acces direct à la mémoire, pas de « branch predictor », et un ensemble d’instructions différente du principal CPU. Ils ne sont pas conçus pour etre efficace pour le « general purpose computing ». Les SPEs ne sont pas du tout adaptés pour le programmation de jeux.
-->La 360 possede 3 cœurs « general purpose CPU ». Le cell en a qu’un.
-->Le CPU de la 360 possede le « vector processing power» dans chaque cœur. Chaque cœur possede 128 « vecters registers » par thread, avec une « dot product instruction » et 1MB L2 cache partagé. Le « processor’s vector power» du cell est, quant à lui géré par les SPEs la plupart du temps.
--> Les « dot products » sont essentiels aux jeux parce qu´ils sont employés dans les maths 3D pour calculer des longueurs de vecteur, projections, transformations, et plus. Le CPU de la 360 a une « dot product instruction », la où d´autres CPU tels que le cell doivent émuler le « dot product » en utilisant des instructions multiples.
-->Le « streaming floating-point » du cell est effectué par les 7 SPEs. Puisque le traitement de la géométrie est déplacé au GPU, le besoin du « streaming floating point » et de tout autre modèle de DSP(les SPE du cell sont des dsp) a chutté pour la programmation des jeux.
--> Tout comme l’emotion engine, avec le cache L2 absente, le cell est conçu pour un type de programmation de jeu, ce qui explique un pourcentage mineur de « processinf time ».
--> Le cell est idéal pour un environnement où 12.5% du travail est du « general purpose » et 87.5% du travail sont des calculs de DSP. Un tel melange prends du sens pour la lecture de video ou pour des taches réseau, mais pas pour des jeux. En fait, en analysant les vrais jeux, on trouve presque la distribution opposée entre « general purpose » et « DSP calculations ». Un pourcentage relativement petit des instructions sont réellement en virgule flottante. De ces instructions à virgule flottante, très peu impliquent le « continuous streams of numbers ». Au lieu de cela ils sont employés dans des taches comme l’IA et le « path-finding » , qui exigent l´accès sélectif à la mémoire et aux « frequent branches » pour lesquelles les DSPs sont mal assorti.
--> Basé sur des mesures des jeux de prochaine génération, seulement ~10-30% des instructions exécutées sont en virgule flottante. Le reste des instructions sont « load, store, integer, branch, etc. » Même moins des instructions exécutées sont en virgule flottante. ~5-10%. Le cell est optimisé pour le « streaming floating-point », avec 87.5% de ses coeurs bons pour le « streaming floating-point » et rien d’autre.
-->Les programmeurs de jeu ne veulent pas partager leur code sur plus de huit processeurs, particulièrement quand sept des processeurs sont mal appropriés au « general purpose computing ». De toute facon, repartir du code a travers 8 processeurs est tres difficil.
-------------------------- GPU ----------------------------
->Meme en ignorant les limitations de la bande passante du RSX, le XENOS est plus puissant.
Below are the specs from Sony´s press release regarding the PS3´s GPU.
RSX GPU
550 MHz
Independent vertex/pixel shaders
51 billion dot products per second (total system performance)
300M transistors
136 "shader operations" per clock
-->Le nombre intéressant en ce qui concerne l’ALU(unité de calcul) est 51 milliards de « dot products » par seconde (performance totale du systeme), 300M de transistors, et plus de deux fois plus puissant que les 6800 ultra.
--> Les 51 milliards de « dot products » par cycle ont été annoncées pour les performances totales du sytel graphique et incluent le cell. Les calculs de Sony semblent supposer que le cell peut faire un « dot product » par cycle par DSP, en dépit de ne pas avoir une « dot product instruction » (calcul de dot products)
--> Cependant, en utilisant les dires de Sony, 7 « dot product » par cycle * 3.2 gigahertz = 22.4 milliards de « dot products » par seconde pour le CPU. Ca laisse 51 - 22.4 = 28.6 milliards de « dot products » par seconde qui sont laissés au GPU. Ca laisse 28.6 milliards de « dot products » par seconde/550 mégahertz = 52 ops de GPU ALU par cycle d’horloge.
-->Il est important de noter que si les ALUs du RSX sont semblables aux ALUs des GeForce 6800 alors elle fonctionne en vector4s, tandis que les ALUs du Xenos fonctionnent en vector5s. La performance totale programmable du RSX en virgule flottante pour la ps3 serait
52 ops d´ALU * 4 floats par op(vector4s) * 2 (madd) * 550 mégahertz = 228.8 GFLOPS, ce qui fait moins que les ops de la 360 : 48 ALU * 5 floats par op(vector5s) * 2 (madd) * 500 MHz= 240 GFLOPS.
-->Avec un nombre legerement plus élevé de transistors sur la 360 (330M), il n’est pas etonnant que ces nombres soient proches.(228.8~240).
--> Le PS3 a les 7 SPEs dans le cell pour ajouter plus d´ops à virgule flottante pour les graphismes, mais les 3 cœurs de la 360 (capable de traiter du general purpose) avec une carte 3D dédiée et les « dot products » sont plus adaptés aux calculs graphiques.
-->Les 6800 Ultra ont 16 pixel pipes, 6 vertex pipes, and fonctionnent aà 400 MHz. Etant donné que le RSX est l’equivalent de 2 6800 Ultra et possede une frequence plus élevée, on peut estimer qu’il y aura 24 pixel shading pipes and 4 vertex shading pipes (moins de vertex shading pipes depuis que les SPEs du cell effectue un certain nombre de vertex shading). Si le RSX garde le pixel shader pipe des 6800(en parallèle) annoncé par sony, cela leur donne encore 24 pixel pipes* 2 issued per pipe + 4 vertex pipes = 52 dot products par cycle d’horloge clock pour le RSX.
--> Si le RSX suit la meme route que la 6800, il aura 24 texture samplers, qui, pendant leur utilisation prennent un slot d´ALU, rendant le RSX dans la pratique moins impressionnant. Même si il parvient à utiliser le « fetch » de l’ALU, il n’y aura pas assez de bande passante pour « fetcher »(^^) les textures.
--> Pour des opérations de shader par cycle d’horloge, Sony compte probablement chaque pixel pipe comme quatre opérations d´ALU (co-issued vector+scalar) et une opération de texture par pixel pipe et 4 opérations scalaires pour chaque vector pipe, pour un total de 24 * (4 + 1) + (4*4) = 136 opérations par cycles ou de 136 * 550 = de 74.8 GOps par seconde.
--> Etant donné le multithreading de la 360 de GPU et sa conception équilibrée, on ne peut pas vraiment comparer les deux systèmes en termes de « shading operations » par horloge. Cependant, le Xenos peut faire 48 opérations d´ALU (chacun peut faire un vector4 et un op scalaire par horloge), 16 textures fetchs, 32 control flow operation et 16 opérations programmables de vertex fetch avec « tessellation » par horloge pour un total de 48*2 + 16 + 32 + 16 = 160 opérations par cycle ou 160 * 500 = 80 GOps par seconde.
--> De façon générale, l’automatique « shader load balancing », dispositifs d´exportation de mémoire, vertex fetching programmable, triangle tesselator programmable, full rate texture fetching in the vertex shader, et autre dispositif "well beyond shader model 3.0" du Xenos devraient également contribuer à la performance globale.
-------------------------- Bande passante ----------------------------
The PS3 has 22.4 GB/s of GDDR3 bandwidth and 25.6 GB/s of RDRAM bandwidth for a total system bandwidth of 48 GB/s.
--> Le PS3 a 22.4 GB/s de bande GDDR3 et 25.6 GB/s de largeur de bande de RDRAM pour une largeur de bande totale de système de 48 GB/s.
--> La 360 a 22.4 GB/s de la largeur de bande GDDR3 et des 256 GB/s de largeur de bande d´EDRAM pour un total de largeur de bande totale de système de 278.4 GB/s.
--> Pourquoi le Xbox 360 a-t-il une quantité si extrême de largeur de bande passante? Même les calculs les plus simples prouvent qu´une grande quantité de largeur de bande est consommée par le frame buffer. Par exemple, avec un simple rendu de couleur et le Z testés à 550 mégahertz, le seul frame buffer exige 52.8 GB/s à 8 Pixel par clock d’horloge. La largeur de bande de mémoire de PS3 est insuffisante pour maintenir la vitesse de rendu maximale de son GPU, même sans texture et vertex fetch.
--> La PS3 emploie la compression Z et couleur pour essayer de compenser le manque de largeur de bande de mémoire. Le problème avec la compression Z et couleur est qu’elle se décompose rapidement dans des scènes 3D complexes.
--> HDR, alpha-blending, et anti-aliasing exigent bien plus de largeur de bande de mémoire. C´est pourquoi la 360 a la largeur de bande de 256 GB/s réservée juste pour le frame buffer. Ceci permet au Xenos d’effectuer les Z testing, HDR, et l’alpha blended color rendering avec 4X MSAA à pleine vitesse et d´avoir toujours la largeur de bande principale entière de 22.4 GB/s pour des textures et des sommets.
| VS | 
|
