La carrera de los bits y los megahercios, séptima parte (II)

Volviendo la vista adelante: la Wii (y II)

Aquí tenéis la segunda parte de la séptima entrega, dedicada a la Wii, de «La carrera de los bits y los megahercios», que como ya dije, será la última, y la iré publicando en varias tandas. Como estamos acabando, y se supone que estos artículos son didácticos y tal, aviso que seguiré la línea del anterior, y donde lo dejé, analizando en cierto detalle la arquitectura de la consola de Nintendo, pero orientado a aquellos no muy entendidos, con algunos conocimientos ya adquiridos, que deseen acercarse más al hardware. Pero antes de seguir dando caña, iremos entrando poco a poco con algo más fácil de leer.

Comentarios generales y cotilleos

Durante mucho tiempo, antes de que Wii viera la luz, se debatieron en foros las posibles especificaciones de la revolucionaria, para algunos, máquina de Nintendo. Había para todos los gustos, aunque incluso los que apostaron por una mayor potencia hablaban de un hardware inferior a sus competidoras, al menos en cuanto a rendimiento. Pero, a pesar de que la idea de Wii, siendo una consola poco potente, pequeña y barata, ya era un hecho casi establecido, no eran pocos los que se aventuraban a sugerir cosas bastante suculentas, e incluso que tal vez se escondiera algún tipo de secreto en su interior que le fuera a permitir acercarse a la Xbox 360. Debo decir que, de todo lo que leí y de todo en lo que yo mismo pensé, la solución de Nintendo fue casi, si no del todo, la opción menos potente.

Nintendo ya empleó un derivado del micro de la NES en la Super NES. Y lo más importante, el PowerPC G3 era energéticamente eficiente, y muy barato de fabricar con la tecnología del momento.

Por un lado, las posibilidades de que se empleara una CPU similar a la de GameCube eran muy altas. Si no iba a haber un gran salto técnico entre ambas consolas, era muy sensato utilizar la misma arquitectura, o, al menos, una que permitiera retrocompatibilidad con el código ya escrito para la Cube. Ello permitiría aprovechar parte de los conocimientos adquiridos en el área de software y suavizar la curva de aprendizaje para los desarrolladores de la nueva plataforma. Sin ir más lejos, Nintendo ya empleó un derivado del micro de la NES en la Super NES. Y lo más importante, el PowerPC G3 era energéticamente eficiente, y muy barato de fabricar con la tecnología del momento. No tenía sentido, y no había motivo aparente, para pasar a otra familia de microporcesadores. A partir de este punto, en el que yo creo que la mayoría estábamos de acuerdo, había varios caminos. El primero pasaba por la opción más directa: una CPU de la misma generación que el Gekko de GameCube, reducida de tamaño para bajar costes y consumo, optimizada para funcionar a mayor frecuencia, y tal vez con algo más de memoria caché. Era en su momento una apuesta bastante pobre y poco atractiva. Otro camino era dar un salto generacional del G3 al G5, un chip mucho más moderno, con más caché y de 64 bits frente a un micro de 32 bits ya obsoleto en el terreno del alto rendimiento. Gracias al G5 se podría haber alcanzado una mayor velocidad, pasando cómodamente de 1GHz, o incluso 2GHz, y obteniendo un rendimiento mayor que el de un G3 a la misma frecuencia de reloj. Por si esto fuera poco, el G5 incorporaba la famosa unidad vectorial Altivec o VMX, que daba un empujón muy sustancial a la capacidad de calculo en coma flotante. El G5, no obstante, tenía el inconveniente de ser más complejo, grande y caro, así como el de presentar un consumo más elevado. Cuando apareció, rondaba los 40 ó 50W, que implica una cantidad de calor considerable, por encima del que cabría esperar de una CPU de portátil moderna de dos núcleos. Pero en el momento en el que Wii podía haberlo requerido, seguramente se podría haber conseguido una implementación que bajara de 20W, a una frecuencia cercana a los 2GHz. Lo cierto es que 20W está bastante bien, pero no debía de caber en los planes de Nintendo ya que Wii, —es decir, la consola entera—, parece no sobrepasar bajo ninguna circunstancia, incluso a plena carga, los 20W. En mi opinión, podría haberse utilizado un G5 a 1GHz o incluso algo menos, intentando bajar el voltaje lo más posible para minimizar el consumo, y rozar tal vez 11 ó 12W, que aún sería por lo menos el doble de lo que consume Broadway. Aunque tal vez a mí no me habría importado que la consola consumiera un poco más, digamos, unos 25 ó 30W, que la seguiría manteniendo dentro de la categoría del bajo consumo. Incluso aunque el supuesto G5 trabajara a sólo 729MHz, como hace el procesador de Wii, habríamos ganado algo en rendimiento global y algo más en el apartado de cálculo, pero no sería razonable invertir dinero y esfuerzo en investigar para dar un salto tan «corto», pues la mejora no habría sido salvaje. Una alternativa que parecía bastante obvia era optar por un PowerPC G4. Un escalón intermedio, pero que, por ejemplo, ya incorporaba una unidad vectorial Altivec. Aparentemente no habría sido nada descabellado. El G4 habría sido más barato que el G5 y seguiría representando un avance, aunque tal vez no se consiguiera un consumo inferior. Esto, que de por sí ya habría sido casi definitivo, no habría sido el único motivo para descartarlo como aspirante. El PowerPC G4 fue desarrollado por la alianza IBM, Motorola y Apple, al igual que lo había sido su predecesor, el ya muchas veces mencionado G3. En este caso, parece que fue realmente Motorola el principal impulsor. De hecho, cuando llegó el momento de pasar a fabricación, IBM decidió no hacerlo porque, por lo visto, tenían puntos de vista distintos en algunos aspectos del chip. Así pues, fue Motorola, hoy en día Freescale (algo así como su división de semiconductores), la que comercializó estos procesadores. Ahora bien: Nintendo ya tenía un acuerdo con IBM, —que suministró el procesador a la GameCube—, el G4 no había sido nunca fabricado por ellos, y es posible que no hubiera sido viable llevarlo a la vida sin la ayuda de Motorola, por lo que no compensaba para nada el esfuerzo para el beneficio marginal que habría supuesto un salto G3 -> G4 a una frecuencia de reloj inferior a los 800MHz. Ahí queda. La única verdadera lástima de no llevar como mínimo un G4 es el seguir sin disponer de una unidad de cálculo vectorial de 128 bits, como Dios manda. Porque apuntando a un consumo tan bajo hay poco margen de maniobra, y la elección del G3 es, desde el punto de vista ingenieril, bastante coherente, aunque discutible. Respecto a la GPU, no habría venido nada mal, considerando el gran avance tecnológico que han experimentado los chips gráficos en los últimos años, haber elegido algo un poco más… moderno. La arquitectura de Hollywood (qué asco de nombre le pusieron) está francamente anticuada, pero lo relevante, a mi juicio, es que no está lo suficientemente dotada de recursos (siempre y cuando la información técnica que tengamos sea correcta). En este caso, no creo que el hecho de ser anticuado sea en sí un problema, porque al fin y al cabo una arquitectura no es más que un modo de llevar a cabo algo, de conseguir un determinado comportamiento o resultado. Obviamente, las hay más eficientes y las hay menos, pero a menudo se puede compensar, al menos en parte, con un aumento de prestaciones. Claro que llega un momento en el que una arquitectura no puede dar mucho más de sí sin que deje de merecer la pena invertir en ella, o sin modificarla tanto que ya no se parezca en nada a lo que era, que suele ser el punto en el que se da un salto generacional, o en otras palabras, se le cambia el nombre (¡aunque a veces se le cambia el nombre sin necesidad de ello!).

Llega un momento en el que una arquitectura no puede dar mucho más de sí sin que deje de merecer la pena invertir en ella, o sin modificarla tanto que ya no se parezca en nada a lo que era

Por ejemplo, si tomáramos un procesador como el 486 de Intel, que dejó de ser considerado potente a mitad de los 90, y con la tecnología actual intentáramos competir con la CPU de Wii, lo tendríamos muy crudo. El 486, que supuso en su momento un gran avance, no incorpora caché L2, y su caché L1 es pequeña. No es superescalar, y por tanto no puede iniciar la ejecución de más de una instrucción simultáneamente. Aunque emplea pipeline, no soporta ejecución fuera de orden, y supongo que en el aspecto de la planificación de ejecución, como la predicción de los saltos en el código, estará muy limitado. Su unidad de cálculo en punto flotante tiene un rendimiento pírrico. Su bus de datos está limitado a 32 bits, y por si fuera poco, su relación consumo/prestaciones es reducido en comparación con un moderno procesador RISC. No podría competir con un G3 simplemente amplificando sus características, al menos no sin llegar a un resultado un tanto grotesco. Pero, volviendo al tema, para nada se puede considerar que la arquitectura de la GPU de Wii esté fuera de juego. Seguro que podría ofrecer un rendimiento muy superior si se dedicara más área de silicio para implementar recursos de hardware que permitieran trabajar en paralelo sobre un mayor número de vértices y píxeles. Se trataría, más que de aumentar la velocidad, de crecer a lo ancho, como solemos decir en este campo. Para quien no lo entienda, quedará más claro con la ayuda de la imagen inferior. A la izquierda vemos cuatro recursos hardware en forma de columnas verticales. Con un poco de imaginación, suponemos que cada uno de esos recursos puede trabajar sobre un dato, y que ello requiere cuatro etapas (divisiones verticales). No vamos a entrar en la arquitectura, es decir, en la forma en la que trabaja cada recurso internamente, sino únicamente en las posibilidades generales de mejora, que son básicamente tres. Izquierda: Se podría rediseñar el circuito de forma que se pudiera aumentar la velocidad a la que procesan los datos (aumentar MHz), reteniendo las cuatro etapas. Centro: Una forma habitual de conseguir lo anterior es aumentar el número de etapas, de forma que cada una de ellas haga un menor trabajo. De esta forma se puede aumentar la velocidad fácilmente y conseguir una suculenta mejora siempre y cuando se consiga que todas las etapas funcionen sin parones (algo que entraña bastantes problemas). Ésta es la llamada técnica de pipeline, que ya traté en artículos anteriores, e implica un crecimiento de la arquitectura en profundidad. Derecha: En contraposición, muestra un crecimiento de la arquitectura en anchura. Se mantienen los mismos tipos de recursos originales, sin ningún aumento o disminución, ni en MHz ni en etapas, pero con un mayor número de ellos. Ésta es una técnica de paralelismo, pues puede trabajar en un mayor número de datos en paralelo, es decir, simultáneamente. Se especuló mucho sobre la GPU que usaría Wii. Por una parte, era muy lógico suponer que se basaría en la misma arquitectura que el Flipper de GameCube, por simplicidad y retrocompatibilidad, pero no era nada extraño pensar que se cambiaría por completo a algo más estándar, similar a lo empleado en las tarjetas gráficas de ordenador, que seguían evolucionando a un ritmo frenético. En mi opinión, teniendo en cuenta el producto que querían conseguir, los de Nintendo tomaron una decisión correcta reteniendo la arquitectura, con la salvedad de que podría haberse mejorado bastante más que en un simple aumento del 50% en MHz, por ejemplo, y volviendo a lo de antes, creciendo a lo ancho (entraré en detalle más adelante). Respecto a la RAM, parece que es donde más gente ha tenido una opinión, sobre todo entre los más profanos. Ya se rumoreaba hace mucho que la capacidad de Wii en este apartado no iba a andar precisamente sobrada. Hubo un prolongado debate abierto. No era descabellado pensar en 128 o incluso 256Mb de RAM, cuando las especificaciones generales eran aún desconocidas. Incluso hasta el último momento, mi esperanza era que Nintendo hubiera decidido usar 128Mb adicionales reteniendo los 24Mb ya disponibles en GameCube; es decir, un total de 152Mb. Y supongo que muchos se llevaron una decepción al ver que ni siquiera llegaría a cuadriplicar la limitada memoria de la Cube. Como ya comenté, se han añadido 64Mb de memoria GDDR3, que junto a los 24Mb de tipo 1T-SRAM alojados en el mismo encapsulado que el Hollywood suman 88 Mbytes. Sin duda muy alejado de los 512Mb de sus contemporáneas, que además trabajan a velocidades muy superiores. En su momento hizo dudar, pero ahora, viendo la consola en su conjunto yo personalmente no la veo descompensada, pues la CPU y la GPU no van a permitir hacer cosas mucho mejores que las que podrían dejarse ver en su antecesora. Y más del triple de memoria debería ser suficiente. Ahora bien, suficiente no quiere decir cómodo. Hay que ingeniárselas, como siempre, para compactar la mayor cantidad de datos y texturas posible. La memoria de vídeo es algo que nunca sobra en una consola. De hecho, la NES estaba terriblemente limitada, y los cartuchos tenían que llevar siempre una memoria que o bien llevaba grabados los gráficos, o bien era RAM donde se iban almacenando durante el juego, porque no había capacidad en la propia consola para ello. Sus escasos 2 Kbytes guardaban la posición de los gráficos del nivel del juego, y únicamente había espacio para un área equivalente a dos pantallas de televisor, lo que permitía un scroll fluido en una de las dos direcciones (vertical u horizontal). En un nivel de avance lateral (ver imagen inferior), cuando el scroll llegaba al final de la segunda pantalla de memoria, la primera era reemplazada por el siguiente tramo del nivel, y aparecía, por decirlo así, a continuación de la segunda (como un bucle), dando la sensación de un avance continuo.

Supongo que muchos se llevaron una decepción al ver que ni siquiera llegaría a cuadriplicar la limitada memoria de la Cube.

Esto mismo se hacía en los niveles de scroll vertical, mapeando las pantallas una sobre la otra (a estos dos modos de funcionamiento se les llamaba mirroring vertical y mirroring horizontal). Si os fijáis, los primeros juegos de NES, como Kid Icarus y Super Mario Bros., sólo avanzan en una de las dos direcciones en cada momento, y más tarde, gracias a circuitería extra en los cartuchos, se permitió el scroll simultáneo, la posibilidad de mostrar un área de menú o inventario que permaneciera fija mientras el fondo hacía scroll, y otras tantas cosas, como se puede ver en juegos como Super Mario Bros. 3. La escasa memoria de vídeo de NES también guardaba las paletas, una para los fondos y otra para los sprites, de tan sólo doce colores cada una más el color «transparente», y atributos muy básicos sobre los sprites como son su posición y su aspecto actual. Las paletas sólo ocupaban 32 bytes y los sprites, cuatro bytes cada uno, con un máximo de 64 sprites de 8×8 pixels, o sea que salvo objetos muy pequeños se requerían varios sprites para construir un personaje o enemigo de tamaño más o menos razonable, reduciendo de forma brutal su número. Y en ningún momento se almacenaban gráficos en sí, sino que se usaban referencias a ellos, que residían en el cartucho, como ya comenté. La optimización del espacio ocupado en memoria era elevada. Los gráficos de muchos juegos ni siquiera llegaban a los 16Kb. Qué tiempos aquellos. En la SNES y la Mega Drive pasamos a tener 64Kb de VRAM, o memoria de vídeo. No parece demasiado, pero para ilustrar el salto, más que considerable, la 16 bits de Nintendo era capaz de almacenar cuatro planos con una colección de 256 tiles de 16 colores para cada uno de ellos, y otros tantos para los sprites, y todavía disponer de alrededor de un 25% de memoria libre. Igualmente, dos planos con tiles de 256 colores nos llevaban a un uso de memoria similar. Estas paletas de hasta 256 colores eran configuradas a partir de 32.768 posibles tonos. En cambio, la NES de 8 bits sólo podía manejar un único plano, y tiles de tres colores seleccionados de una paleta de doce, que era configurada a partir de tan solo 52 colores posibles, y la mitad de sprites, con menos colores y de menor tamaño. De la generación de los 16 bits saltamos, al pasar a consolas con soporte de juegos en CD —y por tanto un mayor requisito de memoria (debido a la mayor latencia y menor tasa de transferencia respecto a los cartuchos)—, al megabyte de VRAM de la PlayStation, los 8 Mbytes de Dreamcast, los 32 Mbytes compartidos de la PlayStation 2, los 64 Mbytes de Xbox, y los 512 Mbytes de la Xbox 360. Es decir, en poco más de veinte años hemos pasado de unos 2Kb de VRAM a una media de 256 Mbytes de uso exclusivo para vídeo, o unas 130.000 veces más. Un ritmo de crecimiento superior a seis veces por año. Pero esta comparación no es del todo válida.

La DS pasa de los 96Kb de la GBA a los 656Kb, sin contar en ambos casos las paletas ni los atributos de los sprites (posición, gráfico, paleta, etc.), y otros 248Kb para el motor 3D (polígonos y vértices)

En esta evolución se pasó de usar rápidas memorias de semiconductor en los cartuchos a discos ópticos, que debido a su sistema mecánico y su funcionamiento introducen latencias variables y requieren buffers y una mayor cantidad de memoria para asegurar un flujo constante de información. Las consolas portátiles actuales de 32 bits, como la Game Boy Advance y la Nintendo DS, que continúan empleando cartuchos, ilustran lo que acabo de decir. La GBA, con una calidad gráfica similar a la que ofrecía la SNES pero por medio de una arquitectura totalmente distinta, dispone de tan sólo 96Kb de VRAM, o en otras palabras, un 50% más que la SNES. En escenarios de varios planos y en un modo gráfico de tiles le saca ventaja a la Super Nintendo porque dispone de 16Kb más de VRAM, que se dedican a almacenar los gráficos de los sprites, y en el resto, 64 Kb, son alojados los planos y sus gráficos, mientras que la vieja 16 bits debía repartir sus 64Kb para sprites y planos. La portátil bipantalla, que se podría equiparar en muchos aspectos a una N64 portátil, pero de nuevo con una arquitectura completamente distinta, es muy similar a la GBA, ampliada con una CPU principal más potente (un ARM9 a 66MHz, manteniendo el anterior, el ARM7, a unos 33MHz aprox, alrededor del doble que en la GBA), más capacidades gráficas, pantalla inferior táctil y un doble motor 2D (aunque el segundo no tan potente como el primero, y por tanto la pantalla configurada como pantalla secundaria tiene algunas limitaciones, pero aun así bastante completo), un motor 3D, WiFi, micrófono, un nuevo sistema de cartuchos y más memoria, entre ellas más VRAM. La DS pasa de los 96Kb de la GBA a los 656Kb, sin contar en ambos casos las paletas ni los atributos de los sprites (posición, gráfico, paleta, etc.), y otros 248Kb para el motor 3D (polígonos y vértices). Si la comparamos con la N64 debemos tomar en consideración toda la memoria disponible, pues la consola de 64 bits de Nintendo empleaba 4 Mbytes de memoria unificada. En la NDS, hay un total de más de 5 Mbytes. De hecho, la memoria RAM principal ya es de 4 Mbytes, pero todas las tareas gráficas disponen de sus propias memorias dedicadas en la NDS, incluso el Wifi, y se han añadido pequeñas memorias adicionales que pueden utilizar ambas CPUs para comunicarse, o como pequeño almacen rápido de datos. Así pues, la comparación más justa que se me ocurre, lanza la siguiente evidencia; no se ha ampliado demasiado la cantidad de memoria de vídeo en las consolas, si se las contrasta con antecesoras de un mismo nivel y soporte de juegos. Así pues, tras toda esta historia, que pretendía dar un cierto trasfondo, se entiende bien cómo la VRAM es un bien cotizado y un recurso muy valioso en una máquina de juegos, y el porqué de su importancia en Wii.

El apartado gráfico

Partimos de un escenario, donde, como ya sabréis, la CPU de Wii podría superar por poco a la de la primera Xbox. Este hecho ya la sitúa más cerca de la pasada generación que de la actual, donde PlayStation 3 y Xbox 360 dominan en el aspecto técnico. ¿Qué tiene que decirnos el resto del sistema? Seguiré en la linea del último artículo, un tanto enfocado al análisis numérico y cuantitativo, pero espero que suficientemente desglosado para que la mayoría, y sobre todo los interesados en ello, lo entiendan. Preparaos, porque me temo que algunos vais a flipar. Pero tranquilos; otros muchos lo encontraréis hasta fácil. Recordad en todo momento, que la GPU de Wii se llama Hollywood, y la CPU, Broadway. En la primera parte de este artículo ya comentamos un poco el sistema de memoria, la GPU y los anchos de banda. En líneas generales, se podría decir que Wii supera a Xbox en anchos de banda, lo que, en otras palabras, significa que es capaz de mover datos y código con mayor fluidez. Destaca en este aspecto la velocidad de comunicación de la CPU con el sistema, casi dos veces mayor (1,9 Gb/s vs 1 Gb/s), lo que va a facilitar el aprovechamiento de los recursos del procesador, que por término medio tendrán que esperar menos tiempo en ser abastecidos. Y muy importante, y de gran impacto, la presencia de memorias embebidas en el Hollywood, que disponen de un canal de comunicaciones con el núcleo gráfico de alta capacidad, son inexistentes en el NV2A (GPU de Xbox), que no tiene más remedio que apoyarse continuamente en la memoria RAM principal, pues al ser compartida, reduce el tiempo que queda disponible para el resto del sistema.

Wii dispone de más cantidad de memoria que Xbox (88 Mb frente a 64 Mb), aunque emplea dos tipos diferentes de éstas.

Como ya mencioné, ambas máquinas cuentan con una memoria RAM unificada, que puede emplearse para cualquier propósito, en contraposición al esquema clásico de memoria de vídeo y memoria principal separadas. Este método lo comenzaron a usar consolas como la NES y la Master System, y lo sigue usando actualmente la PlayStation 3, y no de por sí es peor, pues tiene sus ventajas, pero sí es menos versátil. Wii dispone de más cantidad de memoria que Xbox (88 Mb frente a 64 Mb), aunque emplea dos tipos diferentes de éstas. Una es de tipo 1T-SRAM (los 24 Mb ya existentes en GameCube), y la otra, de tipo GDDR3 (los 64 Mb añadidos en Wii). Ninguna de las dos es más rápida que la ya obsoleta DDR de Xbox, que a pesar de trabajar a una frecuencia menor, usa doble canal. Voy a demostrar superficialmente estas afirmaciones, con los datos existentes en este momento, o al menos, los existentes en mis manos. Lo que expliqué sobre los tipos de memoria en la primera parte del artículo va a venir de lujo ahora. La Xbox usa una memoria DDR a 200 MHz. Como es DDR, realmente, a la hora de transportar datos, se comporta como si de una 400 MHz se tratara. Sus 64 Mb de memoria están divididos en dos chips de 32 Mb cada uno, con un canal de datos dedicado de 64 bits, lo cual permite acceder a ambos a la vez a través de un bus de 128 bits (64 + 64). El ancho de banda máximo en estas circustancias sería: 400 MHz * 128 / 8 = 6,4 Gb/s Ahora, al contrario. Se cree que la GDDR3 de Wii, una memoria basada en la DDR2, sucesora de la DDR, ofrece un ancho de banda de sólo 4 Gb/s. Esta memoria está alojada en un único chip, y por tanto no hay doble canal. Es posible que emplee un bus de sólo 32 bits, y en ese caso debería funcionar con un reloj de 500 MHz. Así, los números cuadran. Al ser una DDR, se comportaría como una 1000 MHz (2 x 500), y el cálculo anterior quedaría: 1000 MHz * 32 / 8 = 4 Gb/s. O lo que es lo mismo, es una memoria mucho más rápida, pero al emplear un bus de sólo 32 bits, suponiendo que así sea, en lugar de los anchos 128 bits de Xbox, acaba ofreciendo un ancho de banda menor. La ventaja de Wii es que el coste de nuevo se ve reducido, así como el tamaño, la complejidad y el consumo. Además de la GDDR3, Wii dispone de la 1T-SRAM que usaba GameCube, esta vez a 486 MHz, alojada en el mismo encapsulado que la GPU y que seguramente use un bus de 64 bits, alcanzando un ancho de banda prácticamente igual al de la GDDR3 ( 486 MHz * 64 / 8 = 3,9 Gb/s). Si el controlador de memoria del sistema permite al acceso simultáneo a ambas memorias, se podría entonces afirmar que Wii dispone de una especie de doble canal de memoria, y por tanto el ancho de banda, como en el caso de Xbox, sería la suma de ambos, y entonces Wii superaría claramente a la primera consola de Microsoft (7,9 Gb/s vs 6,4 Gb/s). La adición de la memoria GDDR3 abre la posibilidad de mejorar bastante la calidad gráfica de los juegos, echando mano de texturas, y permitiendo alojar cómodamente el mayor número de polígonos que el hardware mejorado permita mover.

La escasez de memoria en GameCube limitaba su potencial en algunas circustancias, y por tanto un poco más de memoria en Wii no habría venido nada mal, sobre todo teniendo en cuenta el coste.

Ahora, 88 Mb siguen sabiendo a poco, sobre todo al lado de los 512 Mb de Xbox 360 y PlayStation 3. Por lo visto, la escasez de memoria en GameCube limitaba su potencial en algunas circustancias, y por tanto un poco más de memoria en Wii no habría venido nada mal, sobre todo teniendo en cuenta el coste. No sé a qué precio andará un chip de memoria GDDR3 de los que monta la consola, pero uno de 64 Mb DDR2, que es distinto, pero primo hermano, cuesta unos 6 euros (por ejemplo, marca Micron Technology, comprado en lotes de al menos 1.000 unidades). Es más lenta que la memoria de Wii y no podría llegar a la tasa de transferencia requerida, pero es para hacerse una idea… de todos modos, seguro que se podría llegar a un buen acuerdo con Samsung o Qimonda, fabricantes de GDDR3 de los que Nintendo se abastece, para usar dos pastillas por consola, en lugar de una. Y sería razonable esperar que el coste del producto no se elevara demasiado. Por ir con más margen, existen chips DDR2 de la propia Qimonda, que están en torno a los 4 euros (siempre de 64 Mb y siempre que se compren en grandes cantidades, de al menos 2.000 por pedido, cosa nada importante en el caso de Wii). Aunque la GDDR3 fuera más cara, tenemos un punto de referencia. Y digo «aunque», porque no estoy del todo seguro. No está de más añadir que el precio de este tipo de chips, memorias de semiconductor en general, fluctúa muchísimo en el mercado y depende de bastantes factores. No es algo que baje constantemente, como sucede con otras tantas cosas, y a menudo los precios se estancan o suben. Pero vamos, al menos sirve para pensar que habría sido bastante razonable dotar a la consola de más capacidad en cuanto a RAM se refiere. De haber añadido otros 64 Mb adicionales, se podría haber habilitado sin mucho problema otro canal de memoria de 4Gb/s, además de haber otorgado a Wii unos ya nada despreciables 152 Mb de RAM, más que suficiente para apoyar el modesto aumento en la potencia del hardware. Pero veamos hasta qué punto la memoria disponible es suficiente.

Volvamos sobre los buffers de video una vez más…

Como ya comenté en anteriores artículos, un chip gráfico estándar hace uso de dos tipos de buffers para construir y mostrar la imagen en pantalla. Las cosas no se van dibujando en ella conforme van «viniendo», sino que se guardan temporalmente en lo que se suele denominar búffer de vídeo. Sobre esta copia «oculta» de la imagen se hacen todos los cambios pertinentes y solamente es envíada a la circuitería encargada de mostrarla en pantalla, en cada refresco de la misma, que en el sistema de televisión NTSC ocurre 60 veces por segundo (60 Hz) y 50 en el PAL (50 Hz). Pero para evitar parpadeos y otros problemas de eficiencia, se suele emplear un doble búffer de vídeo. Mientras se está formando la imagen en uno de ellos, se está volcando el anterior fotograma desde el otro búffer, que luego será sobre el que se construya, mientras se envía a la pantalla el que se estaba usando anteriormente. Además, en la gran mayoría de los sistemas, existe un búffer-Z, que guarda información sobre la profundidad de los objetos en la escena, desde el punto de vista de la cámara, lo que permite saber qué superficies ocultan a otras, por ejemplo. Estos buffers se alojan habitualmente en la memoria más rápida accesible por el chip gráfico. En la Xbox se guardan en su memoria RAM de 64 Mb, ya que no dispone de ningún otro tipo de memoria, y la emplea de forma unificada para todos los propósitos, ya sean datos, texturas o código ejecutable. Pero tanto en GameCube como en Wii, se dispone de una memoria especial, embebida en la GPU, de 1 Mb, para cada uno de estos dos buffers. ¿Por qué 1 Mb? Es menos de lo que cabe en un floppy… y sí, podrían haber sido más generosos, pero ¿por qué 1 Mb?

Normalmente al construir una escena hay que redibujar varias veces algunas áreas que están cubiertas por objetos que las ocultan a la vista de la cámara, y en el momento de dibujar la zona oculta, tal hecho era desconocido por el hardware gráfico.

Bueno, al contrario que otras memorias, como sucede con un disco duro, un pendrive USB o un floppy, donde cuanta mayor capacidad, más cosas puedes ir metiendo, la función del búffer de vídeo es muy concreta. Únicamente necesita tener el tamaño suficiente para almacenar la información de todos y cada uno de los pixels de la pantalla. Como en Wii se emplea una resolución de 640 x 480 progresivos (o 480p), hay un total de 307.200 pixels en la pantalla, cada uno representado por un color de 24 bits, o lo que es igual, 3 bytes. Si hacemos la multiplicación, 307.200 * 3 = 921.600, o lo que es lo mismo, casi 1 Mb. Este mismo razonamiento se puede aplicar al búffer-Z, si suponemos que la profundidad de cada píxel es representada por un valor de 24 bits (lo que permite más de 16 millones de niveles de profundidad posibles, que ya está bien). Para ver la ventaja que otorga disponer de memorias embebidas en la GPU para los buffers, veamos la cantidad de tráfico que genera dibujar un fotograma en la pantalla de la Xbox y en Wii. En la Xbox, como los buffers se guardan en RAM, al no haber ninguna memoria dedicada, hay que generar y escribir el buffer-Z, y luego leerlo para formar la imagen en el búffer de vídeo activo, tal y como se va a ver la escena. Si suponemos, para simplificar los cálculos, que cada buffer ocupa 1 Mb, hay que escribir dos veces, y leer una, lo cual significa 3 Mb de tráfico por fotograma. Si se quiere mantener un ritmo estable y fluido de 60 fotogramas por segundo, 3 * 60 = 180 Mb cada segundo. Pero en la Xbox, el búffer-Z se comprime y descomprime en tiempo real por la GPU para ahorrar ancho de banda, a un tercio de su tamaño, más o menos. Así pues, el cálculo sería: (1 + 2*(0.33)) * 60 = 99,6 Mb. Pero aquí no acaba la cosa. Normalmente al construir una escena hay que redibujar varias veces algunas áreas que están cubiertas por objetos que las ocultan a la vista de la cámara, y en el momento de dibujar la zona oculta, tal hecho era desconocido por el hardware gráfico. A esto se le llama «overdraw». Y el nivel de overdraw depende muchísimo del juego y la escena, pero podemos suponer una media de 2,5 veces, lo cual implica que para llenar una pantalla con todos sus pixels hay que procesar el equivalente a dos pantallas y media. Por tanto, el tráfico generado por los buffers gráficos en el bus de memoria de Xbox en estas circustancias rondaría los: 99,6 * 2,5 = 249 Mb. Si me permitís redondearlo a 250 Mb… que conste que no soy partidista, ni intento hundir a esta estupenda consola. Es para simplificar los cálculos, por si las moscas.

En Wii existe otra pequeña memoria embebida para texturas, también de 1 Mb. Su uso es completamente distinto, ya que sirve principalmente para “cachear” texturas que se estén usando en ese momento.

Ahora bien, como Wii dispone de memoria embebida para los buffers de vídeo y búffer-Z, el único momento en el que se usa el bus es para enviar la imagen final, es decir, el búffer de vídeo a la memoria RAM, desde donde ya se manda a la pantalla. O en otras palabras, alrededor de 1 Mb, 60 veces por segundo. Sí, claro, eso genera un tráfico de alrededor de 60 Mb cada segundo, frente a los 250 Mb/s de la Xbox, lo que ilustra las ventajas de emplear memorias embebidas. Por ello, aunque el ancho de banda de RAM de Xbox y Wii fuera el mismo, la consola de Nintendo estaría claramente por delante en este apartado, gracias a estas memorias, integradas en la GPU, que reducen el tráfico en el sistema de memoria RAM, compartido por todos los recursos. Además, las memorias embebidas o integradas suelen ser bastante más eficientes y rápidas, por lo que su uso en tareas críticas como éstas facilita la aproximación al aprovechamiento máximo del potencial gráfico de la consola. Como parece razonable pensar que Wii dispone de un ancho de banda superior al de Xbox, como ya dije (7,9 Gb/s por 6,4 Gb/s), esta diferencia teórica se vería aún más aumentada en el mundo real, a favor de Wii. Además, en Wii existe otra pequeña memoria embebida para texturas, también de 1 Mb. Su uso es completamente distinto, ya que sirve principalmente para «cachear» texturas que se estén usando en ese momento. Es el canal con mayor ancho de banda de Wii, superando, estimo yo, los 15 Gb/s, o lo que es lo mismo, permitiendo a la GPU un acceso a las texturas 2,5 veces más rápido que en Xbox con todo su ancho de banda dedicado a esta tarea, lo que obviamente no es sostenible, porque el sistema no sería capaz de hacer nada más. La cara negativa de la memoria de texturas de Wii es su reducido tamaño. Para paliarlo, tanto GameCube como Wii, al igual que Xbox, usan un sistema de compresión de texturas, que puede llegar a un ratio de 6:1, o en otras palabras, el diminuto búffer de 1 Mb de texturas de Wii podría alojar unos 6 Mb de texturas, con una pérdida de calidad muy baja, y que en la mayoría de los casos permite usar texturas de color de 24 bits, sin que ocupen más espacio que de 16 o incluso de 8 bits. A este sistema se le denomina S3TC. Pero ni Xbox ni GameCube fueron las primeras en hacer algo así. La Dreamcast ya usaba otro método de compresión de texturas, Vector Quantization, que aunque no podía comprimir transparencias, aumentaba dramáticamente la capacidad de texturas de su memoria de vídeo, hasta un ratio máximo de 5:1. Nada despreciable.

Ancho de banda efectivo. Vamos al terreno práctico

Ahora bien, por mucha memoria embebida de texturas de que disponga la Wii, al final toda textura debe leerse del disco de juego (en los periodos de carga, por ejemplo), escrita en memoria RAM y luego envíada a la GPU cuando sea requerida, donde el búffer pueda almacenarlas para ser reutilizadas si es preciso, sin necesidad de releerlas de la RAM. Esto significa que cada vez que se requiera una textura ya alojada en la GPU, el resto del sistema no sufrirá ninguna penalización. Se tomará de la memoria embebida y listo. Pero cuando se hace necesaria una textura que al no caber, está almacenada en la memoria RAM, más grande, pero más lenta, habrá que recurrir a algún bus del sistema para traerla, afectando de esta forma al resto de funciones de la máquina, al ser el bus un recurso compartido. Por tanto, es necesario conocer el ancho de banda que se tiene para enviar texturas a la GPU, sin tener en cuenta memorias embebidas. Esto sirve para saber qué ocurriría en el peor caso, en el que al no reutilizarse apenas, las texturas tuvieran que traerse siempre de RAM y la memoria embebida apenas sería de ayuda. Vale, éste es un golpe duro a la Wii, que la hace descender hacia la Xbox, pero veamos qué tal lo encajaría.

Es necesario conocer el ancho de banda que se tiene para enviar texturas a la GPU, sin tener en cuenta memorias embebidas.

Vamos a suponer un ancho de banda total inicial de 6,4 Gb/s para Xbox y de 7,9 Gb/s para Wii. En primer lugar, la CPU de Xbox tiene un ancho de banda de alrededor de 1 Gb/s. Como ya expliqué en la anterior entrega, no es difícil que la CPU consuma ese ancho de banda y por tanto vamos a restarlo del total disponible en ambos sistemas. De momento, Xbox, 5,4 Gb/s y Wii, 6,9 Gb/s (si suponemos que el PowerPC de Wii tiene un juego de instrucciones más eficiente que el pseudo-Pentium III de Xbox, seguramente no sea descabellado pensar que será capaz de aprovechar algo mejor ese mismo gigabyte). Ahora, la GPU consume, no sólo texturas sino también polígonos. Por tanto hay que contabilizar el tráfico de polígonos al transferirlos desde la RAM. De nuevo, el tamaño de un polígono varía bastante. En principio, si suponemos un triángulo de tres vértices, sabiendo que la posición de cada vértice se describe como tres números de 32 bits, hasta aquí tenemos 3 * 3 * 32/8 = 36 bytes. Si además hay información de color, habría que añadir al menos otros 32 bits para describirlo. Y puede haber otros tipos de datos provenientes de iluminación, efectos, etc. que no vamos a considerar, pues en algunos casos los programadores usan números de 16 u 8 bits para comprimir el tamaño de los vértices, perdiendo precisión en su posición, pero ahorrando espacio. Así que una cosa por otra, vamos a suponer que cada triángulo ocupa 36 bytes en RAM. Y puestos a soñar, imaginemos un mismo juego en Xbox y Wii, con idénticos requisitos, y en una escena que mueva unos 8 millones de polígonos (relativamente fácil para Xbox y Wii). El tráfico generado por estos polígonos será pues de 8 millones pol/s * 36 = 288 Mb/s. Vamos a redondear a 300 Mb/s y a restarlo del ancho de banda restante en ambos sistemas. Xbox, 5,1 Gb/s y Wii, 6,6 Gb/s. Ahora llegan algunas diferencias. Vamos a tener en cuenta el tráfico que generan los buffers de video y búffer-Z para construir un fotograma, que ya calculamos anteriormente:

• Xbox: 5,1 Gb/s – 0,25 = 4,85 Gb/s.
• Wii: 6,6 Gb/s – 0,06 = 6,54 Gb/s.

Ahora entran factores más sui-generis, pero con impacto real. Por ejemplo, aunque el tráfico generado por el audio es habitualmente despreciable, pues puede rondar varios megabytes por segundo únicamente, Wii dispone de una memoria dedicada de 16 Mb, con un bus también dedicado, por lo que no se requiere molestar a la memoria RAM, y por tanto, no influir a los hermanos mayores: CPU y GPU. Mientras que en Xbox, aunque supone un caudal muy pequeño de datos, el audio debe sumarse a la muchas peticiones de su única memoria, los 64 Mb de DDR unificada, (a la que le tienen que estar pitando ya los oídos) y su único bus de 6,4 Gb/s (idem).

La DDR (Xbox) y GDDR3 (Wii) tienen latencias claramente superiores a la 1T-SRAM (Wii), y aún mucho más que las memorias embebidas en la GPU de Wii.

Pero tal vez lo más importante sean las latencias. Como ya comenté por encima en la primera parte, la latencia afecta bastante al rendimiento de la memoria, y por tanto, al ancho de banda real. La latencia es el tiempo que tarda el chip de memoria en responder a una petición. La DDR (Xbox) y GDDR3 (Wii) tienen latencias claramente superiores a la 1T-SRAM (Wii), y aún mucho más que las memorias embebidas en la GPU de Wii. Parece correcto afirmar que en la mayoría de los casos una memoria DDR sólo se aprovecha plenamente entre un 70 y un 80% del tiempo. En mi PC uso DDR2, y consigo aprovechar un 76% del ancho de banda teórico, luego tengo otro motivo más para pensar que dicha suposición es probablemente válida, o al menos no descabellada. Si asumimos, optimistamente, que la DDR de Xbox alcanza un rendimiento del 80%, podríamos entonces ver reducido su ancho de banda total de 6,4 a 5,12 Gb/s, y tras restar todo lo anterior, en lugar de los 4,85 Gb/s que obtuvimos sin tener en cuenta la latencia, quedarnos en unos 3,57 Gb/s. En el caso de Wii es más complicado porque hay que calcular las latencias por separado para cada memoria. Su GDDR3 sufriría una penalización similar, en principio, pero la 1T-SRAM podría alcanzar un aprovechamiento del 90%, algo razonable teniendo en cuenta su menor latencia respecto a una SDRAM convencional. Adelanto que el resultado es 5,36 Gb/s, pero por si alguien quiere romperse la cabeza, dejo los cálculos, que por cierto son muy sencillos. Quien no, p’alante.

• Ancho de banda total de la GDDR3 = 4 Gb/s * 0.8 = 3,2 Gb/s
• Ancho de banda total de la 1T-SRAM = 3,9 Gb/s * 0.9 = 3,51 Gb/s

Se suman, y se restan los anchos de banda de la CPU, de polígonos y de buffers, es decir, 1 Gb/s, 0,3 Gb/s y 0,06 Gb/s, respectivamente.

Vale, vale, ¿y ahora qué?

Observamos una mejoría en Wii del 10% en el ancho de banda que quedaría libre para transferencias de texturas. Por cierto, para quien se haya perdido, esto es lo que intentábamos hallar. En palabras sencillas, es una mejora sustancial, pues GameCube no llegaba ni a la mitad de la capacidad de la Xbox en este apartado. Por motivos obvios, ya que me gustaría que la gente leyese todo este cuento, me salto los cálculos y demostraciones. Me creéis y ya está, jeje. Pero si hay alguién interesado, que lo pida. Y debo aclarar una vez más que estos cálculos suponen que Wii puede acceder simultáneamente a sus dos memorias RAM. De lo contrario, su puntuación en ancho de banda efectivo se vería drásticamente afectada.

La capacidad de renderización está a menudo limitada por el ancho de banda del que dispone la GPU para comunicarse con su memoria de vídeo.

El porqué tanto empeño en averiguar el ancho de banda aproximado que puede dedicarse a mover texturas por los buses del sistema es debido a que dicha capacidad resulta un factor muy importante, incluso decisivo, en el rendimiento de un sistema gráfico 3D. Para ser más precisos, la capacidad de renderización está a menudo limitada por el ancho de banda del que dispone la GPU para comunicarse con su memoria de vídeo. Y las texturas suelen ser las que generan un mayor tráfico, sobre todo cuando se usan ciertos efectos, como el antialising y filtrados trilineares y anisotrópicos, por nombrar cosas habituales. De nada vale dotar a la GPU de poderosas unidades de texturización, si no son capaces de recibir las texturas suficientemente rápido. Sólo un sistema balanceado, sin cuellos de botella pronunciados, puede ostentar el aprovechamiento más o menos completo de sus recursos. De ahí la importancia de este ancho de banda. Pero me temo que no hemos acabado del todo, aunque queda poco. La memoria embebida para texturas de Wii permite reutilizar las texturas almacenadas a través de un canal dedicado y nada despreciable de unos 15 Gb/s. Esto, como cabría esperar, aumentaría notablemente el ancho de banda efectivo. En otras palabras, esa pequeña memoria crearía la ilusión de que Wii dispone en realidad de un ancho de banda mayor del que calculamos hace un momento, los 5,36 Gb/s de las memorias externas. En un caso medio en el que una escena esté usando unos 30 Mb de texturas, el sistema estaría viendo un ancho de banda efectivo de más de 6 Gb/s, en el peor de los casos, poco más que los 5,36 Gb/s.

Wii viene a ser algo así como la Dreamcast. La última consola de SEGA dejaba tirada a PlayStation, Saturn y Nintendo 64, pero no podía plantar cara a las consolas que en la siguiente generación verían la luz.

Pero si unas pocas texturas fueran muchas veces reutilizadas, se podría sin problemas superar los 10 Gb/s, o incluso más. Y cuanto más nos aproximemos a estas condiciones, más nos acercaremos a los 15 Gb/s correspondientes a la memoria embebida. En cambio, la Xbox, cuya GPU no tiene memoria embebida, sólo dispone de una pequeña caché para texturas, que en cualquier caso será bastante más pequeña que la de Wii, y apenas podrá mejorar mucho el desempeño en este apartado, a no ser, de nuevo, que muy (muy) pocas texturas se reutilizaran a saco (en cualquier caso, la hipotética escena daría pena, jeje). Éste es un apartado en el que GameCube y Xbox reñían duramente, quedando la pequeña de Nintendo ligeramente por debajo (en mi opinión) y que ahora supera con margen Wii. Claro que muchos ya estaréis pensando (espero) que la Xbox es una consola de la pasada generación, y que la comparación no es justa. Y es cierto, pero Wii es una consola que, tecnológicamente hablando, sería más una extensión de la generación pasada, que un miembro de la actual, y no tiene sentido compararla en un asalto frontal a PlayStation 3 o Xbox 360, que además sería más complicado. Wii viene a ser algo así como la Dreamcast. La última consola de SEGA dejaba tirada a PlayStation, Saturn y Nintendo 64, pero no podía plantar cara a las consolas que en la siguiente generación verían la luz. Podríamos bautizarlas a ambas como consolas inter-generacionales, ¿qué os parece? (por cierto, habría que añadir al menos un tercer miembro, la TurboGrafx y sus versiones japonesas, la PC Engine, Core Grafx, Turbo Duo, etc. que fueron las 8 bits más potentes, llegando a resultados cercanos a los que lograba una Mega Drive). Llegados a este punto, os aconsejo un descanso. Me salto la conclusión hasta la última entrega, que ya está al caer. Y después de esta «saga», vendrán otros artículos de índole muy distinta. Ya estoy maquinando.