UNOS POCOS CONCEPTOS SOBRE CPUs
Para entender bien la propuesta de Sony y Microsoft para la CPU de sus nuevas consolas, hay que conocer los conceptos de “ejecución fuera de orden” y “unidades de ejecución”. Esto es lo que voy a tratar con un mínimo de detalle, pero muy brevememente, en este apartado. A quien no tenga mucha idea, puede parecerle un poco rollo al principio, pero creéme que cuando comprendes estás cosas, muchas se empiezan a volver más interesantes. Y no es nada complicado. Eso sí, es para tomarselo con calma 
Poco a poco, los artículos se han ido complicando, y os aviso que en este artículo voy a dar mucha caña. Pero la recompensa es dulce n_n
- Ejecución en orden : Los procesadores se encargan de ejecutar las instrucciones que componen un programa. La ejecución en orden, es un tipo de ejecución, en la cual las instrucciones se van ejecutándo en orden, es decir, la segunda después de la primera, y la tercera después de la segunda. La CPU trae la instrucción que toca de la memoria, la decodifica para ver que hay qué hacer, y la ejecuta. Después, con un registro especial (el contador de programa) apunta a la siguiente instrucción, la trae, la decodifica, ejecuta, y de nuevo apunta a la siguiente,… Cada procesador tiene un reperorio de instrucciones, esto es, una lista con todas las posibles instrucciones que entiende, y que sabe ejecutar. Cada CPU tiene el suyo. Y hay repertorios más potentes que otros. Pero eso es algo que trataré en otro artículo. Para entender mejor esto, que puede resultar muy abstracto, voy a poner un ejemplo de programa inútil y super simple, y aunque te lo puedes saltar si lo ves complicado, es interesante aunque sea seguirlo un poco. Es para una CPU sencilla, el MC68000 (usado en la Megadrive, NeoGeo, Arcade,…).
MOVE.W #32, D0
ADD.W D1,D0
MOVE.W D0, $FF0000
OR.W D2, $FF0000
Que no cunda el pánico. Cada línea es una instrucción, y cada instrucción hace una cosa. Veámos el qué.
El MOVE transfiere un dato de un lugar a otro, dentro o fuera de la CPU. El ADD realiza una suma, y el OR lleva a cabo una operación OR lógica. Por tanto el anterior programa haría lo siguiente:
- Trasnfiere el número 32 a un registro de la CPU llamado D0.
- Suma el valor que contenía el registro D1 al que tiene D0 (en este caso, sabemos que es 32, porque lo acabamos de meter), y guarda el resultado en D0.
- Tranfiere el contenido de D0 (que ahora es la suma de 32 más el valor que tenía D1), a la posición de memoria $FF0000.
- Realiza una operación OR lógica del valor que contenga el registro D2, con el valor de la posición de memoria $FF000 (que contiene el resultado de la suma que acabamos de almacenar).En la Megadrive, por ejemplo, la dirección $FF0000 corresponde con el primer byte de la memoria RAM, así que en una Megadrive, el resultado de la suma quedaría almacenado al principio de la RAM al ejecutar la instrucción MOVE.W D0, $FF0000. Esto varía de un sistema a otro. En la Super Nintendo, por ejemplo, la posición $FF0000 corresponde a una zona de la memoria ROM del cartucho, y no se puede copiar nada ahí. Es de sólo lectura. La RAM está en otra zona. Además, la Super Nintendo no usa un MC68000 sino un 65c816, y por tanto no entendería la instrucciones del MC68000. Cada CPU tiene su propio repertorio.
La secuencia de instrucciones va generando todo lo que hace un programa, pasito a pasito. Como podrás imaginar, hacer cualquier pequeña cosa perceptible requiere miles de instrucciones (o incluso millones). Una CPU moderna ejecuta miles de millones de instrucciones por segundo.
- Ejecución fuera de orden: El concepto se basa en permitir que la CPU ejecute las instrucciones en un orden distinto, para poder aprovechar mejor sus recursos. Para ello, se ha de dotar al procesador de una compleja circuitería. Se trata de ir trayendo las instrucciones a un pequeño almacen, donde la CPU las examina, y decide qué orden será el más adecuado para conseguir el mejor rendimiento, asegurándose de que no cambie el comportamiento original del programa, claro. Cosa muy pero que muy chunga, así que no entraré en detalles sobre cómo se hace.
Una vez que una instrucción ha sido elegida para ser ejecutada, la CPU la manda a una de sus unidades de ejecución, que son los circuitos que realmente se encargan de efectuar la operación requerida. Una CPU puede tener muchas unidades de ejecución, cada una de las cuales tiene un cierto cometido.
Por ejemplo, el Athlon de AMD tiene:
- 3 unidades para coma flotante (FP)
- 3 para números enteros (ALU)
- 3 para generar direcciones (AGU)
- 1 para almacenamiento/carga. (LSU)
No es suficiente con decir el número de unidades de ejecución. No todas operan igual, ni son igual de rápidas. La forma en la que se alimentan es clave. ¿De qué valen muchas y muy potentes unidades de ejecución, si no eres capaz de mantenerlas abastecidas de trabajo? La historia es que cuando una CPU puede ejecutar instrucciones fuera de orden, como es el caso de todas las CPUs de los PCs y los MACs, éstas se van distribuyendo a las diferentes unidades de ejecución no en la secuencia original, sino en el orden que procura que éstas van a estar ocupadas el mayor porcentaje de tiempo posible. Lo cual puede aumentar mucho el rendimiento respecto a una CPU que, aún teniendo las mismas capacidades de ejecución, no sea capaz de aprovecharlas.
Supongamos una CPU que ejecuta en orden, y otra fuera de orden. Ambas tienen 3 unidades de ejecución para coma flotante, y 3 para enteros. Cada operación lleva un ciclo en ser completada. Imagina que de repente, llegan 5 instrucciones de operación con enteros (INT), y después 4 en coma flotante (FP). La ejecución sería, en un hipotético caso muy simplificado e idealizado, la siguiente:
Ciclo 1 INT1 INT2 INT3 INT1 INT2 INT3 FP1 FP2 FP3 Ciclo 2 INT4 INT5 FP1 FP2 FP3 INT4 INT5 FP4 Ciclo 3 FP4
El procesador que no soporta la ejecución fuera de orden, no tiene más remedio que encargarse de las 5 operaciones de enteros, antes de poder atender las de coma flotante. Por ello, en el primer ciclo, hace las operaciones enteras INT1, INT2, INT3. De las INT4 e INT5 no puede encargarse aún, pues todas sus unidades de enteros están ocupadas. En el siguiente ciclo, ya podrá hacerse cargo de las restantes, y llegar a las operaciones en coma flotante, aunque de nuevo, solo podrá despachar 3 de una tacada. Para el tercer ciclo quedaría la última instrucción. Se han desperdiciado 9 ciclos de unidades de ejecución (en rojo). En cambio, el que sí soporta la ejecución fuera de orden, puede empezar a ejecutar las operaciones en coma flotante aunque no haya acabado, o incluso empezado, todas las anteriores. En el primer ciclo puede enviar 3 operaciones de cada tipo, hasta llenar todas sus unidades. Aunque las instrucciones FP1, FP2 y FP3 realmente van detrás de las INT4 e INT5, aún no despachadas, esto no es problema en esta CPU. En el siguiente ciclo acaba todo el trabajo. El aprovechamientos de los recursos es, en este ejemplo, masivamente superior.
Este ejemplo es puramente teórico, pues he supuesto que todas las instrucciones estaban ya decodificadas y listas para ejecutarse por obra del Espíritu Santo. Realmente una CPU tiene una cierta capacidad para decodificarlas, lo cual depende de la CPU y también normalmente de la sequencia partícular de instrucciones. Por ejemplo, un Athlon puede, en el mejor de los casos, decodificar 3 instrucciones por ciclo. Un Core 2 Duo podría, en teoría, llegar a las 4 instrucciones por ciclo. Para acabar de ilustrar esto, volvamos al ejemplo anterior, pero vamos a suponer que las CPUs pueden decodificar 3 instrucciones cada ciclo. Y supongámos que las operaciones FP1 y FP3 son más complejas y tardan 2 ciclos en ser completadas. Así es más realista.
Ciclo 1 INT1 INT2 INT3 INT1 FP1 FP3 Ciclo2 INT4 INT5 FP1 INT4 INT2 INT3 FP1 FP3 Ciclo 3 FP1 FP2 FP3 INT5 FP2 FP4 Ciclo 4 FP4 FP3 .
La primera CPU no puede hacer otra cosa que ir ocupando las unidades de ejecución conforme le van llegando las instrucciones. Cada ciclo puede iniciar la ejecución de 3 instrucciones como mucho, porque no es capaz de decodificarlas más rápidamente. Desperdicia 13 ciclos en esta ocasión. La segunda CPU, mucho más inteligente, es capaz de planificar la ejecución, de forma que acaba un ciclo antes, desperdiciando únicamente 7 ciclos, e incluso demostrándo que, al ejecutar fuera de orden, puede acabar su trabajo antes, realizando más operaciones por segundo, y sin llegar a usar en ningún momento la tercera unidad de ejecución en coma flotante. Es decir, anque sólo tuviera 2 unidades FP, lo cúal abarataría el coste, podría seguir siendo más rápida que su rival.
Y ya está de momento. Enhorabuena, lo has aguantado
Pronto entenderás para qué tanta leche. Es hora pasar a lo que nos interesa.
EL RENDIMIENTO DE LA XBOX 360 Y LA PLAYSTATION 3
INTRODUCCIÓN.
UN “LIGERO” CAMBIO DE FILOSOFÍA.
La CPU de la Xbox 360, el Xenon, es un chip de 3 cores, integrados en un sólo die, con tecnología de 90nm, y que funciona a 3,2GHz. Una velocidad bastante elevada, teniendo en cuenta que el Xenon tiene más de un año, y que hasta hace muy poco, la CPU de PC más potente, el Core 2 Duo, ” sólo” tenía 2 cores, y oscilaba entre los 2GHz y los 3 GHz.
Pero el “truco” es el siguiente. Mientras el Core 2 Duo, o el Athlon, fruto de una trabajada evolución, tienen unas capacidades de ejecución fuera de orden fabulosas, el Xenon no es capaz de ejecutar instrucciones fuera de orden. Ups, interesante diferencia. Eso quiere decir que un Athlon 64 X2 de 2 cores, a 2,6GHz, podría rendir más que el Xenon, más rápido y con más cores. Por cierto, a partir de ahora, en lugar de “ejecución fuera de orden”, usaré la abreviación OOE (Out of Order Execution), que me rayo.
Durante muchos años, todas las nuevas CPUs han sido diseñadas con un sólo core, cada vez más potente, con más y mejores unidades de ejecución, y con una OOE cada vez más eficiente, para aprovechar cada vez más el hardware. Cuando la industría empezó a pensar en fabricar CPUs de doble core, de repente, se propuso un cambio radical para la Xbox 360, una CPU no de 2 cores, sino de 3, pero a los que se les despojarían de la compleja circuitería que permite la OOE. Es decir, que se le ha quitado la “inteligencia” para planificar la ejecución del código. Al prescindir de esta circuitería, no sólo se abarata el coste, sino que se ahorra espacio, que ahora se puede aprovechar para integrar más cores, más caché, etc. Una filosofía de diseño totalmente distinta.
Vale, pero esto ¿por qué y para qué?
En primer lugar, una de las desventajas de la no OOE, es que el aprovechamiento de las unidades de ejecución y los recursos de la CPU, cae. Pero lógicamente no puede ser todo malo, pues de lo contrario el Xenon no tendría razón de ser. Y la tiene, porque en la práctica puede llegar a rendir fabulosamente. Los planteamiento son los siguientes. Esta arquitectura está pensada para que los programas que se ejecuten en ella, puedan explotar lo que se llama la TLP, o paralelismo a nivel de threads. Lo que quiere decir, es que el programa sea fácilmente dividible en distitnos hilos de ejecución (o threads) que se ejecuten en paralelo. Ahora voy a aclarar esto, y verás que no es nada complicado. Te dejo que eches un trago de agua, jeje. Al ataque.
Los programas “normales” se ejecutan instrucción a instrucción. Cuando un programa es capaz de ejecutarse en varios threads, eso significa que el código se divide en varios trozos, que se pueden ejecutar en paralelo (al mismo tiempo). Si la CPU es de un sólo core, y no es capaz de ejecutar más de un hilo a la vez, lo que hará será ejecuta los hilos alternativamente, una instrución de uno, luego otra de otro, y así, sin ninguna mejora aparente. Pero cuando una CPU dispone de más de un core, o es capaz de ejecutar más de un hilo a la vez, podrá procesar instrucciones de los distintos hilos simultáneamente, y por tanto, habrá una importante mejora. Con la imagen de abajo se verá más claro - o se verá, a secas
Los cuadrados rojos son instrucciones que van llegando a las CPUs.
Las cajas azules son CPUs capaces de ejecutar un sólo thread.
La caja verde es una CPUs, capaz de ejecutar 2 threads, o hilos de ejecución.La CPU de la izquierda, ejecuta un programa de un sólo thread. Las instrucciones pasan una a una.
La CPU del centro ejecuta un programa de dos threads. Como no es capaz de procesar más de un hilo, ejecuta una instrucción de cada thread en cada momento. No hay mejora.
La CPU de la derecha ejecuta un programa de dos threads. Como está si es capaz de procesar 2 threads, puede ejecutarlos a la vez, procesando las intrucciones de 2 en 2. Magia
Cada uno de los 3 cores del Xeon puede manejar 2 threads, por lo que la Xbox 360 puede ejecutar 6 threads en paralelo. Si conseguimos que nuestro software pueda balancear su carga en 6 threads, entonces vamos a obtener una jugosa ventaja frente a otras arquitecturas. Por tanto, un objetivo muy deseable es que el software se apoye en el multithreading (varios threads). En cambio, una aplicación típica y sencilla, que se apoya en la ejecución de un sólo thread, no podría aprovechar más que una pequeña parte del potencial del Xenon, y por tanto, tendrá penalizaciones enormes. Poco a poco, se empieza a extender en el mundo del PC el multithreading, para aprovechar al máximo los nuevos procesadores de dos cores, pero historicamente, la inmensa mayoría de software ha sido de un sólo thread. Esto ha sido debido en gran parte a que casi todos los PCs tenían un sólo procesador monothreading, y también porque el desarrollo de software multithread es más costoso y complejo (hay que estudiar cómo dividir el código, sincronizarlo, etc.). No obstante, en la Xbox 360, si queremos exprimir su potencia, el camino del multithreading es vital.
Las cajas verdes son CPUs, capaces de ejecutar 2 threads, o hilos de ejecución.
Imagina que son los 3 cores del Xenon.El core 1, ejecuta un programa de un sólo thread. Las instrucciones pasan una a una.
El core 2 ejecuta un programa de dos threads. Es capaz de procesar una instrucción de cada thread a la vez, permitiendo el paso de instrucciones de dos en dos.
El core 3 ejecuta un programa de tres threads. La CPU sólo puede ejecutar 2 threads a la vez, así que va alternando la ejecución de dos de los hilos. No hay mejora respecto al core 2. Pero mola.
Básicamente, lo que esto significa, es que los programadores van a tener que currar más. Van a tener que elaborar bien el software, dejarse de chapuzas, y garantizar que se pueda ejecutar en varios threads. Como el Xenon no tiene capacidad de OOE, los programas deben estar optimizados, para compensar la pérdida de “inteligencia” por parte de la CPU, y darle algo de trabajo ya hecho, para así minimizar las penalizaciones que ello conlleva. En resumen, el Xenon, se apoya en que la tarea se pueda repartir uniformemente a los 3 núcleos, y no sufra mucho al ser ejecutada en orden.
LA PLAYSTATION 3 SIGUE EL MISMO CAMINO
Si señores, el todopoderoso Cell también es un chip muy malvado. La CPU de la Playstation 3 también ha sido diseñada sin la OOE en mente. Y no ha sido por olvido. Al igual que el Xenon, no es capaz de ejecutar fuera de orden. Pero el caso de la Playstation 3 es aún más complejo. Se dice que su procesador es de 8 cores. Y como funciona también a 3,2 GHz, el plantel es verdaderamente impresionante. Y cabría esperar que fuera un maquinón, muy superior al Xenon. Ahora bien, eso de 8 cores hay que matizarlo bastante. Muy simplificado, el Cell es un chip con un sólo core principal (UNO), muy parecido a los del Xenon, y siete pequeños cores. Y es este core principal el que, por decirlo así,es un procesador completo, y controla al resto, que.tienen capacidades reducidas.
Así que no podemos comparar el Xenon y el Cell por el número de cores, así sin más, por la cuenta de la vieja. En resumen, se espera que la Xbox 360, con 3 cores principales, sea más eficiente en aplicaciones genéricas de muchos threads, que la Playstation 3, con un sólo core principal. Aunque a la hora de hacer gran cantidad de operaciones de cálculo, los 7 cores secundarios del Cell pueden marcar una clara ventaja (ya se sabe, 7 enanitos pueden hacer muchas cosas).
Las propuestas son por lo tanto:
| Cell | Xeon | Core 2 Duo | |
| Cores principales | 1 | 3 | 2 |
| Cores secundarios | 7 | 0 | 0 |
| Ejecución fuera de orden | No | No | Sí |
Muy bien, ya estás preparado (aunque cabe una ligera posibilidad de que sea “preparada”) para seguir digiriendo el artículo. Realmente lo peor ya pasó (es lo que siempre se dice, ya lo sé). Ahora pasamos a hablar de las consolas en sí, y a respirar un poco de la teoría.
VISIÓN GENERAL DE LA XBOX 360
Esquema general. Ancho de banda.
Los nombres pueden confundir un poco. El Xenos es la GPU y el Xenon la CPU. Como podemos ver, la Xbox 360 usa el chip de la GPU como Northbridge (igual que la Gamecube y la Xbox), es decir, como centro de comunicaciones de los buses rápidos del sistema. Por tanto, la CPU debe acceder a la memoria a través del Xenos.La comunicación CPU-GPU tiene, por primera vez en una consola (que yo conozca), 2 canales independientes. Se dispone de 2 buses de 64 bits, uno para enviar en cada dirección. Cada uno de estos buses puede mover 10,8Gb/s (esto es unas 10 veces más que la comunicación en ambos sentidos en la primera Xbox). Si se envía y se recibe de forma balanceada, se pueden alcanzar port anto los 21,6Gb/s entre la CPU y la GPU.
El ancho de banda de la memoria RAM, de tipo GDDR3, es de 22,4Gb/s.
700MHz * 2 * 128 / 8 = 22400 MB/s
El * 2 viene de que la memoria es GDDR3, y dobla su frecuencia de funcionamiento interna (700MHz) a la hora de transferir datos. El * 128 porque el bus es de 128 bits, y el / 8 porque para pasar de bits a bytes hay que dividir por 8 (1 byte es un conjunto de 8 bits).
El ancho de banda de la memoria es pues tres veces y media superior a la primera Xbox, permitiendo a la GPU acceder a texturas y demás datos a una velocidad bastante elevada. Todo esto es bueno, por si no ha quedado claro
El southbridge es donde están conectados los diversos buses lentos del sistema, que a través de 2 canales se comunica con el northbridge. Estos 2 canales son en realidad 2 buses PCI-Express. De nuevo, un canal sirve para enviar en una dirección, y el otro, para enviar en la otra, y cada uno permite un caudal de 500Mb/s. Aunque pueda parecer que 500Mb/s es poca velocidad si se compara con la de la memoria RAM, hay que recordar que la memoria RAM necesita ser muy rápida, mientras que la comunicación entre el southbridge y el northbridge no tiene requisitos elevados. Al southbridge van conectados dispositivos relativamente lentos. La información del pad, o de las tarjetas de memoria, no requiere gran velocidad, porque mueven poca información. El mayor requisito de este canal puede ser la comunicación con el DVD y el disco duro. Y en concreto, el canal que envía datos del southbridge al northbridge, para mandar todo lo que se lea del DVD a la CPU. Hay que tener en cuenta, que en la consola, casi todos los accesos serán de lectura (del DVD sólo es posible leer), y por tanto este canal tendrá una carga mayor. Aunque 500Mb/s debería ser más que suficiente (dudo que lector sea capaz de leer más de 10Mb/s, así que es imposible que llegue a saturar el bus).
| Xbox 360 | Playstation 2 | Xbox | |
| Ancho de banda CPU-RAM | 10,8 Gb/s (2x) | 1,3 Gb/s | 1 Gb/s |
| Ancho de banda GPU-RAM | 22,4 Gb/s | 3,6 Gb/s | 6,4 Gb/s |
| Ancho de banda CPU-GPU | 10,8 Gb/s (2x) | 1,3 Gb/s | 1 Gb/s |
.
GPU. El Xenos. La arquitectura unificada hace aparición.
Como ya expliqué, una GPU se encarga de las tareas gráficas de transformación y renderizado, esto es, cálculos de la geometría, iluminación, texturizado, efectos, y generación de la imagen. Para ello, existen diversos componentes en su interior. Primeramente la CPU cálcula una lista con los vertices de todos los polígonos de la escena, que envía a la GPU. Ya en la GPU, por una parte, los vertex shaders se encargan de los cálculos matemáticos, que permiten determinar la posición y orientación de los polígonos en el plano bidimensional de la imagen. Además, permite aplicar efectos a los vertices. Entonces, cada polígono es rasterizado, es decir, convertido a una serie de pixels que lo compondrán. El resultado de esta étapa pasa a los pixel shaders, que realizan operaciones sobre los pixeles, calculan su color, profundidad, texturizan, aplican efectos, etc. Los pixeles procesados son almacenados en la memoria de video, listos para ser ensamblados en la imagen final, que pueda ser mostrada en pantalla. De esta tarea se encargan los ROP, que además llevan a cabo algunas optimizaciones. Así pues, el proceso gráfico pasa por lo vertex shaders, pixel shaders, y ROPs. Si ves las especificaciones técnicas de una tarjeta de video, verás que cada una tiene un cierto número de cada uno de estos componentes (venga, ve a comprobarlo!). Cuantos más tengan, más mano de obra, y mayor rendimiento.
En la Xbox 360, el Xenos propone algo un tanto distinto; una arquitectura unificada, donde los vertex shader y los pixel shaders se funden. El Xenos es la primera GPU en emplear este sistema, y dispone de 48 shaders, que se pueden encargar tanto de procesado de vértices, como de píxels. Cada shader sólo puede ocuparse de una de las 2 tareas, pero en un momento posterior, puede cambiar para ocuparse de la otra. Esto otorga más flexibilidad, porque si en un momento dado, se requiere mucho pixel shading, se pueden dedicar los 48 shaders a ello, y si más tarde esta demanda decae, se puede rebalancear la carga, dedicando más shaders al procesado de vértices. Guay ¿no?
Bueno, unas pocas especificaciones… el Xenos dispone de 48 shaders, y funciona a 500MHz. Cada shader es capaz de realizar 10 operaciones en coma flotante por ciclo de reloj, lo que le confiere la capacidad de hacer 240 GFLOPS. Recordar que la Playstation 2 era un maquinón en esto de la coma flotante, con 6,2 GFLOPS, y ninguna de las consolas de la generación PS2-Xbox.-GC supera por mucho esta cifra. Pues bien, la Xbox 360 es capaz de realizar 240,000,000,000 operaciones decimales por segundo, y únicamente con su GPU. Luego habría que añadir otras contribuciones, como la de la CPU.
Como la GPU dispone de 8 ROPs, cada uno de los cuales puede generar un pixel, para ser mostrado por pantalla, resulta que su fill-rate es de 4000 Mpíxels/s.
500MHz * 8 = 4000 Mpíxels/s.
Para quien se haya perdido, esto significa que es capaz de dibujar 4,000,000,000 de pixels por segundo en pantalla, como máximo. Eso sí, recuerda que estos píxels han debido se ser previamente procesados por los pixel shaders. Los ROPs sólo se encargan de renderizarlos, es decir, generar la imagen final a partir de los píxels ya cálculados.
Además, el Xenos tiene una sorpresita muy agradable, pues en el mismo encapsulado, hay otro chip (en la imagen de arriba, el die pequeño a la izquierda), que además de 10Mb de memoria integrada, dispone de una interesante circuitería que acelera ciertos procesos. Recuerdo que la Playstation 2 disponía de 4Mb de memoria integrada en el chip gráfico (la Gamecube 3Mb), para acelerar el acceso a las texturas y buffers de vídeo. La Xbox 360 dispone de más del doble de esta cifra. Aunque por desgracia, cuando usa resoluciones de pantalla de alta definición (720p o 1080i), la memoria integrada de 10Mb no es suficientemente grande para alojar el buffer de la pantalla. Un sencillo cálculo os demostrará porqué. Tomad aire. Tomemos el modo 720p, cuya resolución es 1280×720. Si multiplicamos el número de píxels horizontales por los verticales, obtenemos el número total de píxels de una imagen a esa resolución, que resultan ser 921,600. Casi un millón. En el buffer, hay que guardar el color, y su atributo Z (su profundidad). Podemos suponer que se usan números de 32 bits para cada uno de estos atributos, requiriendo pues 64 bits para representar un píxel (8 bytes por píxel).
8 * 921600 = 7200 Kb = 7Mb
Como la memoria integrada es de 10Mb, vemos que sí cabría en el buffer. Pero, el Xenos está diseñado de forma que se puede usar antialiasing (suavizado de bordes) de 2X y 4X. Lo que quiere decir que se toman 2 u 4 muestras por cada píxel, para usar una media entre las muestras, y evitar así los típicos dientes de sierra que aparecen a veces en los bordes de los polígonos. Es genial, pues el antialiasing es un proceso costoso, que consume muchos recursos, y la Xbox 360 puede hacerlo sin penalización alguna, cosa de la que se encargan los ROPs. Pero al necesitar 2 u 4 muestras por píxel, hay que almacenar el doble o el cuadruple de datos en el buffer, mientras se procesa el antialiasing. Ahora multiplica los 7Mb que ocupaba una imagen en alta definición (720p) por 2 o por 4, y verás que ya no cabe en los 10Mb de memoria integrada. Por tanto, el Xenos cebe recurir a lo que se llama Tile Rendering, en el que debe renderizar la imagen por partes, cada una de las cuales debe caber en 10Mb. Para el modo 720p, se requieren 2 pasadas usando antialiasing X2, y 3 pasadas usando antialiasing X4. Lógicamente, abusar de estas cosas va a reducir el rendimiento.
Ya podéis respirar, jejej.
Para terminar, los 512 Mb de memoria RAM de la Xbox 360 son compartidos por la CPU y la GPU, así que en teoría, se podría llegar a usar 412Mb de RAM como memoria de vídeo, para texturas y demás, siempre y cuando se pudiera trabajar con unos 100Mb de memoria para datos y programa, algo que podría ser factible. Una desventaja de este sistema, es que como la CPU tiene que acceder a la memoria a través del Xenos, los datos tienen que viajar por el bus que cominuca la CPU con el Xenos, reduciendo el ancho de banda restante entre ambos procesadores. Cuando hablemos de la Playstation 3, que usa otra arquitectura, entenderás lo que quiero decir.
Daré más detalles sobre el Xenos cuando hable del RSX.
| Xbox 360 | Xbox | |
| MHz | 500 MHz | 233 MHz |
| Vertex Shaders | - | 2 |
| Píxel Shaders | - | 4 |
| Shaders (unificados) | 48 | - |
| TMU (Unidades de texturas) | 32 | 8 |
| ROPs | 8 | 4 |
| Píxel Fill-rate | 4,000 Mpíxels | 932 Mpíxels |
| Ancho de banda de memoria | 22,4 Gb/s | 6,4 Gb/s |
Memoria.
Como ya he dicho, posee 512Mb de capacidad. Y al igual que su predecesorda, la Xbox 360 usa su memoria de manera unificada, es decir, para todo, ya sea gráficos, datos, código, etc.. o en otras palabras, hace a su vez de memoria principal y memoria de vídeo.
La memoria empleada por la Xbox 360 es una evolución de la DDR usada por la primera Xbox. La versión posterior a la DDR se denomina DDR2, de la cual derivó la GDDR3, optimizada para aplicaciones gráficas. Así que cuidado con el 3 de GDDR3, porque no es de una generación posterior, sino de la misma que la DDR2.
La memoria de la Xbox 360 funciona a 700MHz, que efectivamente se transforma en 1400MHz para la transferencia de datos. La de la Xbox funciona a 400MHz efectivos. Por tanto, como ya indiqué, se aprecia un aumento muy notorio de velocidad.
VISIÓN GENERAL DE LA PLAYSTATION 3
Esquema general. Ancho de banda.
Como podemos ver, es ahora la CPU la que hace de northbridge (como sucedía con la PS2). Así pues, la CPU de la Playstation 3 puede acceder directamente a su memoria principal, sin necesidad de pasar por la GPU, como sucedía en la Xbox 360. Además, el RSX puede acceder directamente a su memoria de vídeo. La desventaja de este esquema es que cuando el RSX accede a la memoria principal, o la CPU a la memoria de video, aparece una penalización, que en este caso es especialmente preocupante cuando el Cell intenta leer de la memoria de vídeo, pues es casi incapaz de hacerlo. Además, el tener 2 tipos de memoria, hace que cuando se deseé transferir datos de una a otra se consuma ancho de banda, mientras que en el caso de la Xbox 360, con memoria unificada, no hay tal problema.
La cominicación entre la Cell y el RSX tiene también 2 canales, uno para cada dirección, pero no son simétricos, ya que el canal RSX->Cell dispone de un unos jugosos 5Gb/s extra.
Los anchos de banda de las memorias son muy similares a los de la Xbox 360. Es más, el de la memoria de vídeo es exactamente el mismo, pues es del mismo tipo. La memoria principal es un poco más rápida.
La comunicación northbridge-southbridge usa también 2 canales, uno por cada dirección, pero son más rápidos que los de la Xbox 360 (realmente, 5 veces más, anque no sé para qué podría requerirse tanta velocidad aquí, y no creo que la ponga en desventaja. ¿Será para el Blu-Ray? jajaja).
| Playstation 3 | Xbox 360 | Playstation 2 | Xbox | |
| Ancho de banda CPU-RAM | 25,6 Gb/s | 10,8 Gb/s (2x) * | 1,3 Gb/s | 1 Gb/s |
| Ancho de banda GPU-RAM | 15+20 Gb/s ** | 22,4 Gb/s | 3,6 Gb/s | 6,4 Gb/s |
| Ancho de banda CPU-GPU | 15+20 Gb/s | 10,8 Gb/s (2x) | 1,3 Gb/s | 1 Gb/s |
* Es el ancho de banda del bus CPU-GPU, por donde los datos deben de pasar. No puede sobreparse en total los 22,4Gb/s, que es la máxima tasa de transferencia de la memoria en sí.
** Es el ancho de banda del bus CPU-GPU, por donde los datos deben de pasar. No puede sobreparse en total los 25,6Gb/s, que es la máxima tasa de transferencia de la memoria en sí.
GPU. El RSX. Una arqitectura clásica.
La Playstation 3 tiene una GPU de bastante potencia, fabricada por NVIDIA en tecnología de 90nm, y equiparable en muchos aspectos a una Geforce 7800 GTX (una tarjeta gráfica de equiparable potencia saldría por algo más de 200 euros, a fecha del lanzamiento de la consola). Al contrario que el Xenos de la Xbox 360, el RSX no es una arquitectura unificada, y por tanto dispone de vertex y pixel shaders. En concreto, tiene 8 unidades de vertex shaders, y 24 de píxel shaders, así como 8 ROPs.
El RSX (izquierda) junto al Cell (derecha) finalmente ensamblados en una Playstation 3.
Si lo comparamos al Xenos, veremos que dicha comparación no es sencilla. Como, ambas GPUs funcionan a 500MHz, tenemos que analizar la arquitectura para ver cual aprovecha más cada megahercio. El RSX dispone de 32 shaders en total, y el Xenos de 48, que además pueden dedicarse a procesar vértices o píxeles a conveniencia. Pero no todos los shaders son iguales. Cada shader puede trabajar sobre un vértice o un píxel, pero algunos shaders pueden hacer más operaciones que otros. Y aunque, por tanto, sólo esté trabajando sobre un vértice, podría aplicar más o menos efectos a la vez, requiriendo más o menos ciclos en concluir la tarea.
Cada uno de los 48 shaders del Xenos es capaz de realizar 10 operaciones en coma flotante por ciclo de reloj, porque dispone de una unidad vectorial que opera con vectores de 4 componentes, y una unidad escalar, que opera sobre números de un sólo componente. Por tanto, puede hacer 5 operaciones por ciclo, ¿no? Si, pero es capaz de hacer una operación compuesta llamada MAD, una multiplicación y suma, que son en realidad 2 operaciones, luego 10 en total.
Los vertex shaders del RSX son igualmente capaces de hacer 10 operaciones en coma flotante por ciclo. Pero los píxel shaders son más robustos, pues permiten hacer 20 operaciones, al disponer de 2 unidades vectoriales y 2 escalares.
Vale, ahora sumemos. El Xenos es capaz de hacer 240 GFLOPS (500MHz * 48 shaders * 10 FLOPS). En el RSX tenemos que contabilizar las operaciones por separado, pues los vertex shaders no son iguales a los píxel shaders. Por una lado, los vertex shaders son capaces de hacer 40GFLOPS (500MHz * 8 shaders * 10 FLOPS). Y por otro lado, los píxel shaders alcanzan los 240GFLOPS (500MHz * 24 shaders * 20 FLOPS), y en total, 280GFLOPS.
Luego aunque el RSX disponga de menos shaders, es capaz de hacer más operaciones en tareas de shading. He de decir, que he simplificado los cálculos, pues en realidad los píxel shaders del RSX no hacen 20 operaciones sino 27, contando con operaciones de normalización (no viene a cuento), y el Xenos dispone de otros mecanismos más complejos para agilizar ciertos procesos, etc. Por tanto, he hecho una comparación simplificada en cuanto a rendimientos de cálculo de los shaders únicamente, pues de otra manera se complica mucho. El resto es mejor comentarlo a parte, o se vuelve muy farragoso.
¿Quiere esto decir que el RSX es más potente? Puede que sí, y puede que no. Pero en mi opinión, dependerá de la aplicación en concreto, y el aprovechamiento que se haga. Por ejemplo, mientras el Xenos tiene 10Mb de memoria integrada, el RSX no dispone de ella, y debe guardar todos los buffers y texturas en la memoria de vídeo, que es más lenta. A modo de comparación, la memoria integrada del Xenos es capaz de mover 256Gb/s, mientras que la memoria de vídeo de ambas consolas, 22,4Gb/s, que es bastante, pero del orden de 10 veces más lenta. Además, el Xenos no sólo tiene esos 10Mb de memoria, sino que en realidad es una GPU con 2 dies, uno que constituye la GPU en sí, y otro que alberga la memoria integrada y una circuitería que hace cosas interesantes. Además, el Xenos tiene la libertad de poder balancear el número de shaders que dedica a vértices y a píxeles, mientras que el RSX no puede dedicar más que 8 a vértices, y 24 a píxeles. Aunque lo compensa, al tener unos píxels shaders más robustos (normalmente las aplicaciones 3D actuales requieren mucho más trabajo sobre píxels que sobre vértices). Por otro lado, el RSX no dispone más que 256Mb de memoria de vídeo, mientras que el Xenos podría llegar a disponer de más cantidad de memoria, al tener la Xbox 360 512Mb de memoria unificada.
Así pues, llegado a este punto, muchos expertos se tiran debatiendo indefinidamente, y yo prefiero decir que ambas GPUs son una maravilla de la ingeniería, y que cualquier debería estar suficientemente contento con cualquier de ellas. Aunque cierto es que algunas críticas contra el RSX están fundadas, teniendo en cuenta que para cuando se ha lanzado la Playstation 3, ya había tarjetas gráficas en el mercado más potentes que el RSX. En cambio, aún no había tarjetas de arquitectura unificada, como el Xenos, cuando la Xbox 360 salió al mercado, hace ya casi un año.
El futuro es para la arquitectura unificada, pues las tarjetas gráficas van a empezar a adoptar ese sistema, y el nuevo DirectX 10 dará soporte a esta arquitectura. Por si fuera poco, Microsoft presionará para que ésta se imponga, pues domina el mercado del PC, y sus sistemas operativos Windows seguirán, de momento, marcando tendencias. ATI llevaba ventaja a NVIDIA, pues ya había diseñado una GPU unificada, el Xenos. NVIDIA acaba de lanzar su primera tarjeta de arquitectura unificada, la Geforce 8800, que es de momento la más potente del mundo (que vale, por cierto, unos 600 euros), a espera de la nueva ATI.
| Xbox 360 | Plastation 3 | Xbox | |
| MHz | 500 MHz | 500 MHz | 233 MHz |
| Vertex Shaders | - | 8 | 2 |
| Píxel Shaders | - | 24 | 4 |
| Shaders (unificados) | 48 | - | - |
| TMU (Unidades de texturas) | 32 | 24 | 8 |
| ROPs | 8 | 8 | 4 |
| Memoria de vídeo | 512 Mb (compartida) | 256 Mb | 64 Mb (compartida) |
| Ancho de banda de memoria | 22,4 Gb/s | 22,4 Gb/s | 6,4 Gb/s |
| Píxel Fill-rate | 4,000 Mpíxels | 4,000 MPíxels | 932 Mpíxels |
Memoria.
Dispone de 512Mb, como la Xbox 360, pero no unificada, y repartida en 256Mb de memoria principal, y 256Mb de memoria de vídeo.
La memoria gráfica es del mismo tipo que la memoria unificada de la Xbox 360, GDDR3 a 700MHz, así que no diré nada más. En cambio, la memoria principal es de un tipo distinto, basada en RAMBUS, un tipo de memoria, ya usada en la Playstation 2, y que llegó a emplearse en los PC, pero no ciajó (memoria RIMM, usada por las primeras placas de Pentium 4, carísima). La Playstation 3 usa una evolución de esta tecnología RAMBUS, llamada memoria XDR. Funciona a la impresionante velocidad de 3,200MHz, pero cuidadín. Su anchura de bus es de sólo 64 bits. Por lo tanto es poco más rápida que la memoria a 1400MHz de la Xbox 360, cuyo bus es de 128 bits.
LAS CPUs
Hasta el momento no he hablado en detalle de las CPUs. No quiero recargar demasiado el artículo, porque como ha sido flojillo y tal 
Así que me he reservado algo sencillo para el final.
Como dije, el Xenon es una CPU de tres cores idénticos, cada uno de los cuales puede ejecutar 2 threads simultáneamente, y disponen de una unidad de ejecución VMX (se encarga del cálculo vectorial), que le otorga casi todo su rendimiento en coma flotante. Los 3 cores tienen a su disposición una memoria caché compartida de 1Mb. No demasiada, si se tiene en cuenta que las CPUs de doble core de PC oscilan entre 1Mb y 4Mb.
El Cell es una CPU con un sólo core, similar al del Xenon, y 7 procesadores de apoyo, con capacidades reducidas, llamados SPE. El core principal puede manejar 2 threads, al igual que en el caso del Xenon, pero el Xenon puede ejecutar 6 threads en total, al disponer de 3 cores. En aplicaciones generales, debería ser más potente el Xenon. Pero en el campo de las operaciones en coma flotante, el panorama cambia, pues el Cell dispone de más unidades de ejecución, al tener un mayor número de cores. Pues, en aplicaciones muy dependientes de cálculo, el Cell debería rendir más. Otra posible desventaja del Cell es su pequeña memoria caché, de sólo 512Kb a compartir entre los 8 procesadores. Pasarán hambre. A lo mejor hasta se matan entre ellos. Aunque cada SPE tiene una pequeña memoria local, para él solo, en una CPU como esta, con tantos componentes, es importantísimo que la comunicación y la compartición de datos sea lo mejor posible, y la memoria caché es la única a la que pueden acceder todos de igual forma, core principal y SPEs. Pero tampoco me hagas mucho caso
Para acabar, os dejo la imagen del die del Xenon (izquierda) y del Cell (derecha). No están a escala, aviso. Si te fijas, se ven los SPE del Cell, y el Power Processor Element, o sea, el core principal. Sí, el Cell tiene 8 SPE y no 7, pero uno de ellos estará deshabilitado en la Plasystation 3.
Si tenéis que recordar una sola cosa sobre estas CPUs, sobretodo, es importante recordar lo que he explicado al principio sobre la OOE (ejecución fuera de orden) y el hecho de que ni el Cell ni el Xenon tienen esa capacidad. El resto son sólo números, para quien le interese.
CONCLUSIONES
Felicidades por haber llegado hasta aquí. Poco más
Sí, echáis de menos la Wii… Nintendo no ha soltado ni una palabra sobre las especificaciones de la consola (no me extraña). Y ahora que ya ha salido a la venta, tampoco lo han hecho ni creo que lo hagan. Así que es algo parecido a imposible el haberla incluído en este artículo. Aunque poco a poco voy averiguando más cosas sobre su hardware, y tal vez lo trate en un futuro. Es un sistema mucho menos potente que sus competidores, y no tiene mucho que ver con ellos. Se parece más, como todos ya sabréis, a la arquitectura de la Gamecube. Lejos de los 512 Mb de memoria de la Xbox 360 o la Playsation 3, lleva 64 Mb, y su CPU es una simple evolución del Gekko (la de la Gamecube), que con casi toda certeza ejecuta fuera de orden, es decir, que sigue la filosofía clásica, como ha sido hasta la anterior generación.
Este artículo lo he escrito únicamente porque quedaba bien, al seguir el hilo de los otros (hilo en el sentido habitual, olvida los threads ya, jaja). Además, por ser de cierta actualidad, pensé que sería interesante. Y sobretodo, para cultirizar un poco, porque aunque hay multitud de artículos por internet sobre estas cosas, es díficil encontrar algo digerible para una persona con conocimientos limitados. O bien tratan temas especificos, o bien son excesivamente técnicos, o largos, o son muchos y es´tan desperdigados, o bien están fatal explicados,… y el 90% está en inglés (por experiencia). Así que espero haber podido hacer un interesante compendio de lo que he aprendido éste último año sobre el tema (eso espero, porque me ha llevado muchas horas escribirlo).
En el próximo artículo las cosas ya no se complicarán más (no sé si podré resistirme). De momento, puede decirse que esté ha sido el último artículo del desarrollo “teórico” , por llamarlo así. Tengo pendiente 2 artículos más.
- Uno sobre la Dreamcast (porque me lo ha pedido bastante gente).
- Otro sobre la Super Nintendo y la Megadrive (porque le tengo ganas, y porque seguro que muchos se preguntan cosas sobre estás dos máquinitas de la época dorada de las 2D).
Después se acabó xD
Aunque es posible que escriba otra serie de artículos sobre otra cosa…
¡Un saludo a todo! y ya sabéis, intentad ejecutar vuestras vidas fuera de orden xD
1 comentario:
Dοnt looκ а xbox720 іn the eyes rofl :-)
Here is my web page - xboxkinect.se
Publicar un comentario