Re-Construyendo Nintendo NX (Entrada Desfasada)

Esta entrada va a ser larga, es una versión resumida y rehecha de la serie Construyendo Nintendo NX. Tengo que aclarar que ya no sostengo lo dicho en esta entrada, pero la dejo como un buen ejercicio de especulación técnica.

expired blue vintage rubber stamp on white

En primer lugar, durante las tres últimas generaciones de consolas Nintendo hemos ido viendo una curiosa evolución en lo que a la memoria se refiere:

gc-mobo-small

Gamecube tenía la MEM1, unos 24MB de memoria 1T-SRAM dentro de la placa base de la consola, Wii en cambio…

hollywood_dies

Coloca en el mismo encapsulado, encima del mismo sustrato pero en diferente chip tenemos a la MEM1 en Wii. La evolución definitiva ya se dió en Wii U donde la MEM1 paso a formar parte del interior del chip.

El uso de la memoria embebida dentro del chip tiene sentido en un entorno estilo OpenGL 1.x, que es por donde se movió Nintendo durante años con el hardware de GCN y Wii en sobremesa y se mueve actualmente con 3DS en portátiles.En estas consolas se opera directamente sobre el backbuffer y es por ello que el ancho de banda de la memoria es crucial, pero en  los tiempos actuales la cosa ya no es así.

Hoy en día los cuellos de botella se encuentran en los shaders y/o cuando es necesario coger datos de memoria y estas etapas se encuentran más atrás respecto a los ROPS en lo que al renderizado se refiere. Por si fuera poco todo se esta moviendo de forma progresiva hacia el uso de Compute Shaders en detrenimiento de los Pixel/Fragment Shaders. Siendo la diferencia entre un Pixel Shader y un Compute Shader bastante simple, el uso de los ROPS. El Pixel Shader escribe el resultado sobre la memoria a través de los ROPS, el Compute Shader hace bypass de estos para escribir en memoria o en su defecto escribe en la cache L1 el resultado para que un hilo de ejecución que viene a posteriori pueda tomar los datos sin acceder a la memoria externa y tener que recuperarlos.

En el caso de New 3DS el aumento de la eDRAM tiene sentido en su contexto de renderizado ya que su GPU el PICA200 es del tipo OpenGL ES 1.1, en el caso de realizar una consola con una GPU al nivel DX11/OGL4 por parte de Nintendo la memoria embebida dejaría de tener total sentido práctico.

El ejemplo de ello es Xbox One, consola que pese a tener memoria embebida no puede evitar tener que depender de un bus de cuatro canales DDR3 con 16 chips de memoria en la placa base, lo que derrota por completo el proposito de la memoria embebida que no es otro que el de reducir los costes y la complejidad de la placa base del sistema reduciendo los chips de memoria en la misma.

Captura de pantalla 2015-04-17 a las 11.35.26

Las memorias embebidas dado que están dentro del chip permiten interconexiones en matriz que ocupan mucho menos espacio que las interconexiones seriales por lo que disminuyen enormemente el número de pins externos (que marca el tamaño del chip) y de la enorme cantidad de memoria conectada a dichos pins externos. ¿Desventajas de la memoria embebida? Su poca densidad y el hecho que resulte un engorro para los desarrolladores tener que lidiar con dos niveles de memoria distintos.

El hecho de que Nintendo haya utilizado memoria embebida es lo que ha permitido que sus consolas utilizarán siempre un bus de 64 bits con la memoria externa,  desde… ¡GameCube hasta Wii U! ¿La memoria externa? En Gamecube era una SDRAM muy lenta para hacer de búfer de datos y para almacenar el sonido que la llamaron A-RAM (Auxiliary RAM), en Wii la cambiaron por memoria DDR2 de 64 bits a 243Mhz y en Wii U paso a ser de DDR3 a 800Mhz y también con un bus de 64 bits.

Imaginemos por un momento que Nintendo decide no optar por cosas como la memoria HBM y en vez de ello opta por el camino tradicional que es memoria estándar de PC bajo un bus de 64 bits, por timing tocaría la DDR4, esto significaría pasar de los 12.8 GB/seg a solo 25.6 GB/seg para la memoria principal, lo cual es una cifra enormemente pauperrima y crearía enormes cuellos de botella ya que la GPU cuando no encontrase un dato en la memoria embebida lo tendría que ir a buscar en la LEEENTAA DDR4. Precisamente una cosa que no sabe la gente sobre Wii U es que la configuración de su GPU en cuanto al número de Shaders esta directamente relacionada con el ancho de banda de la memoria externa,

Captura de pantalla 2015-04-17 a las 11.46.49

Captura de pantalla 2015-04-17 a las 11.46.11

El RV740, la única GPU lanzada en PC bajo el proceso de 40nm y perteneciente a la serie R700 de AMD tenía una configuración de 640 unidades shader para 51.2 GB/seg de memoria, la DDR3 de Wii U da un ancho de banda de 12.8 GB/seg, por lo que hay una relación entre el número de Shaders y el ancho de banda. Precisamente este es el motivo por el cual Microsoft ha tenido que colocar la DDR3 más rápida posible y con cuatro canales (256 bits) en Xbox One para evitar picos de rendimiento.

El caso es que es una tontería tener dos pozos de memoria distintos, hoy en día que las GPUs ya soportan direccionamiento de memoria unificado tanto por parte de AMD…

HSA-HUMA-04

… como por parte de Nvidia.

UniMem

Así que la tendencia va directamente hacía un solo pozo de memoria y no dos, dicho pozo ha de cumplir dos requisitos: Densidad y Ancho de Banda. No quiero lanzar sal a la herida pero soy de los que piensa que cuando Sony anuncio los 8GB GDDR5 en PS4 en Microsoft estaban así:

Scared manager

La ESRAM existe porque la DDR3 no puede dar el suficiente ancho de banda a los ROPS como para poder mantener la tasa de relleno:

HumuseDRAM

Como no daba suficiente ancho de banda la DDR3 se acabo añadiendo la ESRAM, pero estoy seguro que si Microsoft hubiese tenido la DDR4 disponible en el mercado y en gran volumen no hubiésemos visto el uso de la ESRAM. Claro esta que en la entrada hablamos de Nintendo cuyo objetivo con la memoria embebida es reducir el número de chips de memoria en la placa.

¿Pero que ocurre cuando tienes disponible en el mercado una memoria que tiene la ventaja de reducir los chips de memoria externa de la eDRAM y sin los problemas de densidad de esta ?Pues que la eDRAM deja de tener sentido, y si a esto le sumamos el hecho que el direccionamiento de memoria se esta unificando y por tanto la separación entre MEM1 y MEM2 que ha utilizado Nintendo hasta ahora nos encontramos en que la memoria HBM es la mejor solución posible en el planteamiento que tiene Nintendo.

¿Pero como funciona dicha memoria? El estandar HBM JESD235 apila cuatro chips de DRAM con dos canales de 128 bits por chip en una chip lógico como base, lo que supone un dispositivo de memoria de 1024 bits de ancho de banda. En la siguiente diapositiva se ve mucho mejor:

sk_hynix_hbm_dram_3

Cada canal es similar a la interfaz DDR, pero es completamente independiente y por lo tanto cada canal en cada pila e incluso dentro de cada chip de la pila puede operar a una frecuencia diferente, tener timings distintos… Cada canal soporta capacidades entre 1Gb y 32 Gb, puede tener entre 8 y 16 bancos además de que puede operar a unos ratios desde 1Gb/seg por pin hasta 2Gb/seg por pin. Como resultado, un chip completo de memoria HBM puede ir desde 1GB hasta los 32GB/seg de densidad y puede colocar su ancho de banda entre los 128GB/seg y los 256GB/seg. Todo ello permite reducir enormemente el número de chips en la placa base así como la energía generada por los mismos.

Captura de pantalla 2015-04-17 a las 12.08.37

El esquema habla de chips de memoria HBM a 1Ghz, pero el hecho que estos consuman 3.5W cada uno de ellos, la reducción del tamaño de la placa y del número de chips de memoria es algo que va en consonancia con la forma en la que Nintendo diseña sus consolas, placa bases pequeñas con pocos chips de memoria y consumo bajo. Por cierto si os preguntáis que significa el acrónimo CoWoS significa Chip on Wafer on Substrate. Se refiere al sustrato (de color blanco en la imagen) que se encarga del cableado entre los diferentes chips.

Del primer procesador que se tiene constancia que utilizará este nuevo estándar es el Nvidia Pascal aunque antes en el mercado aparecerá el AMD Fiji.

nvidia-pascal-gpu

Como véis la GPU esta montada sobre un sustrato (de color verde) con cuatro chips HBM al lado, por lo que se trata de un dispositivo que puede ir desde los 512GB/seg hasta 1TB/seg de ancho de banda en el caso del de Nvidia. ¿Pero realmente hará falta una GPU con un ancho de banda tan potente? Ni mucho menos, dado que las GPUs son dependientes en rendimiento del ancho de banda una misma gama ira escalando según el número de chips HBM que tenga al lado y por tanto con el ancho de banda tal y como ha ocurrido hasta ahora.

Claro esta que para competir contra Xbox One y PS4 como mínimo el sistema necesita unos 8GB de densidad de memoria, en el caso de la memoria HBM de primera generación tenemos una densidad de 2Gb por chip de la pila, lo que dan unos 8Gb o 1GB y harían falta 8 chips, en el caso de la memoria HBM de segunda generación la cosa se va a los 8Gb por chip de la pila, haciendo un total de 4GB por chip y permitiendo que en una configuración de dos chips HBM se llegue a los 8GB de de densidad.

HBM

El otro tema es la CPU, en Gamecube y Wii la CPU se encontraba en la placa base, pues bien, la evolución en Wii U fue la siguiente:

MCM_WiiU

La siguiente evolución lógica es colocar la CPU dentro del chip.

Obviamente después de más de diez años utilizando el PowerPC 750 se necesita un cambio urgente por una arquitectura completamente distinta y más si tenemos en cuenta que este ha sido uno de los talones de aquiles de Wii U.

En primer lugar, IBM que fue el diseñador de estos chips carece ya de su división de microprocesadores ya que se la vendió a Digital Foundry y la empresa jamás ha tenido interés por el mercado de los SoCs domésticos por lo que no hay ninguna tecnología que Nintendo pueda utilizar de cara a integrar la CPU dentro del mismo chip. En segundo lugar el tema del direccionamiento de memoria unificado que he comentado antes, algo con lo que se esta trabajando de cara a arquitecturas con procesadores x86-64 y ARMv8, y la arquitectura PowerPC queda completamente fuera de todo esto.

El chip más grande en área que ha sacado Nintendo en su historia es el Latte de Wii U con unos 147mm^2 de área, suponiendo que suprimimos la eDRAM de dentro del Latte e integramos la CPU en su lugar y como CPU escogemos dos modulos AMD Jaguar como en PS4 y Xbox One entonces podemos hacer una simple regla de tres. En PS4 los dos módulos ocupan un 15% de los 348mm^2 y eso son unos 52.2 mm^2 en total para la CPU dejando para el resto de componentes dentro del SoC unos 94.8mm^2, tened en cuenta que estoy siendo altamente conservador en lo que al tamaño del chip se refiere y al proceso de fabricación (28nm). Vamos, que estoy tirando MUY A LA BAJA.

El tercer tema es la GPU… la gran mayoría de juegos de Nintendo en Wii U funcionan a 720P30, hay que tener en cuenta que las GPUs de AMD trabajan con lo que se llaman Wavefronts desde la arquitectura R600 en adelante, ¿Como se define un Wavefront? Es una colección de 64 hilos de ejecución que se almacenan en la GPR (General Purpose Register) y que son enviados a las Compute Units de la GPU donde son operadas en grupos de 16 por ciclo por lo que el tiempo mínimo en solventar un Wavefront son unos cuatro ciclos de reloj. En el caso de Wii U cada una de sus 8 Compute Units podían operar con un solo Wavefront, en el caso de las arquitecturas GCN pueden operar con cuatro Wavefronts al mismo tiempo. La GPR de la GPU de Wii U puede almacenar hasta 192 Wavefronts, en el caso de la arquitectura GCN el número de Wavefronts esta directamente relacionado con el número de CU y el máximo por cada una de ellas es de 40. Dado que l número de Wavefronts aumenta con la resolución y la tasa de refresco que queramos conseguir con el juego, imaginemos que somos un poco conservadores y solo queremos pasar de los 720P a los 1080P, lo que requiere pasar de los 192 Wavefronts en total a los 432 WaveFronts, lo que se traduce en una configuración de 11 Compute Units bajo arquitectura GCN. Obviamente de continuar con la arquitectura de la GPU de Wii U harían falta unas 44 Compute Units para alcanzar un rendimiento similar.

Ahora bien… ¿Cual es el tamaño de cada Compute Unit? Pues unos 6.5mm^2 bajo el proceso de 28nm, esto da unos 72mm^2 aproximadamente para la GPU dejando unos paupérrimos 22mm^2 para:

  • La intercomunicación entre CPU y GPU.
  • Lo controladores de memoria.
  • Los planificadores de hilos de la GPU (dado que las Compute Units solo son las unidades de ejecución).
  • El chip de sonido, el controlador de E/S…
  • Controlador de pantalla.

En general es un imposible colocar todo eso en solo 22mm^2 de procesador. Tened en cuenta que el controlador de pantalla que utiliza AMD en sus APUs/SoC ya ocupa por si solo unos 7.2mm^2. Claro esta que esto es bajo el proceso de 28nm y es muy posible que Nintendo cuando lance la consola pueda optar por un proceso mucho más avanzado donde el área ocupada por cada uno los componentes del SoC sea mucho menor, sí Nintendo opta por el proceso de 20nm para su chip:

  • El doble modulo Jaguar de la CPU pasará de los 52.2 mm^2 a los 26.6mm^2.
  • Cada Compute Unit de la GPU de los 6.5mm^2 a los 3.25mm^2.
  • El Controlador de pantalla al ser una interfaz conectada a un chip externo se mantendra en los 7.2mm^2.

Suponiendo el mismo tamaño del chip estos componentes ocuparían unos 70mm^2 en total, dejando 77mm^2 para el resto de componentes del sistema, lo cual da una viabilidad mayor a la configuración del chip. En todo caso no sabemos cual será el nodo escogido por Nintendo para el procesador de la NX y hay que tener en cuenta que esta entrada es puramente especuladora.

Eso es todo, nos vemos.

Anuncios