Re-Construyendo Nintendo NX (Versión No-HBM)

Captura de pantalla 2015-04-21 a las 19.04.53

La verdad es que tal y como dice Danielno se si Nintendo optará por la memoria HBM o por el contrario tirará por la DDR4 u otro estandar como puede ser la LPDDR4.

Solo digo que a mi la memoria HBM me parece ideal para la forma que tiene Nintendo a la hora de diseñar sus consolas y por el hecho que hemos llegado a un punto donde la utilidad de la memoria embebida esta en entredicho.

¿Pero que ocurriría sí Nintendo no eligiese la memoria HBM? ¿Como sería el diseño del sistema?

En primer lugar tenemos que tener en cuenta es que lo que va a ser un cambió respecto a otras consolas de Nintendo será la integración de la CPU dentro del SoC principal de la consola en vez de ser un elemento separado físicamente, provocando una serie de cambios en la interfaz del mismo.

latte_annotated

En el Latte de Wii U podemos ver como hay un enorme espacio dedicado a la intercomunicación con el bus 60X utilizada por el PowerPC Espresso, con la CPU ya dentro del SoC en el caso de la siguiente consola y moviendonos con unas áreas de procesador similares entonces seria posible aumentar el número de interfaces con la memoria externa, ya sea DDR4 o LPDDR4.

La primera ventaja de esto es que Nintendo podría abandonar el raquítico bus de 64 bits por uno de 128 bits, lo que supondría que el número de chips de memoria en el sistema aumentaría. En la placa base de Wii U se pueden ver unos cuatro chips de memoria DDR3, cada uno de ellos conectado a un bus de 16 bits.

Captura de pantalla 2015-04-21 a las 19.52.49

En cambio en Xbox One que utiliza también memoria DDR3 el número de chips es de 16 por el hecho que su interfaz es de 256 bits.

Captura de pantalla 2015-04-17 a las 11.35.26

El procesador en el primer caso es de 147mm^2, en el segundo es de unos 368mm^2, esto es importante porque aumentar el ancho de banda y la memoria suponen un coste adicional sobre el diseño del sistema.

El motivo por el cual Nintendo utilizaba memoria embebida es muy sencillo, un gran ancho de banda no solo supone una enorme cantidad de chips en la placa base del sistema, supone también que el área del procesador ha de ser grande porque se necesita una enorme cantidad de pines. Estos dos problemas en teoría se solventaban con una memoria embebida para el búfer de imagen.

El problema del ancho de banda es un pez que se muerde la cola ya que los ROPS que son los encargados finales de escribir sobre el búfer de imaten requieren un ancho de banda inmenso para mantener la tasa de relleno (número de ROPS*Velocidad de Reloj de la GPU*Precisión por Pixel). Pero al mismo tiempo el aumento de ese ancho de banda para los ROPS aumenta la latencia de acceso a la memoria por lo que cuando en otras etapas se necesita leer de memoria se acaban creando burbujas que solo se solventan con shaders muy largos y/o haciendo que la GPU no solo realice tareas gráficas sino también otras tareas para aprovechar el rendimiento de la GPU durante dichas burbujas en la que la GPU esta esperando datos.

Debido a que la memoria embebida solo solventa el problema de los ROPS y no solventa el problema de la recogida de datos para las etapas anteriores se acaba convirtiendo en una solución parcial. ¿Acaso no es suficiente con hacer que se pueda leer directamente en la memoria embebida? Bueno, esta tiene un espacio limitado ocupado por los búfers de imagen, el hecho de que en Xbox One y en Wii U se pueda leer es para poder manipular el búfer final para los efectos de post-procesado y a lo que me estoy refiriendo en cambio es a buscar información en la memoria de video para procesarla y hay una alta probabilidad de que los datos no se encuentren en la memoria embebida por lo que al final la GPU tiene que buscar en la memoria externa y como el ancho de banda de esta sea bajo el cuello de botella que se acaba creando es enorme sí el ancho de banda es limitado en su memoria externa.

El mejor truco es crear una cache de texturas que pueda almacenar todos los datos que se van a incluir en el fotograma sin tener que acceder a la memoria externa. Esto significa incluir un pozo de memoria aparte del utilizada para el búfer de imagen para la cache de texturas. Tanto en Xbox One como en Wii U es posible utilizar el búfer de imagen como si fuese una textura y procesarlo directamente desde la memoria embebida sin tener que acceder a la memoria externa.

En realidad solo necesitas un simple pixel texturizado de datos para dibujar un solo pixel en pantalla, por lo que únicamente necesitaras una textura con la misma resolución de pantalla en memoria y nada más, este concepto fue utilizado por Sony y Nintendo en el diseño de PS2 y Gamecube/Wii, en el caso de Microsoft tanto Xbox One como Xbox 360 pese a utilizar memoria embebida nunca han utilizado un pozo adicional para esto. La idea es que si pre-cargas las texturas necesarias de la escena es la memoria embebida no tienes que acceder a la RAM externa desde la GPU y no necesitas tanto ancho de banda de esta, lo que provoca una reducción de las interfaces de memoria y con ello se acaban colocando menos chips de memoria en la placa base reduciendo costes.

Pero lo de Nintendo en Wii U ha ido más allá, tradicionalmente Nintendo separaba fisicamente la VRAM (eDRAM para gráficos) del primer pozo de memoria RAM a la que llamaba memoria interna, en Wii U ambas memorias se han fusionado y esto significa que no solo la GPU tiene acceso a la eDRAM sino también la CPU pero utilizando un direccionamiento de memoria distinto.

No se si os acordaréis del mapa de memoria de Wii U que publico VGChartz hace un tiempo:

 

Tenemos solo 2GB de memoria pero 4GB en direcciones de memoria… ¿A que se debe esto? Pues simple y llanamente que el direccionamiento de la GPU empieza desde la dirección más alta y va disminuyendo, el de la CPU es la inversa. Es por eso que en la litografía anotada por Marcan42 que he puesto al principio de la entrada la MEM1 esta en la dirección 0x00 mientras que para la GPU esta en la dirección 0xF6. El motivo es que ambos procesadores utilizan sistemas de direccionamiento distintos para acceder a las memorias del sistema ya que aunque la memoria este unificada cada procesador utiliza un sistema de direccionamiento distinto, la GPU que es de la arquitectura R7xx utiliza un direccionamiento Big Endian mientras que la CPU utiliza un direccionamiento Little Endian.

El caso es que que quiero que entendáis que los 32MB de memoria que van desde el 0xF4 al 0xF6 es la misma memoria que va desde el 0x00 al 0x02 donde pone System y que en Wii U la eDRAM no solamente sirve para los búfers de imagen sino también como RAM del sistema. Algo que en el diagrama principal de la patente es llamado Internal Main Memory.

 

Así pues con tal de ahorrar en la cantidad de chips de la memoria externa necesitamos:

  • Memoria Embebida para los búfers de imagen.
  • Memoria Embebida como cache de texturas donde almacenar las texturas de la escena.
  • Memoria Embebida como RAM del sistema.

No olvidemos que a Xbox One se le critica la ESRAM no por el hecho de ser una mala idea, en el fondo no lo es, sino por el hecho de que es de baja densidad para las resoluciones en las que opera la consola. Wii U en cambio es una consola pensada para funcionar a resoluciones más bajas y es por ello que sus 32MB le son suficientes pero… ¿Que ocurre con un salto a los 1080P? Pues que la eDRAM necesaria pasan a ser de 80MB dentro del chip en lo que a densidad se refiere para poder mantener bajos la cantidad de chips de memoria en la placa base, lo cual es una cifra enorme.

En el informe que la gente de NeoGAF consiguió sobre el Latte de Wii U se puede leer:

The large orange block on the left is 32MB of eDRAM, known as MEM1. It’s 40.72mm², and takes up 27.8% of the die.

Teniendo en cuenta que el proceso es de 40nm, esto significa que en el mismo espacio a 28nm sería posible colocar unos 64MB y a 20nm unos 128MB pero un 28% del tamaño de un SoC para la memoria embebida es un tamaño considerable que se podría utilizar para otras cosas, pero dado que es la forma en la que Nintendo suele diseñar sus consolas no les veo utilizando la memoria embebida como Microsoft sino como lo han hecho desde siempre. Al fin y al cabo el método Microsoft significan muchos chips de memoria en la placa y Nintendo coloca la memoria embebida en sus sistemas para ahorrársela y reducir el tamaño de la placa base

Anuncios