Gráfico Retro: Gamecube (y Wii)

#1 Historia

Nintendo64 fue el primer mazazo importante para Nintendo, después de cosechar enormes éxitos la consola no estaba teniendo el éxito esperado en Japón pero principalmente Nintendo estaba muy enfadada con Silicon Graphics porque opinaba que habían boicoteado a la consola adrede para que no hiciese la competencia a las estaciones de trabajo de Silicon Graphics.

Nintendo estaba viendo como un hardware contemporaneo a N64 pero presentado a puerta cerrada como el M2 no solo no tenía los problemas del hardware de N64 sino que además existía una versión más avanzada del chipset. 3DO le habia ofrecido con anterioridad el hardware de la sucesora de M2 a Sega había estado a punto de utilizarlo pero al final las negociaciones no habían ido a más por la entrada de Nintendo a mediados de 1996 en el proyecto, es decir, mientras Nintendo64 salia en Japón en Nintendo tenían ya planes para su sucesora y esta vez utilizando una versión más avanzada de la M2 de Matsushita a la que habían llamado MX.

Como recordaréis la M2 no fue lanzada al mercado, el motivo es que Matsushita/Panasonic decidió hacer una apuesta más fuerte al acercarse el DVD y se planteo hacer una consola con DVD y busco la colaboración primero de Sega que se nego por completo y luego de Nintendo para lanzar una versión más avanzada de la M2 que fue la MX y que fue la base para el diseño de Gamecube.

En teoria la MX tenia que reemplazar el doble PowerPC 602 por un PowerPC 604e en su primera versión, pero ya añadia algunos elementos que años más tarde se verían en el hardware final de Gamecube como es el añadido de un DSP de audio independiente en el chip de la gráfica y la memoria embebida. Pero Nintendo tenía unas buenas relaciones con NEC Electronics y no la queria perder, dichas relaciones han durado hasta Wii U empezaron con N64. El problema de Matsushita era que tenían un trato de fabricación de lo chips gráficos con Cirrus Logic y eso no agradaba a Nintendo dado que tenia un contrato a largo plazo con NEC Electronics y no iban a poder cumplirlo debido a que las ventas de N64 no eran las esperadas por lo que en Nintendo se veían con la obligación de meter a NEC por algún lado.

Inicialmente propusieron cambiar la CPU de PowerPC a MIPS pero esto significaba retocar el chip, inicialmente Matsushita que tenía como objetivo el poder lanzar la consola a corto plazo acepto pero Nintendo empezo a colocar exigencias encima de la mesa como la retrocompatibilidad total hacía atrás con Nintendo64 al completo. Todo ello eran exigencias para tener la propiedad intelectual del hardware que se estaba desarrollando en ese momento. Matsushita no llego a un acuerdo con Nintendo y vendio la división 3DO a Samsung donde fue renombrada como CagEnt. Nintendo entonces rompio relaciones temporales con Matsushita pero les compro el diseño de la siguiente consola aunque años más tarde pactarian el lector optico para la consola y Nintendo les permitiría vender una versión de Gamecube con soporte para DVD Video llamada Q.

Dicen las malas lenguas que Nintendo estuvo altamente convencida del hardware de la nueva consola y que incluso se dice que habia cierta demo corriendo en dicho hardware. Nintendo se intereso en comprar la renombrada 3DO como CagEnt a principios de 1998 para terminar su consola pero…

Según informaciones, Microsoft trabaja en la consola de juegos.

27 de abril de 1998 Paul Thurrott | Windows IT Pro

Según las últimas informaciones, Microsoft Corporation pretende permitir que su dispositivo WebTV de próxima generación compita con las consolas de juegos Nintendo 64 y Sony Playstation. La historia es bastante complicada, pero es algo así: hace unos años, una compañía llamada 3DO estaba trabajando en su propia consola de juegos de próxima generación, que se denominó M2. El M2 contenía tres tecnologías clave que fueron bastante impresionantes para su día: reproducción de DVD, decodificación MPEG3 y un nuevo conjunto de chips llamado MX. Cuando quedó claro que 3DO tendría que salir del mercado de hardware por razones financieras, vendió la tecnología M2 a Samsung, que creó una división llamada CagEnt que tenía dos años para ganar dinero con ella.

La tecnología M2 utilizaba dos microprocesadores PowerPC 602 en ese momento: la misma CPU que funciona con las computadoras Apple Macintosh. A fines de 1997, Nintendo visitó CagEnt en busca de un nuevo conjunto de chips 3D ya que su relación con Silicon Graphics se había derrumbado y las ventas de la Nintendo 64 fueron más lentas de lo esperado. A principios de 1998, Nintendo terminó oficialmente su relación con Silicon Graphics y ofreció comprar CagEnt directamente.

Mientras continuaban los detalles de la venta, Nintendo trabajó con CagEnt para envolver su conjunto de chips MX alrededor de un procesador MiPS, ya que las consolas de la compañía usan CPU NEC MiPS, no PowerPC. El plan era parala nueva máquina basada en MX, hardware completo para el 3D, DVD-ROM y con la capacidad de soportar cartuchos para la Navidad de 1999. Desafortunadamente para Nintendo, las conversaciones con Samsung no llegaron a buen puerto y las negociaciones se rompieron, momento en el que intervino Microsoft.

Por otro lado el equipo de desarrollo del RCP de N64 había roto relaciones con Silicon Graphics por completo y crearon su propia compañía llamada ArtX. SGI los denuncio paralizando por completo sus actividades hasta Mayo de 1998 donde un tribunal en los EEUU archivo el caso y dejo a ArtX libre de poder operar. Dado que Nintendo había perdido a CagEnt contrataron a ArtX para realizar un chip con capacidad similar para una futura consola que en ese momento no era más que un boceto.

En realidad aunque parezca mentira, Nintendo armo su consola entre 1999 y el año 2000 y justo después de la presentación de PlayStation 2, momento en el que fue pactando con los diferentes socios. Es decir, Nintendo no tenia ninguna consola cuando PlayStation 2 habia sido presentada ya terminada. En realidad ArtX no tenia nada que presentarle a Nintendo y el primer chipset que había hecho era el Aladdin7 para el mercado del PC que tratare más adelante. Es decir, Nintendo invirtio y mantuvo a flote a ArtX durante uno años pero era como quien paga ahora un kickstarter, es más, solo eran 20 personas y cuando Nintendo anuncio Gamecube bajo el nombre Dolphin y tenían solo un año para hacer todo el trabajo e incluso menos, y lo consiguieron, Nintendo consiguio presentar su nueva consola en el Space World del año 2000.

#2 Arquitectura General del Sistema.

Gamecube tiene la arquitectura más simple de las consolas de su generación y se trata de una evolución de la arquitectura de Nintendo64 en muchos aspectos, se puede decir que es una Nintendo64 corregida y altamente vitaminada.

Los diferentes componentes del hardware excepto el sonido los ire tratando a continuación:

#3 IBM Gekko

El Gekko CPU es un IBM PowerPC 750 con 256KB de cache de segundo nivel, es la primera consola en la historia en disponer una CPU con memoria cache de segundo nivel, lo que le da ventaja enorme en cuanto a rendimiento respecto a otras CPUs contemporáneas.

En informática, la caché es la memoria de acceso rápido de una computadora, que guarda temporalmente los datos recientemente procesados (información).^[1]

La memoria caché es un búfer especial de memoria que poseen las computadoras, que funciona de manera similar a la memoria principal, pero es de menor tamaño y de acceso más rápido. Es usada por el microprocesador para reducir el tiempo de acceso a datos ubicados en la memoria principal que se utilizan con más frecuencia.

La cache en GameCube esta como un método para evitar la latencia de la memoria, por lo visto los ingenieros de Nintendo se traumaron tanto por los problema de N64 que decidieron solventarlos a través de la cache L2 y la 1T-SRAM.

En una comparación de tu a tu si hablamos de la operación con enteros solo es superada por la CPU de Xbox que ya tratare en su entrada, el caso es que la CPU de GameCube puede realizar 1125 MIPS en el Dhrystone con una velocidad de 486 MHz, lo cual es más del doble que los 450 MIPS del R5900 que lleva PS2 en su interior y por supuesto más que los 360 MIPS del SH4 de Dreamcast.

En lo que a coma flotante se refiere IBM y Nintendo hicieron un ligero cambio llamado Paired-Singles. La idea es quitar el soporte de coma flotante de 64 bits porque es inútil en una consola de videojuegos pero mantener sus registros y cambiar su set de instrucciones para permitir operaciones dos operando, las cuales son utilizadas para realizar ciertas operaciones gráficas sobre el búfer de imagen frontal, el cual se almacena en la memoria principal (aunque a eso ya llegaremos).

La idea de desdoblar una ALU y sus registros en dos ALUs con la mitad de precisión actualmente lo hemos visto en GPUs y en cosas como el Rapid Packed Math de AMD, esto es directamente lo mismo. Precisamente este cambio en la FPU es de las dos únicas cosas que que diferencian al Gekko de un G3 estándar.

#4 LSI Flipper y RAM del sistema

El LSI Flipper, al contrario de lo que muchos afirman, no es la GPU de Gamecube sino que incluye la GPU de la consola referenciada en honor a la API de la misma como GX GPU pero en sus 55 millones de transistores incluye:

• El Uncore/Northbridge del sistema que le da acceso a todos los componentes a la RAM.
• La GX GPU Obviamente.
• El Southbridge que consiste en los controladores de E/S para los periféricos.
• Un DSP de sonido diseñado por Macronix.
• 2MB de memoria embebida para el bufer de imagen y 1MB para cache de texturas.

En realidad es un SoC y las siglas LSI es una forma de decir también SoC, solo que la CPU no se encuentra en su interior por lo que Nintendo al igual que su predecesora directa continuo con el concepto de tener solo dos chips en la placa base.

Dado que el controlador de memoria se encuentra en el Flipper, el Gekko ha de acceder a través del controlador de memoria en el Flipper a la RAM. Nintendo con tal de evitar los problemas de latencia no solo coloco una cache L2 a la CPU de la consola como he comentado antes sino que además utilizo un tipo de memoria DRAM bastante particular llamada 1T-SRAM de la compañia MoSys.

La memoria SRAM se suele utilizar en las memorias más cercanas al procesador porque aguanta velocidades más altas y tiene menor latencia pero al mismo tiempo es mucho más cara que la DRAM, la cual no tiene esas ventajas pero su densidad es mucho mayor. El salto de la SRAM a la DRAM se dio con los ordenadores de 16 bits aunque en consolas no fue hasta las consolas de 32 bits.

La memoria SRAM ocupa mucho más espacio dado que suele utilizar entre 4 y 6 veces más transistores y almacena los datos en un par de puertas lógicas, esto le permite almacenar los datos más tiempo y por eso es fiable como cache.

La DRAM en cambio almacena los datos en un condensador/capacitor y esta se debe ir actualizando, no es tan fiable pero es mucho más barata.

Por lo que la 1T-SRAM solo por la definición de su nombre no puede ser memoria, en realidad la memoria 1T-SRAM es lo que llamamos una PSRAM o Pseudo-SRAM, por lo que hablamos de una DRAM con varios circuitos internos de control en el chip que le permiten operar como una SRAM. En el caso de la 1T-SRAM de MoSys este es el motivo por el cual ambos chips de memoria tienen la extraña densidad de 12MB y no de 16MB, algo que para muchos desarrolladores teniendo 32MB en PS2 y 64MB en Xbox resultaba en una enorme limitación.

No obstante la 1T-SRAM fue utilizada por Nintendo en la GX GPU para almacenar el Backbuffer y como cache de texturasd de manera interna en el chip, con 2MB de memoria para Z-Buffer y Color Buffer (Back Buffer) y 1MB como cache de texturas. Esto es un elemento heredado de los dias del proyecto MX…

Estamos hablando de antes de que ArtX entrase como socio para desarrollar la GPU del nuevo sistema y cuando Nintendo iba a utilizar el hardware de CagEnt que no eran otros que lo de 3DO después de que Matsushita revendiese la empresa a Samsung.

El recorte de revista esta ilegible pero os transcribo y traduzco lo que pone:

La imagen del nuevo hardware no estaría completa sin incluir a 3DO, así que vamos a cambiar las marchas sobre la MX. Como la M2 con anterioridad, 3DO aclama que la MX será su arma topep para esta negociación. Nuestros espia no han informado que el sucesor de la M2 ya ha pasado la etapa del documento de diseño y actualmente se encuentra en un hardware real. Por el momento, el chipset de la MX es fisicamente enorme (apenás cabe en una mesa) pero una vez que 3DO elimine todos los fallos trabajaran en reducir el tamaño (una práctica común en el negocio del hardware). De todos modos, el MX es impresionante con 5 millones de poligonos moviendose en pantalla. No solo puede producir los gráficos con filtro trilineal y Edge Antialiasing de la N64 y de la M2 sino que puede efectuar otros efectos Filtro Anisotropico, Phong Lighting y Surface Antialiasing. El secreto del alto rendimiento radica en su arquitectura radical de hardware. Al contrario que otros antes de este, la RAM en el MX se encuentra en el mismo chip que la CPU y el procesador gráfico.

Es decir, Gamecube desde sus inicios iba a tener memoria embebida y tiene sentido desde el momento en que una de las desventajas de Nintendo64 era el problema del ancho de banda respecto al Z-Buffer, el cual era un problema común en la época. Dreamcast lo había solventado con el Tile Rendering y PlayStation 2 como Gamecube lo soluciono con memoria embebida de tal manera que no impacte con la RAM principal, esto le daba la posibilidad a Nintendo de montar la consola con dos chips de memoria solamente y ahorrar en chips de memoria externa, una de las obsesiones de Genyo Takeda de cara diseñar consolas de bajo coste.

La otra memoria es la A-RAM, falsamente llamada Audio-RAM cuando en realidad quiere decir Auxiliary RAM. ¿Su existencia? Tiene una historia bastante extraña y se remonta a uno de los problemas que tenía la Nintendo64. Como sabréis es oficial que la consola no tuvo CD-ROM pero si que hubo unidades CD-ROM externas hechas por terceros como el Doctor V64 o V64 a secas.

El SDK oficial de N64 lo que hacía era volcar la información del cartucho temporalmente a una N64 en placa sin slot de cartuchos pero con RAM en su interior por lo que el testeo de los juego y la programación se hacía en la misma máquina, con el Doctor V64 podían probar los juegos en el hardware real pero de la misma manera que en el SDK necesitan algo para emular el cartucho y se vendía con un cartucho especial con RAM en su interior.

En las fases iniciales de Gamecube la consola había de ser compatible hacía atrás con Nintendo64 por lo que en el diseño inicial de la placa añadieron la RAM para emular el cartucho, cuando se descarto por completo dicha RAM sirvió como cache de disco y para almacenar datos que no necesitan tanto ancho de banda para funcionar como es el audio, de ahí a que también se la llame Audio-RAM pero esta RAM no es utilizada jamás para gráficos.

Otra de la particularidades es que tenía que servir para poder conectar el 64DD y poder volcar los datos, en N64 se utiliza el espacio adicional del expansión pak para ello, Nintendo no vendía un cartucho de RAM con el 64DD porque eso eliminaba la posibilidad de la combo cartucho+disco. El caso es que el 64DD como toda unidad de discos magneticos necesitaba de RAM para volcar sus datos. Ahora bien, Gamecube carece del 64DD como accesorio, pero esto tiene una explicación muy simple.

Matsushita/Panasonic convencio a Nintendo que usara tarjetas SD en un adaptador especial para reemplazar al 64DD, dado que los costes para Nintendo y el usuario eran mucho más bajos dicha idea se mantuvo aunque en Gamecube la tarjeta SD fue una rareza uno de los cambios que Nintendo hizo en Wii en el LSI Hollywood fue añadirle un lector de tarjetas SD y su interfaz de manera adicional, aparte de 512MB de NAND Flash pero su mayor cambio fue el remplazo de la lenta SDRAM de 8 bits a 81 Mhz de Gamecube a una memoria de 64 bits de ancho de banda con 64MB de densidad.

En Wii al contrario de Gamecube se puede utilizar la A-RAM (renombrada a MEM2 o External RAM en Wii) como RAM principal de los juego, tiene un poco más de latencia que la 1T-SRAM pero es que entre la cache L2 en el Gekko/Broadway y la 1T-SRAM era una obra de sobre-ingenieria y no hacía falta tanta complicación en el fondo en cuanto a la memoria pero Nintendo mantuvo por temas de tiempo de las instrucciones los 24MB de 1T-SRAM en Wii e incluso los coloco dentro del mismo encapsulado pero en un chip diferente.

#5 GX GPU

La GX GPU son una serie de componentes encargados del pipeline gráfico de Gamecube que se encuentran en el LSI Flipper junto a los otros componentes previamente descritos.

No obstante la GX GPU y el LSI Flipper en general tienen una historia muy curiosa y si, se que la he explicado previamente en esta misma entrada pero la voy a ampliar un poco.

En 1997 los ingenieros que habían hecho el RCP se fueron de SGI al ver como se acercaba la era de los chips en 3D para PC para crear su compañía. no se fueron directamente con Nintendo sino que decidieron entrar en el mercado de los chipsets de bajo coste para PC. En esa época las aceleradoras 3D eran una novedad pero habían visto como en el tema del sonido muchas placas base habían integrado la funcionalidad o el propio YM3812 para el sonido haciendo que este se estandarizará y como le ocurrio a 3Dfx pensaban que el futuro estaba en integrar la gráfica en el chipset del PC (Junto al Northbridge), al contrario de 3Dfx lo consiguieron y sacaron el producto para las placas base de Socket 7 (Pentium, Pentium MMX y toda la gama de AMD hasta el K6-III).

El chip se ve aquí con más detalle:

Nintendo se intereso por el mismo porque por tema de costes le servía para ahorrarse el Northtbridge y así se reducía la complejidad de la placa base de la futura consola, aunque le pidio a ArtX que adaptase al chip para la interfaz 60X de los PowerPC pero lo que realmente atrajo a Nintendo era una particularidad de la que carecían muchos chips de la época que era el
añadido de una unidad geométrica, el problema es que en pleno 1999 en PC apenás habían juegos que lo utilizaran por no decir ninguno… Incluso Quake 3 tiraba de CPU para la geometría y por lo visto las unidades de rasterizado y texturizado del Aladdin 7 no eran tan buenas en comparación con lo que había en el mercado como era la TNT2.

Lo que mato a la aventura en solitario de ArtX en PC fue la aparición repentina del Athlon/K7 con un tipo de placa base nuevo que inutilizo su chip para el mercado del PC. Pero Nintendo no estaba en el mercado del PC y sabía que con el PowerPC no podían competir contra las capacidades geométricas del SH4 de Dreamcast y necesitaban de un motor geométrico. El otro motivo es que al ser una unidad de función fija en cuanto a la geometría no necesita de complicados microcodigos como en el RSP de N64, facilita enormemente la programación y conocer el rendimiento de antemano del sistema de forma mucho más fácil.

Para empezar hemos de tener en cuenta que alcanza velocidades muy altas a la hora de calcular la geometria, en realidad la unidad XF es muy rapida y los cuellos de botella se encuentran en partes posteriores del pipeline. Lo unico que hace es en modo automático el World Space Pipeline clásico con la capacidad de calcular el Vertex Color…

Es decir, la unidad XF calcula de manera automática y secuencial las famosas matrices y envia los datos directamente al rasterizador. Pero tiene un talón de aquiles que esta esta en el hecho que durante la etapa de goemetria no se pueden manipular los datos en ninguna de sus etapas. Esto significa que la consola no soporta Vertex Shaders e incluso algoritmos de manipulación de vertices como es la teselación que se tenían que hacer por CPU, es más… El agua de Wind Waker es teselada a través de CPU como pre-proceso al envio de los vertices.

Tenemos ejemplo como el no-port del Burnout 3 donde al no poder la GX GPU manipular gran cantidad de vertices esto era enviado a la CPU. PlayStation 2 no tenía problemas para ello por la unidad VU0 y porque esta funciona en paralelo con la CPU, en Gamecube la FPU mejorada toma tiempo de la CPU y no tiene tanta capacidad de calculo porque además se tiene que encargar de otras cosas. Pero el caso más sonado es el del Doom 3 que nunca tuvo versión de Cube no solo porque Microsoft pagase mucho dinero como exclusiva sino porque hacía uso de los Vertex Shader para sus gráficos.

No obstante en potencia bruta la unidad XF es muy potente para la epoca en la que salio y me atreveria que es superior a la de las unidades contemporaneas de la época en PC. No se puede realizar la comparación directa con la VU1 de PS2 desde el momento en que no sabemos cuantos ciclos tarda la GX GPU en realizar la etapa geométrica al completo, pero la cifra que Nintendo da en el SDK es de 32.400.000 polígonos por segundo transformados sin ninguna fuente de luz aplicada sobre la escena (unos cinco ciclos). Hay que tener en cuenta que esto son cifras de la etapa geométrica y no de todo el pipeline gráfico. La particularidad es que la potencia del motor geométrico parece ir bajando a medida vamos añadiendo fuentes de luz adicionales hasta un límite 8 fuentes de luz, pero esa limitación hace referencia más bien a la tasa de relleno.

El XF se encarga de aplicar la iluminación de la escena a nivel de vertice manipulando el valor de color de cada vértice, el cual afectará el valor de color de la textura cuando se realice la étapa de texturizado. Puede aplicar hasta 8 fuentes de luz por escena y consume 4 ciclos adicionales aparte de los 5 ciclos de transformación por fuente de luz. Por lo que el ratio de la unidad XF sería el siguiente:

No obstante no podemos olvidar que estas cifras no son los polígonos que se dibujan en pantalla sino las tasas de la unidad geométrica que son enviadas al Triangle Setup/Rasterizador

Pero la unidad geometrica no puede presentar nada en una pantalla 2D porque entiende el mundo en 3D, por lo que necesita como mínimo una unidad de rasterizado y he aquí la vergüenza de la familia y el enorme cuello de botella en la GX GPU. Su unidad de rasterizado es tan lenta que tarda uno 16 ciclos de reloj y llega a poco más de los 10 millones de triangulos rasterizados por segundo. Obviamente pocos juegos se acercaban a esa cifra en Gamecube pero en Wii que Nintendo no intentase renovar dicha unidad clama al cielo porque es el mayor factor limitante y sobretodo teniendo en cuenta las capacidades del NV2A de Xbox. Para que os hagáis una idea aproximada, la unidad de rasterizado de la GX GPU es peor que la de una GeForce pese a que la capacidad de calculo de la XF esta por encima de la de la GeForce 2.

Fuentes de Luz	Polígonos
0	32.400.000
1	18.000.000
2	12.500.000
4	7.715.000
8	4.379.000

No obstante no es mala del todo desde el momento en que dispone de la capacidad de realizar Hidden Surface Removal por hardware, esto significa la eliminación de las superficies no visibles utilizando como refencia la posición de los objetos en el Z-Buffer para evitar el overdraw. Es muy posible que sea esta función la que haga que el rasterizador sea más lento a la hora de transformar la geometria, pero al contrario del HSR en los PowerVR hemos de tener en cuenta que Gamecube no es un middle-sort y para que sea efectivo el juego ha de renderizar de adelante hacía atrás y no todos los juegos lo hacen.

El tema es que en Gamecube dicha limitación es circunstancial, dado que el 99% de los juegos de la generación están por debajo del limite y que el XF funcione de manera cuasi automática permite sacar escenarios con mucha carga poligonal para la época muy facilmente. La capacidad HSR en el rasterizador evita que las unidades de texturas no tengan que calcular fragmentos no visibles.

El rasterizador escribe durante la fase de rasterizado el Z-Buffer en el eFB utilizando las unidades C/Z que son los 4 ROPs del sistema, en el diseño inicial del Aladdin7 ArtX utilizo solo 2 ROPS pero en Gamecube y por influencia de la aparición de la primera GeForce con 4 ROPS duplicaron esa cifra. Obviamente el color de lo pixeles no se calcula en la etapa de rasterizado sino en la de texturizado.

La tercera etapa y última es la etapa de texturizado. Tenemos 4 unidades de texturas unificadas en una sola unidad con una unidad TEV (Texture Environment) haciendo de Color Combiner y 1MB de memoria embebida con un bus interno de 512 bits. Dicha memoria embebida funciona diferente a la de PS2 desde el momento en que se comunica directamente con un bus de 10,368 GB/s (es una coma, no un punto, fijaos bien) lo que le permite tener una tasa de texturizado con 16 bits de color por pixel de 648 Mtexeles/s, es decir sin perdidas de rendimiento, aunque con color de 24 bits no puede hacerlo bajo la misma tasa de texturizado y esto provoca que muchos juegos sufran de Dithering debido a la precisión de color limitada en la consola.

La unidad TEV por otro lado es un Color Combiner que ha evolucionado del de N64, al contrario de lo que pasa con el de Xbox no podemos hacer operaciones con dos texturas porque cada unidad de texturas solo maneja una textura por ciclo, esto significa que al igual que en N64 cada vez que se añade una textura/operando se recorta la tasa de relleno, al contrario que en N64 soporta el limite de 8 del OpenGL y no se queda solamente en 2, aparte que añade una serie de instrucciones adicionales.

• Una Instrucción de Comparación que es esencial para las instrucciones de salto.
• Instrucciones de salto.

No obstante las intrucciones de salto son sumamente inutiles en este tipo de unidades y esta de más. El tema es que la tasa de texturizado se reduce al igual que pasa en PS2 por cada nuevo mapa de texturas sobre el fragmento o por cada nuevo operando y el Vertex Color heredado también cuenta como operando.

Si tenemos en cuenta el ratio Dreamcast (32 pixeles por poligono) tenemos las siguientes tasas teóricas:

Texturas/Luces/Ops	Fillrate	Fragmentos
1	648,0	20,3
2	324,0	10,1
3	216,0	6,8
4	162,0	5,1
5	129,6	4,1
6	108,0	3,4
7	92,6	2,9
8	81,0	2,5

El problema es que el rasterizador no puede enviar más de 10 millones de poligonos y por eso eso es una tontería texturizar con solo 1 textura por fragmento porque no da ventajas de rendimiento y es por ello que los juegos suelen empezar con multitexturax2 aunque también hay excepciones.

Aparte del TEV existe otra unidad llamada EMBM que se encarga de realizar efectos de Environment Mapping y Bump Mapping combinados (tipo Emboss no Normal Mapping) pero dada la limitación a una textura por ciclo y unidad de texturas reduce también la tasa de relleno. Este es el motivo por el cual Super Mario Sunshine redujese de su versión beta a la versión final su tasa de fotogramas a la mitad al incluir este efecto.

En la imagen podéis ver el efecto de Dithering por la limitada precisión de color.

El siguiente tema es la compresión de texuras, la consola puede descomprimir texturas en formato S3TC/DXTC al vuelo, no es que la consola soporte DirectX sino que la compresión de texturas de la empresa S3 fue adoptada por Nintendo, dicha compresión de texturas ofrece un ratio de 2:1 para texturas de 8 bits, 4:1 para texturas de 16 bits y 6:1 para texturas de 24 bits. Esto significa que el eTM virtualmente puede almacenar hasta 4MB de texturas de la escena en un atlas de texturas. En realidad Gamecube no soporta texturas de más de 512×512 pixeles de tamaño, lo cual es extraño si tenemo en cuenta que las GPUs contemporaneas a la GX GPU soportaban texturas de hasta 2048×2048 en tamaño pero en si mismo es una paradoja. La gran mayoria de sistemas de la época tienen una limitada cache de texturas que hace que esas increibles texturas tengan que fraccionarse, Gamecube tiene acceso a toda la textura de manera directa, lo cual es producto de la sobrecomplicación del hardware.

Hay que tener en cuenta que el funcionamiento en Gamecube es distinto al de PlayStation 2 pese a tener ambas memoria embebida por la lentitud del rasterizador de la consola de Nintendo. En el caso de PlayStation 2 se envia la geometria ya calculada varias veces y las texturas, en el caso de Gamecube solo se envia una vez y las texturas que se van a utilizar para lo efectos de multitextura de la escena se pueden cargar directamente en la eTM. Obviamente es posible realizar streaming desde la RAM principal pero al estar la eTM tan cerca es mucho más eficiente ya que el tiempo de busqueda de los datos es menor.

Tened en cuenta que Nintendo heredo el diseño de la MX que le estaba haciendo CagEnt/3DO como base de la arquitectura de Gamecube y dicho diseño ya tenía memoria embebida, no es que a Nintendo por ver el Graphics Synthesizer se le ocurriese implementarlo. Más bien fueron las especificaciones finales de PlayStation 2 lo que permitio a ArtX concretar las capacidades de la consola y su potencia bruta. Aunque Gamecube se diseño de inicio como consola para batir a Dreamcast las especificaciones de PS2 retrasaron el proyecto un año para añadir mejoras como un TEV mejorado, el uso de memoria 1T-SRAM y el soporte para compresión de texturas S3TC.

La cuarta y última etapa en gráficos es el dibujado del bufer de imagen, por temas de espacio y coste la memoria embebida no permite el Front Buffer y la imagen final se ha de copiar en la RAM principal desde el eFB, la RAM principal es referida como XFB.

Y lo siguiente es un mapa de las dos secciones del eFB, una para color y la otra para Z.

El eFB tiene dos bufers de 640×528 pixeles en total que soportan hasta 8 bit por componente en RGB, si en una textura utilizamos formato RGBA entonces pasa a ser 6 bits por componente.

Por lo que el sistema soporta sin problemas color de 24 bits y Nintendo en el texturizado solo tendría que haber aumentado el ancho de banda para evitar el Dithering. Por otro lado esto significa que la consola no puede soportar dicha resolución y ha de tirar del xFB (y por tanto utilizar la RAM principal) si quiere hacer SSAAx2 manteniendo la resolución o reducirla a la mitad.

Ambos modos no pueden pasar de los 640 pixeles en horizontal. No olvidemos que estamos hablando de una consola pensada para televisor de tubo donde solo se podían alcanzar los 60hz con una resolución de 262 lineas, pero algunos televisores de la época eran capaces de soportar escaneo progresivo a 60hz… Para ello en Gamecube era necesario un cable especial.

Nintendo en Wii elimino la salida analogica y dejo solo la digital…

#6 Wii

Aunque Wii la hemos ido tratando por encima se ha de tener en cuenta que la consola nacio como un re-diseño aprovechando el paso del nodo de 180nm a 90nm, lo que permite reducir en teoría la densidad a 1/4 parte y aumentar la velocidad de los componentes un 50%. Nintendo no solo aprovecho para aumentar la velocidad sino además añadir una serie de componentes adicionales como es la unidad Bluetooth para el Wii Remote y una unidad WiFi para conectar la consola online, para ello Nintendo sacrifico los dos puertos de expansión de Gamecube utilizados por el modem y el Game Boy Player.

En general sus especificaciones son:

• IBM Broadway a 729Mhz. El Broadway es el mismo chip que el Gekko pero fabricado a 90nm en vez de 180m.
• LSI Hollywood: El sustituto del LSI Flipper, incluye la GX GPU a 243 Mhz sin cambio alguno en su arquitectura y manteniendo los 3MB de memoria embebida
• Se mantienen los 24MB de memoria 1T-SRAM, ahora dentro no del mismo chip pero si del mismo encapsulado que el LSI.
• La memoria A-RAM ha sido sustituida por 64MB de memoria DDR2 de 64 bits a 243Mhz.
• Incluye 512MB de memoria NAND Flash y un lector de tarjetas SD.

Su arquitectura es exactamente la misma que la de Gamecube pero con un 50% de velocidad adicional.

Nintendo le cambio el diseño industrial a la consola que inicialmente iba a ser una versión Lite/Slim de la Gamecube original y el Wii Remote ir como accesorio para esta.

El otro añadido fue una interfaz de arranque donde poder ejecutar las diferentes aplicaciones en memoria, la mayoría ROMs de la consola virtual o ejecutables del Wiiware, o acceder directamente al disco.

Paradojicamente pese a ser inicialmente planteada como una versión Lite/Slim el éxito de Wii en el mercado como todos sabréis fue enorme pero no es motivo de esta entrada.

Y con esto termino esta entrada, teneis el Discord y lo comentarios de la entrada para comentar