NX Terminal/Portátil y la compatibilidad hacía atrás con 3DS.

He estado pensando acerca de cuál sería la mejor solución para poder adaptar la doble pantalla de 3DS a una única pantalla panorámica como la que hemos visto en las patentes recientes de la consola.

630x

La solución es sencilla, necesitamos una pantalla con un ancho de 720 pixeles, unos 400 pixeles de la pantalla serían para representar la pantalla superior de la misma aunque en este caso deberíamos excluir el 3D, los otros 320 serían para representar la pantalla inferior, obviamente se necesita que la pantalla tenga la capacidad de utilizar un stylus,no por ello tiene que ser una pantalla resistiva sino que pueden existir otros métodos para implementar dicha funcionalidad.

En cuanto a la resolución vertical sería de 480 nativos, en modo 3DS el chip encargado de leer del búfer de imagen y escribir en la pantalla LCD dibujaría la misma línea dos veces mientras que en modo NX funcionaria con las 480 líneas. Esto no significa que la resolución de la pantalla del dispositivo vaya a ser esa, no podemos olvidar la función Off-TV que siga descrita en las patentes, es decir, del hecho de que la consola de sobremesa transmita las imagines generadas inalámbricamente al controlador y desde el momento en que las televisiones tienen una resolución 16:9 entonces la resolución de pantalla del dispositivo tendría que ser en ese formato, lo que haría que esta fuese de 854×480, dejando un espacio de de 134 pixeles en horizontal que se puede utilizar para separar la representación de las dos pantallas.

Ahora bien, el añadido de la compatibilidad con 3DS tiene más miga que la compatibilidad hacía atrás de otras portátiles de Nintendo. ¿El motivo? Game Boy, Game Boy Color, Game Boy Advance y Nintendo DS eran consolas que renderizaban la escena a la velocidad en la que se iba dibujando la pantalla como las viejas consolas de 16 bits. ¿Un ejemplo de ello? Mirad lo que ocurre cuando se le hacen subidas o bajadas de velocidad a una NintendoDS:

Pero 3DS es una bestia de otra naturaleza ya que rompe con dicha tradición, para entenderlo hay que tener en cuenta la naturaleza de su GPU, el DMP PICA200, cuya unidad geométrica no es una máquina de estado que realiza siempre el mismo programa. Es decir, no es un algoritmo o serie de algoritmos codificados en el chip donde el único control que tenemos son los datos sino que el programador tiene control sobre la forma en la que se tratan los datos por lo que el número de ciclos en cada juego variara y por tanto la sincronía con la velocidad de reloj que era tan necesaria en las anteriores portátiles de Nintendo desaparece por completo en la compatibilidad hacía atrás con 3DS.

Si miramos las especificaciones de 3DS nos encontramos que debido a la compatibilidad hacía atrás con DS/DSi la velocidad de reloj maestra es la misma que la de DSi.

Captura de pantalla 2015-10-01 a las 7.00.31

La velocidad de reloj maestra es la que rige el sistema y hace que todos los componentes de la misma funcionen a un múltiplo de dicha velocidad de reloj, el motivo de ello es el ARM9 que es el que permite la compatibilidad hacía atrás con los juegos de DS/DSi, pero Nintendo siempre se ha asegurado la compatibilidad hacía atrás en una generación y es por ello que en la siguiente generación el sistema va a romper con la tradición en cuanto a la velocidad de reloj se refiere.

Añadir la compatibilidad hacía atrás con 3DS es a su vez más complejo, ya que tenemos que integrar en lo máximo posible el SoC de 3DS.

clipboard07l

La parte roja es la CPU de 3DS, un ARM11MP2 a 268Mhz sin cache de segundo nivel, ejecutar el código para dicha CPU no es problema en otros ARM más potentes desde el momento en que las CPU con conjunto de instrucciones ARM más avanzadas son compatibles hacía atrás en cuanto a código binario. El problema vendría con los juegos para la siguiente versión de la consola:

New-Nintendo-3DS-26

Si miramos la tabla de arriba veremos que no solo han duplicado el número de núcleos sino que en modo N3DS funciona a 804Mhz, es decir, tres veces la velocidad de reloj de 3DS, a eso hay que sumarle la cache L2 que debería aumentar el rendimiento del sistema. Es decir, la nueva CPU debería ser lo suficientemente rápida para ejecutar los juegos en modo N3DS de forma nativa, estar compuesta por unos cuatro núcleos, tener 2MB de cache de segundo nivel en su interior y ser compatible con el set de instrucciones ARM.

El catálogo que tiene Nintendo para escoger una CPU es inmenso, dentro del catalogo de CPUs ARM existentes, sinceramente no se la CPU por la cual pueden optar para la NX Terminal/Portátil pero ha de ser lo suficientemente potente como para poder ejecutar los juegos al nivel Wii U en lo que a CPU se refiere. Si tenemos en cuenta el IPC y la velocidad de reloj de Wii U el número de instrucciones por segundo teóricas es de 5750 millones de instrucciones por segundo mientras que el de New 3DS es de 4200 millones por lo que hace falta una CPU más potente para que la versión de bolsillo de NX no tenga un cuello de botella en ese aspecto. En todo caso esta claro que con el antediluviano ARM11 de 3DS y New 3DS no se pueden quedar.

El segundo punto a incluir es la RAM, por el momento voy a dejar la memoria embebida a un lado y me voy a centrar en la memoria externa.

Captura de pantalla 2015-10-04 a las 12.26.20

3DS tiene unos 128MB de memoria FCRAM conectados a un bus de 64 bits en modo clamshell (cada chip esta conectado a una interfaz de 32 bits) y en New 3DS la densidad ha pasado a ser de 256MB y con el mismo ancho de banda y… El PICA200 no tiene acceso directo a la RAM principal… ¿Entonces como accede las texturas y al contenido en la misma? A través del llamado Transfer Engine, lo cual es una unidad DMA que carga los datos desde la RAM a la memoria embebida que tiene la GPU. Mientras el Transfer Engine accede a la RAM la CPU no puede acceder a la misma y viceversa ya que comparten el mismo controlador de memoria y por tanto el mismo canal de comunicación.

El ancho de banda de 3DS es de unos 3.2GB/seg, hoy en día hay memorias para sistemas de bolsillo con una densidad mucho mayor y un ancho de banda mucho mayor. Pero lo importante aquí es la densidad ya que el coste de esta ha bajado en picado en los últimos años gracias a los smartphones y al hecho que sus SOs de estos requieren ingentes cantidades de memoria para funcionar bien. Actualmente tenemos teléfonos móviles de bajo coste con 1GB de RAM en su interior, lo cual a mi me parece más que suficiente para la sucesora de 3DS, esto ya nos lleva al tercer elemento, la memoria embebida.

Lo ideal sería eliminar la memoria embebida del SoC y sustituirla por una memoria externa lo suficientemente rápida, el problema es que al hacer eso lo que hacemos no es solo ampliar la interfaz de memoria del SoC y con ello el tamaño del chip sino que además estamos obligados a colocar chips de memoria adicionales en el sistema y Nintendo no ha sido nunca muy fan de dicha solución en sus sistemas, aparte de que hablamos de un chip para un sistema de bolsillo donde el espacio es crucial. El hecho de prescindir de la memoria embebida significaría un mayor número de chips en la placa, menos espacio y un encarecimiento del sistema en general. Descarto la memoria WideIO por falta de ancho de banda y la WideIO 2 por ser algo que de momento se encuentra en un mapa de ruta pero no listo para aplicarse a un producto de consumo. No hace falta decir que las memoria para sistemas de sobremesa las descartamos de entrada por temas que son más que obvios.

El otro motivo es la forma en la que funciona 3DS en cuanto a memoria, su funcionamiento es el mismo que el de GCN/Wii/PS2 donde las texturas necesarias son pre-cargadas en un espacio de la memoria embebida por una unidad DMA. Dado que la memoria embebida es un requerimiento para mover los juegos de 3DS no la podemos eliminar de la ecuación y esta se tiene que mantener en el nuevo sistema.

En cuanto a su funcionalidad, la memoria embebida se encarga de dos funciones distintas:

  • Como cache de texturas (lectura)
  • Como búfer de imagen (escritura)

El motivo por el cual se incluye memoria embebida para ciertas funciones de la GPU es porque la interfaz con la memoria RAM externa no da el suficiente ancho de banda para realizar ciertas operaciones con el rendimiento esperado… ¿el problema con el que nos enfrentamos? No tenemos información sobre cual es el ancho de banda de dicha memoria, pero mirando las especificaciones del PICA200 lo podemos deducir.

PICA200Specs

Lo que llama la atención es que el sistema soporta filtrado bilineal, es raro que no soporte trilineal o anisotropico que son mucho más avanzados y dan mejor calidad de imagen. El filtrado bilineal necesita 4 muestras por pixel, eso son 4 accesos de memoria por pixel y con 4 bytes por pixel (RGBA8888) el ancho de banda en 3DS para la lectura en la memoria embebida vendría a ser de:

268 Mhz* 4 Unidades de Texturas*4 Bytes por pixel*4 Muestras=17,152 GB/seg.

En cuanto a escritura la cifra debería ser la misma por lo que el ancho de banda total de la memoria embebida de 3DS y New 3DS sería de 34,3 GB/seg aproximadamente, lo cual significa que la GPU esta conectada a la memoria embebida a través de una matriz de 1024 bits.

Ahora bien, no hay que olvidar que la idea de Nintendo es el hacer uso de los mismos bienes de producción a la hora de desarrollar juegos en sobremesa y portátil, esto significa que hay una serie de reglas comunes y en el caso de Nintendo en Wii U han adoptado el rendering por diferido y dudo mucho que lo dejen ir en el caso de NX. Bueno, en realidad el rendering por diferido se convirtió en la regla general en PS3 y 360 también.

Zelda-Wind-Waker-HD-09 12510267324_abef78ac6d_b zelda-wii-u

Es decir, NX debería tener dicha calidad de imagen pero a 480p, el problema con el que nos enfrentamos es que el ancho de banda para este tipo de renderizado es muy grande. No es común en sistemas de bolsillo precisamente por ese motivo pero se podría implementar sin problemas en un sistema con memoria embebida.

Empezando por el tema del ancho de banda de la memoria embebida, la formula sería:

(Número ROPS de la GPU*(color+z))*(lectura+escritura)*4 bytes/muestra*n muestras/pixel*velocidad de reloj de la GPU.

Si Nintendo mantuviese los 268Mhz, una configuración de 4 ROPS y el mismo ancho de banda entonces la formula se convertiría en lo siguiente:

(4*(2))*2*4*n*268=34304.

Como veis es exactamente el mismo ancho de banda que he comentado antes, el caso es que si lo resolvemos:

17152n=34304.

n=2.

Esto significa que con el actual ancho de banda solo podríamos trabajar con unas dos muestras solamente, por lo que para poder trabajar con un mayor número de muestras hace falta ampliar el ancho de banda teórico, hacerlo en cuanto a velocidad de reloj significa aumentar el consumo por lo que al final la cosa se reduce en aumentar la interfaz, dado que Wii U puede operar hasta con 8 muestras por fotograma entonces la ampliación de la interfaz de la memoria sería de 4096 bits.

¿Pero cual sería el tamaño de la memoria embebida entonces? Depende de la forma en la que la GPU renderice la escena, la memoria embebida solo guarda el búfer trasero ya que el delantero es leído desde la memoria principal por el chip dedicado en enviar los datos de la imagen ya terminada a la pantalla. El búfer trasero es el lienzo sobre el que trabaja la GPU y una vez terminado este es copiado por el transfer engine a una sección concreta de la RAM principal.

Si la GPU renderiza de forma directa y no por bloques/tiles entonces la memoria necesaria para el búfer de imagen sería de:

854*480*4 bytes por pixel*8 muestras=12.5MB de memoria embebida dentro del chip sin contar la cache de la CPU.

Pero no sabemos si Nintendo optara por renderizado directo o por bloques/tiles. El segundo con tal de ahorrar costes es el el ideal, en todo caso la consola no puede prescindir de los 6MB de memoria embebida por la compatibilidad hacía atrás con 3DS y tampoco del PICA200 para poder ejecutar los juegos. Aunque por el momento no entrare en el tema de la GPU, pensad que hay muchas cartas encima de la mesa, muchas posibilidades por el momento y lo mejor es que se concrete una, aunque mi apuesta personal sería un Adreno.

Anuncios