¿Por qué creo que NX será compatible hacía atrás con Wii U?

Comentario Original:

pregunta. ¿que te hace pensar o que indicios hay que nx sea retrocompatible? todos sabemos como ha sido el tema de wii con wiiu, y wii con game cube, pero con NX se repetirá?

y otra cosa, realmente, era necesario este refrito ?

Hay varios motivos que me hacen pensar en ello.

En primer lugar esta el tema de la tradición en Nintendo y el hecho que NX empezó a plantearse con Iwata aún a la cabeza de Nintendo y en estas altura debe estar muy avanzadas, desde que Iwata fue presidente todas las consolas de Nintendo han sido compatibles hacía atrás con la generación anterior, tanto en sobremesa como en portátiles. Obviamente si NX es compatible hacía atrás lo será con Wii U y no con Wii por lo que esto abre el abanico de remasterizaciones en HD hacía Wii U/NX con tal de llenar el catálogo.

En segundo lugar tenemos el tema de la estructura de costes del desarrollo, es decir, no me veo a este señor…

shigeru-miyamoto-zelda-900x571

… que sigue siendo el máximo encargado de software de Nintendo según sus propias palabras en el último set de preguntas y respuestas con los inversores:

Como el “camarada” que supervisa la producción entera de software de Nintendo…

Sinceramente no me veo a Miyamoto apostando por ampliar el tamaño de los equipos de desarrollo para dar cabido a mayores valores de producción por parte de los juegos de la propia Nintendo, no olvidemos que el coste de los juegos se dispara enormemente a medida que aumentamos los valores de producción y estos son necesarios para marcar la diferenciación gráfica y el aprovechamiento del hardware gráfico de un sistema.

cerny_aias

750px-Factor_5_dev_costs

¿En que me baso además? En recientes declaraciones de Miyamoto donde él dijo lo siguiente:

“Wii U es suficientemente buena en términos de potencia del hardware…”

“… es más sobre la carga de trabajo del equipo.”

Basicamente baso mi posición en las palabras de Miyamoto y el hacer de las cosas que tiene Nintendo. Claro esta que la situación esta vez es diferente que cuando ocurrió lo siguiente:

Tanto Gamecube como Wii ejecutan sus juegos “sin un SO” es decir, no existe un Sistema Operativo integrado en el sistema que sea utilizado por los juegos. En cambio en Wii U dentro del firmware de la consola existe una cosa que los hackers han nombrado como Café OS que es un SO complejo utilizado por los juegos y las diferentes aplicaciones.

WiiUOS

Esto es importante por las palabras que pudimos leer en el último set de preguntas y respuestas con los inversores, las cuales vuelvo a poner a continuación:

Entiendo que, gracias a la evolucion de la tecnología de las computadoras, apuntar a un entorno se desarrollo de software que no dependa de un hardware específico se esta convirtiendo en la norma de hoy en día.

Esto lo dijo Takeda, lo que viene a continuación lo dijo Miyamoto:

Desde la era de la Famicom, ha sido a menudo el caso en que los desarrolladores de software quienes eran capaces de comprender las técnicas unicas de desarrollar software en un hardware único eran capaces de crear software de calidad. Ahora todo el mundo con un cierto nivel de conocimiento puede crear aplicaciones y especialmente aquellos para los dispositivos inteligentes, nos gustaría desplegar un entorno de desarrollo que eliminase dicha carga en lo máximo posible y que fuese aplicable a una gran variedad de dispositivos.

La única manera de conseguir una independencia respecto a un hardware concreto es colocar un SO concreto y hacer dependientes los juegos de dicho SO, lo cual es un concepto bastante anti-consola pero es lo que permite que el software para los PCs de todo tipo (tanto tradicionales como dispositivos Post-PC) sean independientes de un sofware en concreto y recordad lo que dijo Iwata y que tantas veces he puesto aquí porque es clave.

Apple es capaz de lanzar dispositivos inteligentes con varios factores forma uno después de otro porque hay una sola manera de programación adoptada por todas las plataformas. Apple tiene una plataforma común llamada iOS. Otro ejemplo es Android, pese a que hay varios modelos Android no tiene sequías de software porque hay una forma en común de programar en la plataforma Android que funciona con varios modelos El punto es: las plataformas de Nintendo deberían ser como esos dos ejemplos.

¿Y cual será la base? El Café Os de Wii U.

Una de las cosas que pude aprender en el último par de días es algo curioso y a la vez muy interesante porque coloca todo el tema de la compatibilidad hacía atrás bajo una nueva perspectiva. Resulta que la comunicación entre la API gráfica GX2 y la GPU de Wii U no se hace a nivel de metal, es decir… existe un controlador/driver para la GPU por el medio que añade una sobrecarga de tiempo de renderizado. ¿Que significa esto? Ya os comente recientemente que dicha API en realidad es una versión del OpenGL 3.3 con extensiones para aprovechar las capacidades únicas de la GPU de Wii U, pero creía que su comunicación era a nivel de metal, es decir… pensaba que no existía un controlador por el medio y que el juego escribía directamente en la parte de la memoria desde donde el procesador de comandos de la GPU lee las instrucciones.

cb

Pero resulta que tenemos un controlador/driver… esto abre la posibilidad de la compatibilidad hacía atrás descartando por completo la GPU7 por otra distinta. Es decir, en Wii U ocurre como en PC donde es igual la GPU que tengas mientras cumpla una especificaciones generales mínimas. Esto explicaría además el famoso anuncio de Nintendo del año pasado, el cual ya ha sido retirado por Nintendo pero cuyo texto decía lo siguiente:

Captura de pantalla 2015-11-15 a las 13.26.45

La parte importante en este caso es la que dice:

… Evaluar el rendimiento de las soluciones SoC tanto para las APIs gráficas propietarias como estándar

Normalmente las APIs propietarias de un fabricante de consolas están diseñadas bajo un hardware en concreto, no olvidemos que la idea de la oferta de trabajo era alguien que pueda:

Evaluar las ofertas de hardware gráfico (GPU) entre las diferentes ofertas de SoC disponibles en el mercado basadas en la potencia, el consumo y el área ocupada en el chip.

Yo esto lo había pasado completamente por alto, pero recientemente he podido saber que Nintendo tiene el Café Os pensado para que sea agnóstico de GPU, esto significa que Nintendo puede colocar perfectamente una GPU mucho más potente y avanzada y asegurarse que en el aspecto gráfico los juegos de Wii U se ejecuten sin problemas independientemente de la GPU que lleve el sistema y sin que Nintendo tenga que trasladar la GPU de Wii U al nuevo sistema, dejando espacio libre en el SoC para otros menesteres.

No obstante no lo es a nivel de CPU y esto es algo general en todos los SOs…  Es posible realizar un port de PowerPC a ARM/x86 del Café OS pero esto implicaría que los binarios de los juegos de Wii U pensados para el “Espresso” no serían compatibles y por tanto se perdería la compatibilidad hacía atrás con Wii U. Por lo que entramos en tres escenarios distintos:

  1. La compatilidad hacía atrás con Wii U se elimina por completo, esto significaría eliminar el Espresso de la ecuación del sistema y por tanto pasar de:MCM_WiiU A tener un SoC, es decir, un solo chip donde este todo englobado en vez de dos chips encima de un sustrato/interposer. Obviamente bajo ese escenario la CPU estará dentro de dicho SoC y sería ARM o x86, aunque para mi ARM tiene todos los números.
  2. Un sistema mixto, se conserva el Espresso para la compatibilidad hacía atrás y se tiene una CPU en el SoC/Latte NX que iría montando en un sustrato/interposer. La consola sería dos sistemas en uno, arrancaría en modo NX y podría ponerse en modo Wii U cuando ejecutara un juego de Wii U pasando el control de la aplicación al “Espresso”.
  3. Hacer un Espresso más potente, el chip esta hecho a 45nm SOI y por lo menos Nintendo puede pedir el proceso de 32nm SOI para hacer una versión más potente del chip.

Actualmente mi cabeza anda reflexionando sobre el posible tercer escenario.

el pensador

El paso de los 45nm a los 32nm da dos posibilidades distintas:

  1. Aumento de la velocidad de reloj de la CPU en un 30%, pasando de los 1.24 Ghz de velocidad a los 1.61 Ghz de velocidad de reloj aproximadamente.
  2. Pasar de tres núcleos a seis núcleos para manteniendo la velocidad de reloj.

En cuanto a rendimiento de los juegos es mejor el segundo escenario, siempre y cuando NX haga uso de una API gráfica que permita el uso de múltiples listas de comandos desde múltiples GPUs en vez de una sola, claro esta que esto es aplicable en los otros dos escenarios y no solo al tercero. ¿Y cual es la API que permite hacer esto? Sabemos que Nintendo no tiene ninguna propietaria en ese sentido en desarrollo pero…

khronos_group

… lo que nos lleva a Vulkan, el OpenGL de siguiente generación que permite la creación de listas de comandos desde múltiples núcleos de la CPU, justo como DX12, el GNM de PS4…

Captura de pantalla 2015-11-15 a las 14.01.26

Obviamente para ello es preferible una CPU con múltiples núcleos, recordad ademas que esto es aplicable para los tres escenarios pero en el caso del del escenario con una versión más avanzada del Espresso como CPU esto hace que sea preferible. Por otro lado el uso de Vulkan como API para los juegos de NX significa una GPU que vaya más allá de lo que pediría el GX2, el cual se quedaría por la compatibilidad hacía atrás o para que Nintendo y/o lo terceros lo usarán en sus juegos de NX si lo cree necesario.

Captura de pantalla 2015-11-15 a las 14.02.14

Supongo que el esquema general de lo que estoy hablando se comprende y esta ordenado. La ventaja que tiene este escenario es que Nintendo se puede asegurar la compatibilidad hacía atrás con el software de Wii U sin limitar técnicamente a NX ni hacer que esta se convierta en una carga en el coste final de la consola.

 

Anuncios