Hola Urian. En estos días me pasé por el otro blog y me topé con los artículos de «what if». Me gustaría un what if de la vieja Wii donde Nintendo hubiera hecho un hardware un poco más potente por el mismo precio de salida y con retrocompatibilidad. Saludos!

Me parece un reto interesante, por lo visto tenemos que:

  1. Hacer una consola que sea más potente que Wii.
  2. Compatible hacía atrás con GameCube al igual que Wii
  3. Que este por el mismo precio de salida.

A esta hipotética consola la voy a llamar «GameCube 2» o GCN2 para no confundirla con Wii y no se basaría en el control al estilo Wiimote sino con un estilo completamente tradicional pero dado que el sistema ha de ser compatible hacía atrás hay ciertas limitaciones a la hora de diseñar el sistema y en la elección de los componentes.

Northbridge y RAM

El Northbridge es la unidad encargada de gestionar los accesos a la memoria de los diferentes procesadores y la comunicación entre ellos. En las consolas de Nintendo se suele encontrar en el mismo chip que la GPU, el DSP para el sonido y los controladores de E/S. Hay que tener en cuenta que en todas las consolas de Nintendo desde GameCube la CPU no tiene acceso directo a la RAM sino que esta conectada al Northbridge que se encuentra en el chip que engloba el resto de procesadores.

gamecube_motherboard

Aquí la arquitectura sería similar pero todo depende del ancho de banda de la memoria utilizada. En Wii Nintendo mantuvo la RAM de GameCube dentro del mismo encapsulado que el LSI Hollywood (el chip que engloba GPU, Sonido y E/S) y la llamo «Internal Memory» o MEM1.

hollywood_dies

Como véis esta MEM1 no se encuentra conectada a la CPU pero no es la única memoria en el caso de Wii, hay un segundo pozo, un chip GDDR3 a 243Mhz y 64 bits que es conocida como MEM2 o «External Memory».

d2c_dvd_drive_for_wii_d2a_d2b_d2c_d2e_dms__634572649849370472_1

El ancho de banda de la MEM1 y la MEM2 es el mismo, unos 3.9GB/seg aproximadamente… Es más, la inclusión de la MEM1 me parece un disparate por el hecho que viene de la obsesión de Nintendo por la latencia después de los problemas que hubo con Nintendo64, problemas que otros sistemas utilizando un esquema similar (como la primera Xbox) no tuvieron por lo cual lo mejor sería colocar una configuración de 64 bits GDDR3 a 600Mhz (9.6 GB/seg) y eliminar la MEM1 en nuestra GCN2 dejando un solo pozo de memoria de 128MB en el sistema con tal de facilitar el desarrollo en los juegos y que los desarrolladores no tengan que trabajar con dos pozos de memoria distintos.

CPU

El primer cambio importante sería en la CPU que llevaría un PowerPC 970 modificado en su interior en vez del PowerPC 750, comparativamente el salto en cuanto a la CPU sería el siguiente:

PowerPC 750 (GameCube) PowerPC 970N
ALUs Enteros 2 2
ALUS Coma Flotante 1 2
ALUs SIMD 2 (Integradas en la FPU/Paired Singles) 4 (Integradas en las FPUs/Paired Singles)+1 UnidadVMX
Instrucciones ciclo 2 5
Velocidad de reloj 486 Mhz 2 Ghz
DMIPS 1128 DMIPS 5980 DMIPS
GFLOPS 1.94 GFLOPS 24 GFLOPS.

El PowerPC 970N sería una versión modificada del 970/G5 para Nintendo manteniendo la compatibilidad hacía atrás con el PowerPC Gekko de GameCube.

Sonido

Pese a que sería posible igualar las capacidades del sistema de sonido de la primera Xbox, por temas de compatibilidad hacía atrás se mantendría el sistema de sonido de GameCube.

E/S y Almacenamiento

Eliminaría los cuatro puertos para mandos de GameCube de Wii, a cambio haría una versión nueva del mando de GameCube con conexión Bluetooth para comunicarse con la consola. En Wii los dos puertos de expansión de GameCube son utilizados para el Bluetooth y el WiFi, aquí los usuaria para lo mismo, también conservaría los dos puertos para tarjetas de memoria de GameCube pero no añadiría el lector de tarjetas SD pero mantendría la NAND Flash interna pero no de cara al Wiiware o la Consola Virtual, en vez de ello lo utilizaría solo para grabar partidas en nuestra GameCube 2.

En cuanto al lector, la unidad DVD sería del mismo tiempo que en Wii, disco de 12cm de diametro con doble capa, dicho esto el diagrama general del sistema quedaría de la siguiente manera:

gcn2diagramic

Por el momento tenemos el diagrama incompleto y nos falta hablar del procesador gráfico que es donde vamos a realizar la gran mayoría de los cambios para ello es importante hablar de entrada de la unidad que se encarga de «planificar» como se van a ajecutar las cosas en la GPU, me estoy refiriendo al procesador de comandos, el cual tendria algunos cambios respecto a la GameCube original. El procesador de comandos sería por tanto una extensión del de GameCube añadiendo nuevas instrucciones y funciones para la versión extendida de la API GX la cual soportaría Vertex Shader y Pixel/Fragment Shaders pero sin romper la compatibilidad hacía atrás.

Puede funcionar en dos modos distintos:

  1. Modo GX: Cuando reproduce juegos de GameCube
  2. Modo GX++: Cuando reproduce juegos de GameCube 2

Cada uno  de los modos utiliza un camino de datos distinto de la GPU, por compatibilidad hacía atrás la GPU de nuestra supuesta GameCube 2 hace uso de las unidades originales de GameCube pero en modo GX++ las desactiva y hace uso de otro camino de datos distinto, pero ambos caminos de datos quedan definidos en el siguiente diagrama:

gcn2gpugeneraldiagram

En realidad fuera de los elementos conservados para la compatibilidad hacía atrás se trata de una GPU completamente nueva, en todo caso no voy a comentar dichas unidades y tampoco el pipeline de Gamecube (en violeta en el diagrama), a partir de aquí voy a definir los distintos elementos.

#1 Vertex Shader

La idea es alcanzar como mínimo el nivel visual de la primera Xbox, el cual nos permitiría poder ejecutar juegos en esta Wii alternativa como Doom 3, los cuales por limitaciones del hardware no son posibles ni en GameCube ni en Wii, siendo una de esas limitaciones la falta de Vertex Shaders.

doom-3-image202098

¿Que potencia nos podemos esperar para una consola low cost de 2006? Creo que no es una exageración pedir que la consola pueda mover los juegos que la Xbox original movía a 30fps a 60fps sin perdidas de ningún tipo, para ello hacen falta unas 4 unidades Vertex Shader funcionando a 243Mhz, con ello de entrada el salto a nivel visual sería considerable ya de entrada. Es decir, la idea es utilizar cuatro unidades Vertex Shader con la capacidad de las de la primera Xbox.

¿Diferencias respecto a GameCube? La unidad de transformación de GameCube puede transformar con una sola fuente de luz pero sin texturas unos 32.4 millones de triangulos por segundo sin coordenadas para texturas que se reduce en unos 27 millones si añadimos las coordenadas para las texturas posteriores. A partir de ahí cada textura o cada fuente de luz adicional son 4 ciclos más. Los Vertex Shaders del NV2A en cambio son un poco más rápidos, tarda unos 5 ciclos en colocar una fuente de luz con una textura y como tenemos 2 unidades a 233Mhz la cifra acaba siendo de unos 90 millones de poligonos/segundo aunque luego el sistema tiene un cuello de botella en la tasa de relleno que no le permite utilizar esa cifra es completamente igual ya que tarda 1 ciclo menos para realizar sus operaciones que la unidad de transformación de GameCube y tiene margen de sobras.

Colocar 4 Vertex Shader con la capacidad de cálculo del NV2A de Xbox, es decir, duplicar la capacidad de la primera Xbox no sería raro para nuestro What If y tampoco una imposibilidad en pleno 2016 haciendo uso de un proceso de 90nm. Dado que AMD/ATI sería la socia lo mejor sería adaptar la capacidad de los Vertex Shaders de las arquitecturas basadas en el R300 (al fin y al cabo son dos diseños de la misma gente)

vertexengine

Gracias a esto la GPU de GameCube 2 iría más allá de la de Xbox al soportar el Shader Model 2.0 y con ello la primera versión de DX9, el ideal sería que pudiese soportar el DX9c y por tanto no habría problemas para convertir de manera «light» buena parte de los motores que habría en PS3 y 360, obviamente la capacidad en potencia no sería la misma pero el coste de realizar los ports se reduciría de manera importante.

#2 Rasterizador

El Rasterizador sería uno de los elementos que se verían mejorados respecto al de GameCube, el cual era uno de los mayores cuellos de botella que tenía su GPU ya que solo podía rasterizar un triangulo para convertirlo en fragmento en 16 ciclos, es decir… La tasa máxima de fragmentos que llegaba a las unidades de texturas era de 10 millones, algo que para la época no era problemático pero ya que tenemos una unidad geométrica más potente no es plan de dejar el rasterizador tal cual y que sea un cuello de botella aún mayor.

El mayor candidatos sería el rasterizador de ATI de aquella época, capaz de generar un triangulo por ciclo de reloj, una bestía parda que también fue heredada por la GPU de Xbox 360.  Con una unidad así es más que suficiente para una consola de este tipo y el cuello de botella se encontraría realmente en las tasas de relleno de las unidades de texturas y de los ROPS.

#3 Unidades de Textura y Memoria Embebida

Con tal de ahorrarse una interfaz de memoria más ancha GameCube utiliza memoria embebida para el búfer de imagen pero la memoria para las texturas es una memoria aparte de dicha memoria y se aprovecha su ancho de banda para poder realizar el filtraje de texturas, necesitando unos 4 ciclos para el filtro bilineal y unos 8 ciclos para el trilineal, siendo la regla de los ciclos universal.

flipper_die

Las memorias embebidas suelen estar conectadas en matriz en vez de forma lineal, en el caso de la eTM dicha memoria embebida tiene un bus de 512 bits donde hay conectados unos 16 bloques  con un bus de 32 bits cada al TF, TC y al TEV. El TEV no nos interesa pero el TF y el TC si que nos interesa y es que la GPU de GameCube tiene una unidad de texturas algo peculiar capaz de trabajar con 4 texturas simultaneas por ciclo y que se comunica utilizando una matriz de 512 bits (16×32) con la memoria embebida por lo que esto le permite tener el suficiente ancho de banda para que la consola no pierda su tasa de relleno utilizando filtro trilineal y 16 bits pero aún esto supone un cuello de botella desde que la consola soporta 24 bits de color y la memoria embebida no da el suficiente ancho de banda. La unidad de texturas en GameCube 2 sería cambiada por una capaz de soportar color de 32 bits y su comunicación con la memoria embebida se duplicaría en ancho de banda para poder dar soporte a texturas de 32 bits sin que la tasa de relleno se viese perjudicada y con ello mejorar la capacidad visual en los juegos en el modo GX++, nada de texturas de mala calidad en 16 bits, con este cambio el nivel visual de entrada ya sería mucho mayor que el que Nintendo consiguió en GameCube.

Dado que en el SDK de Gamecube se nos habla de 27 millones para poligonos con una sola textura eso significan unos 24 pixeles (el tamaño de un poligono es variable) con una tasa de relleno de 648 millones, pero con 24 bits la tasa de relleno utilizando trilineal se reduce enormemente:

162*64 bytes (512 bits)= 10368 MB/s

(10368 MB/s)/(3 bytes de color*8 ciclos para trilineal)= 432 Mpixeles= 18 millones de poligonos por segundo.

En cambio con los cambios que hemos realizado:

243*128 bytes (1024 bits)= 31104 MB/s

(31104 MB/s)/(3 bytes de color*8 ciclos para trilineal)= 1296 Mpixeles = 54 millones de poligonos por segundo.

¿Como se compara esto con la primera Xbox? Bueno, la primera Xbox no tiene el suficiente ancho de banda para trilineal en un ciclo por lo que la potencia sería la mitad, unos 25-26 millones fragmentos texturizados por segundo.

#4 Pixel Shader

Al igual que ocurre con las unidades Vertex Shader aquí el ideal sería que estuviesen al nivel del DirectX 9c, gracias a ello se podrían portar una gran cantidad de motores de juego y realizar una serie de ports o spin-offs por un coste pauperrimo en comparación con hacer juegos para Wii que además se verían mucho mejor. Lo mejor sería utilizar los Pixel Shader de la arquitectura R5xx ya que se pueden conectar hasta unas 3 unidades Pixel Shader por unidad de texturas y cada una de ellas con la capacidad de realizar hasta 8 operaciones por ciclo. Dicho de otra manera la capacidad podría ser de hasta 24 GFLOPS en lo que a los Pixel Shaders se refiere pero… ¿Cual sería el nivel de calidad visual que nos podriamos esperar en esta hipotética consola? Pues tendría la potencia de una PS Vita, lo cual no es algo de lo que avergonzarse para una consola low cost de 2006.

#5 ROPS y Framebuffer Embebido

Xbox 360 separa el Framebuffer embebido del resto del chip para disminuir los costes de fabricación del chip.

xenos

De tal manera que en la consola de Microsoft la cosa queda de la siguiente manera:

xenosedram

Los ROPS y la eDRAM se encuentran dentro de la Daughter Die, los 256 GB/seg son por el siguiente calculo:

500 Mhz*8 ROPS*4 bytes de color*2(Color+Z)*2(Lectura+Escritura)*4 Muestras= 256 GB/seg

Es decir, el ancho de banda es ideal para el renderizado en diferido, algo que en GameCube no estaba y algunos motores de GameCube 2 podrían soportar o más bien la GPU debería estar pensada para ello. Por lo que en el caso que nos ocupa la cifra sería:

243 Mhz*4 ROPS*4 bytes de color*2(Color+Z)*2(Lectura+Escritura)*4 muestras= 62 GB/seg

Pero el tamaño de la memoria embebida sería también importante, hay que tener en cuenta que esta tanto en Xbox 360 como en GameCube almacena solo el búfer trasero y no el delantero, pero aún así hemos de tener en cuenta que una GPU al nivel DX9c/OpenGL 2.0 tiene que soportar hasta 4 Render Targets, esto son unos 4 búfers de imagen completos. En GameCube el búfer de imagen tiene la siguiente carácteristica:

wiifb

528 porque el número máximo de lineas en NTSC son 528 lineas, no queremos que la consola soporte resoluciones HD pero si el modo panorámico y 32 bits de color por lo que la resolución sería de 854×528 y tendríamos 4 búfers de imagen (1 por cada muestra) y unos 32 bits de información por pixel en cada búfer (Color o Z+Stencil ya que el Stencil no es soportado por GameCube y también es esencial) por lo que la densidad de la memoria sería:

854*528*4*4=7MB

La cifra es muy alta y lo mejor sería dejar la memoria embebida fuera pero en el mismo encapsulado. Una de 8MB sería de sobras para dicha tarea.

Con esto terminamos el diseño de la hipotética GameCube 2, la cual nunca salió pero de haber hecho Nintendo una consola compatible hacía atrás con un hardware trabajado y sin traicionar el concepto de no hacer una consola HD lo mejor que podrían haber hecho sería un sistema como el descrito en esta entrada.