Twenty Two NX (Final)

Después de reflexionar sobre como sería esta hipotética versión de NX he llegado a la siguiente conclusión: No la vamos a ver por lo que…

11993281226_b1b43b3f74

Aunque como os prometí en esta entrada voy a responder a los comentarios que han aparecido en las dos anteriores y que tengan que ver con el tema, intentare ser lo más didáctico posible en ciertas explicaciones

Comentario#1:

La retrocompatibilidad en Nintendo existe desde que no han cambiado de arquitectura. Condicionar un chip para que funciones los pocos juegos disponibles es una locura.
Que se preocupen en proporcionar MUCHA potencia y que emule WiiU o mejor, que no sea retrocompatible, sigan vendiendo WiiU (así no se sienten defraudados los que poseen una) y lancen NX con lo que supone sacarlo a mitad de generación.

Esto son dos puntos importantes a tener en cuenta.

El primero de ellos es que el problema de base es que podrían haber cambiado de arquitectura desde hace tiempo y mantener la compatibilidad hacía atrás sin problemas. ¿El motivo? El PowerPC no es un procesador concreto sino que es conjunto de registros e instrucciones que ha sido utilizado en multitud de procesadores y actualmente IBM licencia de la misma manera que lo hace ARM donde cualquiera con medios y conocimientos puede hacer su propio procesador compatible con dicho conjunto de registros e instrucciones.

¿Y como es que Nintendo no lo ha hecho? Nintendo hizo una modificación en la FPU estándar de los PowerPC, la cual puede operar con números de doble precisión (64 bits) de tal manera que le quito esa capacidad y le puso la capacidad de operar con dos números de 32 bits en el mismo registro de tal manera que se pudiera aplicar la misma operación en dos operandos distintos, esto le llaman paired singles y solo esta disponible en el PowerPC utilizado por Nintendo.

PowerPC750

Este diagrama de arriba es el del PowerPC estándar, el de abajo es el del núcleo PowerPC utilizado por Nintendo:

Captura de pantalla 2015-11-30 a las 13.36.26

Como veis el diagrama es exactamente igual, esto es porque el PPC utilizado por Nintendo es una derivación del PPC 750. ¿Para que es utilizado entonces? Hay una librería que Nintendo lleva utilizando desde GameCube que se utiliza para hacer operaciones matriciales de propósito general, un trabajo que en el caso de tener soporte “Compute Shader” lo podría hacer la GPU sin problemas pero la GPU de Wii U no puede hacer eso aparte que es utilizada para la compatibilidad hacía atrás con Wii… ¿Pero tenía que ser el PPC 750 y no otro procesador con el mismo conjunto de registros e instrucciones? Lo digo porque un procesador suele estar hecho por diferentes piezas y normalmente de un diseño a otro ciertas piezas se suelen reutilizar dentro de la misma familia en lo que al conjunto de registros e instrucciones se refiere. Lo normal hubiese sido utilizar el PowerPC 970MP/”G5 doble núcleo” pero con cambios en la FPU de este para que aceptará los paired-singles y el código de Wii funcionase sin problemas… Hubiese tenido sentido a simple vista de hacer eso en vez de hacer que IBM desarrollase el Espresso.

fpf04_13

Estas son las especificaciones del PowerPC 970MP:

cell_fdf970_13

Recordemos que la potencia del Espresso en el Dhrystone es de 8556 DMIPS funcionando a 1.24 Ghz de velocidad, pero lo importante aquí es el consumo energético del chip, es cierto que esta tabla es con el proceso a 90nm pero se ha de tener en cuenta que el consumo energético de un chip escala de forma lineal con el tamaño del transistor por lo que una versión a 45nm del PowerPC 970MP tendría un consumo de 50W a 2.5 Ghz… Y recordemos lo quisquillosa que es Nintendo en cuanto al consumo.

 

 

wii-u-power-consumption

Es decir, el hipotético PowerPC 970MP a 2.5Ghz y bajo un proceso de 45nm tendría por si solo un consumo mucho más grande que la Wii U entera. Por lo que queda claro y demostrado que el motivo de la no elección por parte de Nintendo es por temas de consumo más que por temas de rendimiento, pero si os fijáis en el consumo a la mitad de frecuencia 1.2 Ghz este es de 25W, esto es porque el aumento de la frecuencia hace que el consumo crezca de forma exponencial, de ahí que se reduzca a 1/4 parte pero dicho chip a 1.2Ghz y 45nm tendría un consumo de 12W, sería viable para Wii U pero tendría un potencia solo de 4625 DMIPS en el Dhrystone.

¿Pero que hay de la potencia en coma flotante? El siguiente diagrama es del PowerPC 970, en él veréis como la cantidad de unidades de coma flotante se ha duplicado:

Captura de pantalla 2015-11-30 a las 21.11.24

Es decir… Si Nintendo hubiese pedido un cambio en las unidades FPU para soportar los paired-singles entonces la potencia por núcleo  se hubiese duplicado pasando de 4 operaciones a 8 operaciones, por lo que la cantidad de FLOPS en paired-singles para este doble núcleo sería de 16 operaciones por ciclo en comparación con las 12 operaciones por ciclo del Espresso. Aunque lo realmente importante sería la unidad VMX/VALU que fue ampliamente utilizada en PS3 y Xbox 360, ya que ambas tenían como CPU un PowerPC pero en todo caso con una versión a 1.2 Ghz la doble unidad VMX no sería competetiva, pensad que PS3 tiene los SPE y una frecuencia mucho mayor (3.2 Ghz) y Xbox 360 aparte de esa mayor frecuencia era un triple núcleo, es decir… Incluso basando la arquitectura de la CPU en un PowerPC 970MP que pudiese meterse en el factor forma de Wii U Nintendo hubiese estado en desventaja. Es decir… el factor limitante es el factor forma elegido por Nintendo que permite únicamente sistemas con un consumo energético realmente bajo y no dio opción a Nintendo a escoger otras opciones en lo que a la CPU de Wii U se refiere.

El segundo tema, el de la emulación… más bien lo que necesita Nintendo es un interprete que le permite ejecutar el código de los juegos para el Espresso… Algo así como lo que hizo Apple cuando hizo la transición de PowerPC a x86-64 Intel.

WWDC.2K5.Rosetta.Properties

Es decir, traducción de binarios al vuelo… Curiosamente es el mismo método utilizado por los creadores del emulador Dolphin para que el código PowerPC corra en los x86. Los x86 actuales tienen la potencia suficiente como para poder interpretar el código con la suficiente velocidad y no olvidemos que el Jaguar de 8 núcleos de Xbox One puede interpretar sin problemas el más potente PowerPC, respecto al de Wii U, de Xbox 360 sin problemas por lo que un x86 parece la opción más viable en este caso.

Comentario#2:

Urian, si no me equivoco, el Smash de WiiU funciona a 1080p y 60fps… y no es el unico juego que lo hace en la consola… estariamos hablando por tanto de una NX capaz de manejar un Smash Bros a mismos frames y resolución pero mucho más potente a nivel grafico, no?

Sinceramente creo que tardaremos años en ver un nuevo Smash e incluso creo que este podría ser el último de todos, más que nada por el hecho que gracias a la capacidad de colocar contenido adicional a través de las actualizaciones del juego. En realidad Smash Bros es uno de los motivos que hace que un servidor se plantee últimamente NX como un dispositivo compatible hacía atrás con Wii U, lo mismo ocurre con Mario Kart 8 donde creo que para Nintendo les resulta más productivo mantener vivo el juego añadiendo actualizaciones con nuevos circuitos y modos de juego que no re-hacer el juego de nuevo de cara a una siguiente generación.

Esto ya es especulación mía… Pero creo que Nintendo a partir de la celebración del Nintendo World Championship quiere apuntarse a la moda de los e-Sports, siendo dicho evento una especie de campo de pruebas para ello y la aceptación fue cuanto menos positiva.

nintendo

Pero la clave de todo ello es que el cese de Wii U les ha pillado por sorpresa y la transición generacional independientemente de la compañía que seas es algo sumamente traumático en lo que a los equipos de desarrollo se refiere y Nintendo con el paso de Wii a Wii U tuvo una muy traumática por lo que no les veo queriendo hacer otra transición y más bien les veo utilizando lo aprendido en Wii U y las herramientas desarrolladas de cara a NX. Pero claro, no podemos olvidar que las cosas ya no son como antiguamente donde un juego se entregaba completo en el disco sino que ahora el concepto de los juegos con capacidad de expansión de contenido es algo que no solo se ha estandarizado sino que se ha naturalizado.

Así pues Nintendo se puede plantear nuevos modos de juego y contenido de cara a lo que ya tienen en el mercado y en el caso de los juegos basados en comunidad esto es muy importante porque les permite conservarla sin problemas. El hecho de añadir la retrocompatibilidad en combinación de lo que digo forma parte de lo que Nintendo llamo “llevarse la comunidad de una generación a otra”.

future-platforms

Sinceramente estoy esperando a ver como desarrolla Nintendo su nuevo sistema de cuentas “My Nintendo”, no creo que este se desplegue inicialmente en NX sino que lo hará primero en Wii U y 3DS durante el primer semestre del año que viene, por lo que es posible que el año que viene veamos una actualización del Café OS donde se incluya la integración con cuentas “My Nintendo” así como actualizaciones de ciertos juegos para su integración con dicho sistema de cuentas.

Nintendo puede hacer una versión x86/ARM del Café OS con un interprete para las aplicaciones de Wii U, es más, incluso puede dar la posibilidad de bajarse la versión de NX de esos juegos si tienes el disco original o si haces un traslado de permisos de una consola a la otra en el caso de tener la versión digital. Dicha nueva versiones no utilizaría el interprete PowerPC-x86 y le permitirían a Nintendo trasladar la comunidad de Wii U a NX sin problemas y continuar vendiendo esos juegos en la nueva plataforma.

Comentario #3:

Excelente post, tiene sentido un hexa-core espresso si tiene una velocidad de reloj que sea al menos un 80% mayor.

Con respecto a lo de Xarman…200 euros me parece un precio bajo para estos tiempos….Con la devaluacion de hardware (no es lo mismo 200 dolares en 1991 que en 2016) tendrian que lanzarla a un precio de 250 al menos, con online gratuito incluido, si quieren un equilibrio entre potencia/costo reducido.

Que la wii siendo una papa costaba 249 dolares en su lanzamiento, y la gente la compro como pan…299 estaria bien tambien, seguiria siendo mas barata que la wii u deluxe….

Tengo que confesar una cosa… No creo que ese escenario se cumpla y más bien es un “Y si..”… En cuanto al 80% más de frecuencia el problema de los PowerPC 750 es que tienen pocas etapas y no pueden subir mucho su frecuencia realmente. Es más, un 80% más de frecuencia sería unos 2.16 Ghz, aún estarían por debajo de la CPU de Xbox 360 y la de PS3 ya que se necesita un salto por lo menos de un 250% pero no se puede hacer por las pocas etapas del pipeline. Es por ello y por lo descrito antes que creo que este escenario no se cumplirá, más que nada porque Nintendo descartará el PowerPC en NX. De ahí a que haya pasado directamente a los comentarios, es decir… Después de analizar lo que escribí me he dado cuenta de la inviabilidad de dicho sistema.

Comentario#4:

Lindo detalle, me llamaba la atencion lo de Globalfoundries, gracias por la explicacion Urian.

Estoy de acuerdo con Ruben, arrastrar la gpu de wii u me parece algo poco inteligente asi que…

Pero nintendo es caprichosa asi que ay ay ay esta bien, mantengan la retrocompatibilidad metiendo esos 160 shader en 22nm, pero que incluyan AL MENOS unos 800 shaders GCN 2.0 porque, hombre, estamos en el 2015, hay que modernizarse un poco mi queridisimo nintendo…Al menos tendrian un rendimiento levemente superior al de una xbox one lo que supondria mayor apoyo de parte de las 3rds.

Les guste o no, tienen que moverse a la nueva arquitectura de gpu, no lo hicieron con wii, tampoco con la actual, pero ahora no hay excusa.

¿Cuando he dicho yo lo de arrastrar la GPU de Wii U? Más bien hable de utilizar una Evergreen por el hecho de que tiene compatibilidad con el código para la R700 y añade los Compute Shaders a la ecuación del sistema. Mi referencia era la GPU del AMD Llano, una APU de AMD que apareció hace unos años en PC.

llano3-1280x1024

El AMD Llano tiene una GPU con 400 Stream Processors en comparación con los 160 Stream Processors de Wii U. Tomando como referencia la potencia de Wii U y el hecho que la resolución estándar de la misma son los 720P de la pantalla del televisor+480P de la pantalla del mando a renderizar utilizando 160 Stream Processor distintos, pues esto hacen 40 SPs para el rendering del Gamepad y 120 ALUs para el rendering en pantalla. Si se mantiene el gamepad tenemos 40 SPs de base pero si pasamos a los 1080P entonces el número de ALUs pasaría a ser de 310 SPs en total, una cifra por debajo de lo que daría el AMD Llano y permitiría mover los juegos a 1080P, claro esta que la configuración sería de 320 SPs ya que una de 310 no sería posible.

Pero recientemente me ha venido una cosa a la cabeza y es lo siguiente:

khronos_group

En una entrada reciente os he hablado del SPIR-V que va a ser utilizado en Vulkan pero que por si solo es una tecnología del grupo Khronos. Pues bien… hay algo que me ha llamado la atención enormemente.

image.php

Si Nintendo utiliza el SPIR-V como un interprete del GX2 de tal manera que este se pueda ejecutar sin problemas en una GPU no basada en la ISA R600 entonces Nintendo puede añadir la compatibilidad hacías atrás sin problemas en el sistema por lo que habrían tres tipos de software en NX teniendo en cuenta este elemento.

  1. Software Nativo de NX que utilizaría la nueva API gráfica.
  2. Software portado de Wii U, utilizaría binario que solo es compatible con NX pero utilizando la API GX2 de Wii U, la cual sería interpretada por el SPIR-V para que la nueva GPU lo pudiese ejecutar sin problemas.
  3. Software de Wii U, utilizaría el binario de Wii U que sería interpretado al completo.

 

 

En todo caso tampoco es que haga falta el SPIR-V, en el caso de Xbox 360 por ejemplo teníamos la siguiente API en el sistema:

Direct3D9Xbox360

La cual estaba optimizada para la GPU de la consola y no era el Direct3D estándar… No obstante en Xbox One…

Xbox-One-play-Xbox-360-games

… Y no tiene la misma GPU que Xbox 360 ni utiliza el SPIR-V. ¿Como lo hace? Pues por el hecho que es posible convertir una API de bajo nivel en una de alto nivel a través de un controlador intermedio. Sin ir más lejos el OpenGL era la API de bajo nivel del Reality Engine de SGI, por lo que una implementación del GX2 una GPU no basada en la arquitectura del R600 y derivadas se podría realizar sin ningún problema.

Bueno, esto es todo.

Anuncios