Trasladando de Wii U a NX (III): CPU, Cafe OS y organización de la memoria.

Antes de continuar con la tercera parte tenéis que tener en cuenta que esta serie es para presentar un escenario en el que Nintendo quiera realizar una máquina con las mínimas complicaciones necesarias para portar sus juegos y herramientas de Wii U a NX. En las dos entradas anteriores he hablado del entorno de la GPU y la relación de esta con la memoria del sistema aunque he mencionado también la CPU en la parte de la MEM1 de la segunda entrada, en esta me voy a encargar en exclusiva de la CPU y de todo lo relacionado con la misma.

La poca información oficial que tenemos es esta:

espresso_intro

Junto a la litografía del chip anotada.:

espresso_annotated

Por lo visto los tres núcleos tienen no un sistema de coherencia de cache en si mismos porque son núcleos que en su origen se diseñaron para ser mononúcleo entre ellos y de eso se encarga la unidad CIU. La coherencia de cache significa que si un núcleo hace un cambio en una dirección de memoria los otros acaban sabiendo el cambio para que no accedan a una parte de la memoria de manera errónea y lleguen a corromperla. El sistema de coherencia de caches para funcionar necesita saber si la información es global (de acceso para los tres núcleos) o privada (de acceso para solo uno de los núcleos).

Captura de pantalla 2016-05-01 a las 11.11.04

Captura de pantalla 2016-05-01 a las 11.11.49

Dado que el puntero no se encuentra en la cache L2 del Core1 al buscar el dato primero en su cache el Core1 devuelve un error un cache miss. Entonces el CIU/BIU hace lo cambios en cada una de las caches de los tres núcleos de la CPU, pero solo a nivel de CPU y dicha coherencia no es con la GPU ni con ningún otro elemento del sistema.

El siguiente cambio importante a nivel global de los tres núcleos es la ejecución de varios hilos de ejecución entre los diferentes núcleos, para ello el SDK de Wii U incluye una API pensada para gestionar los hilos de ejecución de los juegos. Dado que el Espresso es un procesador único esto supone que el código de los juegos llama a funciones que tienen una alta dependencia con este procesador. No voy a tocarla todas aquí pero si las más importantes empezando por la repartición de hilos de ejecución entre los tres núcleos:

Captura de pantalla 2016-05-01 a las 11.23.36 Captura de pantalla 2016-05-01 a las 11.23.58

Las funciones MPTask son una API que se encarga de gestionar los hilos de ejecución de los diferentes núcleos, pero es en este punto donde tenemos que tener en cuenta lo que la gente de Failoverflow descubrió sobre Wii U y su SO en concreto, Café OS o llamado en el SDK Café Core OS.

WiiUOS

Por lo que la gestión de hilos no funciona de forma directa sino que es parte de las librerías del Café OS y esto hace que el SO se encuentre asociado a dicho procesador y las aplicaciones asociadas a dicho Sistema Operativo.

Captura de pantalla 2016-05-01 a las 11.30.11

El SO de Wii U al igual que todo SO funciona en dos espacios distintos, el espacio de kernel y el espacio de usuario. Todas esas funciones se ejecutan en el espacio de kernel realmente y son accedidas desde el espacio de usuario (aplicaciones) de manera segura. Es decir, lo que se dice la gestión de los procesos es realizada por el Café OS. ¿De que manera?

Captura de pantalla 2016-05-01 a las 11.37.38

En Wii U Brew al hablar del coreinit.RPL nos los definen de la siguiente manera:

Captura de pantalla 2016-05-01 a las 11.38.44

Por lo que podemos asegurar que core.init forma parte del kernel mismo del sistema. Pero como es obvió en estos casos y por temas de seguridad las aplicaciones no tienen acceso a coreinit de forma directa y todas sus funciones sino a coredyn que es el puente de acceso entre las aplicaciones y los servicios del Core OS.

Captura de pantalla 2016-05-01 a las 11.41.22

Para acceder a las diferentes APIs del sistema y sus diferentes servicios de la misma se utiliza el coredyn, las APIs del sistema no solo son las de manejo del sistema sino también las librerías multimedia, de acceso a la red, de gestión de los mandos de control… Pero para que la gente se de mejor una idea el coredyn tiene una función similar al RunDLL32 de Windowsal enlazarlas librerías del sistema para que otras aplicaciones las puedan utilizar por lo que todos los juegos para Wii U y las aplicaciones para esta en realidad se ejecutan en el Café Core OS. Por lo que la clave en este caso es el hecho de portar el SO a otras arquitecturas… Así como sus librerías correspondientes. El hecho de portar un SO completo de un conjunto de instrucciones concreto a otro es algo que no se hace en dos días y es una de las tareas más titánicas existentes. Pero al contrario de lo que ocurría en GCN/Wii donde los desarrolladores tenían acceso directo a la CPU ahora la no la tienen por lo que el nivel de dependencia del código es menor.

Por otro lado sabemos que Nintendo va a portar el entorno de Wii U a NX y Nintendo esta llevando a cabo la unificación de plataformas a nivel de software, esto significa llevar el Café Core OS a más allá del hardware de Wii U por lo que tenemos tres posibilidades:

  1. Seguir con PowerPC.
  2. Ir a x86-64
  3. Ir a ARM.

Dado que Nintendo busca un SO común y por tanto un entorno de desarrollo común en el que el sistema híbrido no es a nivel de hardware sino de software y esto lo sabemos por las declaraciones de Iwata en su día:

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.

El año pasado también empezamos un proyecto para integrar la arquitectura de nuestras futuras plataformas. Lo que queremos decir con la integración de plataformas NO ES integrar las portátiles y las consolas de sobremesa para hacer una sola consola. A lo que apuntamos es a integrar la arquitectura para formar una base común para el desarrollo de software de tal manera que podamos hacer los assets de software más transferibles y los sistemas operativos y sus aplicaciones incluidas de serie más portátiles (entre las diferentes consolas) independientemente del factor forma y el rendimiento de cada plataforma.

¿Los motivos para ello?

Actualmente requiere mucho esfuerzo el portar el software de Wii a a 3DS debido a no solo sus resoluciones sino también a que los métodos de desarrollo de software son completamente distintos. Lo mismo ocurre cuando intentamos portar el software de Nintendo 3DS a Wii U. Sí la transición de software de una plataforma a otra se puede hacer más simple esto ayudaría a resolver el problema de la falta de juegos en los periodos de lanzamientos de las nuevas plataformas.

El hecho de tener una plataforma común elimina la redundancia en el catálogo y dado que Wii U tiene un SO más avanzado que el de 3DS (de este haré una entrada aparte) podemos asumir que este será la base. Es más, en el nuevo blog de Emily Rogers, quien ha demostrado sus contactos con Nintendo en el pasado, ella ha escrito algo muy interesante respecto a este tema:

La redundancia lleva a la ineficiencia.

Basado en mis conversaciones con mis fuentes de Nintendo, los juegos pequeños y los spin offs son solo una pequeña pieza de una estrategia más grande para ampliar la tasa de software en el futuro hardware de Nintendo. A medida que el software para portátil se va convirtiendo en más parecido al de consola, cada vez tiene menos sentido tener dos equipos distintos para dos versiones distintas del mismo juego. Desde el punto de vista de la compañía, sería mucho más fácil crear una sola pieza de software para diferentes dispositivos.

Nintendo quiere resolver el problema.

Y el problema esta en la imagen de abajo.

redundancy

Teniendo en cuenta que PowerPC a nivel doméstico esta muerto y que los x86-64 no han podido entrar en el mundo de los dispositivos de bolsillo y por otro lado los núcleos ARM si lo más lógico es pensar que la futura CPU de las consolas bajo la plataforma común NX se ejecutarán bajo ARM pero es que hay más elementos que me hacen pensar de esta manera y que el Café OS será desarrollado para este conjunto de instrucciones y no bajo x86-64 como mucha gente cree.

El primer motivo es simple, es el hecho de unificar el desarrollo de sistemas portátiles con los de sobremesa y el nivel de experiencia con el conjunto de instrucciones ARM y en el primer caso es un hecho desde GBA.

Actualmente Nintendo tiene cuatro divisiones de hardware y una de ellas es para el desarrollo de hardware. Hace años habían dos divisiones de hardware distintas, una para dispositivos de mano y otro para consolas doméstiacas, con poca interaracciones entre el personal (de ambas). De hecho, teníamos que utilizar tecnologías completamente diferentes para la portatíl y la de sobremesa al mismo tiempo. Las tecnologías que eran adecuadas para los dispositivos de bolsillo y las consolas domésticas casi no tenían nada en común, por lo que era razonable dividir el desarrollo del hardware en dos divisiones.

Por otro lado sabemos que AMD tenía planes para lanzar SoC/APU con CPU ARM en vez de x86, esto era llamado original Project Skybridge, el cual tenía que aparecer bajo el proceso de 20nm.

amd-project-skybridge

Skybridge fue cancelado al final y principalmente tenía que llevar un uncore para dos SoC distintos:

  • Un SoC con Puma+, la versión de 20nm de Puma (Jaguar).
  • Un SoC bajo el Cortex A57.

El que nos interesa es el segundo SoC el que funciona bajo x86. Pero por lo visto por falta de clientes GF acabo cancelando su proceso de 20nm dejando muerto a Skybridge bajo ese proceso:

Desde que AMD cancelo su Project Skybridge hace dos semanas ha aparecido el satánico rumor de que Global Foundries podría estar involucrada.

La lógica detrás de ello es que GloFo es que después del pacto con Samsung en los 20nm, cancelo su propio mapa de ruta para los 20nm y dejo AMD sin una plataforma para este procesador.

Ahora BitsandChips piensa que AMD ha sido dejado sin socio para su iteración de 20nm de Jaguar con soporte HSA.

En semiaccurate tienen un artículo cuanto menos interesante sobre Skybridge y el elemento intercambiable entre ARM y x86 como CPU.

Don’t think of this as two chips that share a common pinout, think of it as an entire CPU or SoC with everything in common but the cores. Those cores are far less important than the rest of the chip, they are just another swappable component.

No penseis en dos chips con una interconexión común, pensad en una CPU o un SoC con todo en común excepto los núcleos. Estos núcleos son menos importantes que el esto del chip y solo son un componente más que se puede cambiar.

Es decir, el SoC vendría a ser exactamente igual que los x86-64 pero cambiando los núcleos ARM. Por otro lado la integración de ARM con HSA lleva años en marcha por lo que la idea es colocar un núcleo o conjunto de núcleos ARM conectados al Onion3 por lo que la arquitectura general (no potencia ya que esta la desconocemos) del chip de NX, PS “Neo” y la APU para PC Raven Ridge puede que llegue a ser la misma pero cambiando la CPU en los tres casos y otros detalles como la interfaz a la memoria.

Como no quiero sobrecomplicar las cosas y la parte del traslado de la CPU esta explicada lo que toca ahora es el tema de la memoria principal del sistema.

CPU y MEM2

En la anterior entrada de esta serie vimos como la MEM2 para la GPU se dividía en 8 bancos distintos divididos en dos canales de acceso diferentes:

Captura de pantalla 2016-04-29 a las 16.43.48

Pero de estos 8 bancos la GPU solo puede acceder a cuatro de ellos:

SurfaceAddressBits

El motivo por el cual la GPU no puede acceder a todos los bancos es porque no estamos hablando de un sistema de memoria heterogenea y coherente entre CPU y GPU donde ambas pueden acceder al mismo espacio de memoria sino que pese a que fisicamente tenemos un pozo de memoria este se encuentra dividido en una parte para la CPU y otra para la GPU.

isca-2014-heterogeneous-system-architecture-hsa-architecture-and-algorithms-tutorial-11-638

En el caso de Wii U el SDK nos da la siguiente información de sobre como están repartidos los pozos de memoria.

Captura de pantalla 2016-05-01 a las 13.49.08

Tenemos que tener en cuenta que el acceso a la memoria es utilizando direccionamiento virtual, el SO no da acceso directo a las direcciones reales por seguridad.

Captura de pantalla 2016-05-01 a las 14.30.28

Mirando el mapa de memoria de Wii U podemos sacar las siguientes conclusiones de como esta organizada la memoria.

  • El Cafe OS se toma para si solo de la dirección de memoria 0x0 a la 0x02000000/33554432 Bytes, es decir, el Cafe OS ocupa en realidad un espacio de 32MB en total.
  • El espacio que va de la dirección 0x02000000 (32MB) a la dirección 0x10000000 (256MB) es para el código no gráfico de las aplicaciones, es decir entre SO y el código de las aplicaciones ambas ocupan un total de dos bancos del primer GB de memoria.
  • Tenemos 1GB para datos gráficos, hay que recordar que este se divide en dos canales con cuatro bancos cada uno pero antes de explicar la organización de memoria toca hablar de la Foreground Area y la Backgound Area.

Dado que el Cafe OS es un SO multitarea tiene que dejar los procesos y por tanto servicios y aplicaciones que no se estén utilizando en ese mismo momento en pausa en una parte de la RAM. Cuando un juego es ejecutado esta es la aplicación principal y tiene una parte de la memoria asignada y reservada:

Captura de pantalla 2016-05-01 a las 14.00.33

La asignación de la memoria no viene por parte del propio juego/aplicación sino que es asignado por el Café OS. La información del mapa de memoria es para que los desarrolladores sepan cual es el espacio de memoria reservado para cada cosa. Hay dos tipos de aplicaciones en Wii U dependiendo, por un lado esta la aplicación que se esta ejecutando en ese momento que es la aplicación frontal (Foreground).

Captura de pantalla 2016-05-01 a las 14.04.49

Captura de pantalla 2016-05-01 a las 14.05.50

Captura de pantalla 2016-05-01 a las 14.06.51

Los procesos y aplicaciones que se ejecutan en el Background ocupan unos 224MB de espacio existentes y no ser que sean llamados (o al menos su aplicación corrrespondiente) estos no tienen acceso a la MEM1.

Captura de pantalla 2016-05-01 a las 14.08.43

Es decir, esos 224MB de los primeros 256MB no están reservados en el caso de Wii U para el código del juego como había dicho yo en el pasado sino que están reservados para aplicaciones y servicios del sistema. Pero no es la única parte reservada para el proceso en el Foreground, aunque no es para la CPU sino para la GPU.

Captura de pantalla 2016-05-01 a las 14.17.01

Esto me he olvidado comentarlo en la entrada anterior pero realizare un inciso aquí… ¿Que es el Scan Buffer? Es el nombre que en el SDK se da al búfer frontal de imagen, el que es leído por el controlador de video para enviar los datos al puerto HDMI del televisor y/o al Wii U Gamepad.


captura-de-pantalla-2014-04-07-a-las-11-08-52

Es decir, el Scan Buffer es el búfer frontal por lo que esos 40MB quedan reservados para la GPU y es la parte marcada como Foreground Area si tenemos en cuenta lo que sabemos la cosa quedaría de la siguiente manera en Wii U en lo que a bancos de memoria se refiere:

export

La GPU no puede acceder a los cuatro primeros bancos y la CPU tiene reservados dos de los cuatro para las aplicaciones y el SO por lo que podemos asumir que los otros 256MB son un espacio adicional para la CPU no determinado, seguramente para los servicios y aplicaciones. Quizás se encuentra en desuso en el caso de Wii U pero solo sabemos que la GPU no puede acceder a esa parte, Lo mismo ocurre con el segundo slot de memoria:

export

Hay que tener en cuenta lo que hemos visto ya, que la GPU debería tener acceso a los 8 bancos de los dos canales en total, haciendo un total de 2GB disponibles para la gráfica bajo dicho escenario:

export-1

 

Por lo que la GPU de NX podría tener unos 2GB de memoria asignados para la GPU… ¿Pero que hay de la CPU? Recordemos que ocupan los 4 primeros slots de memoria de los dos pozos de memoria por lo que la configuración podría quedar de la siguiente manera dando acceso completo a los 8 bancos a la CPU en cada slot y dejando la asignación de memoria de la siguiente manera para el nuevo sistema:

export-1

La configuración mínima serían 4GB con bancos de 128MB cada uno, pero hay que tener en cuenta que como funciona el direccionamiento a los bancos en este caso, hay suficientes bits de direccionamiento para hacer que cada banco tenga un tamaño de hasta 4GB por lo que la memoria total del nuevo sistema podría ir por encima de los 4GB en NX. Es posible que veamos diferentes especificaciones de los dispositivos según la resolución de pantalla.

En todo caso dejo la tercera parte aquí, en la cuarta parte voy a hablar de la CPU de nuevo y cual podría ser su configuración, esa parte la ha dejado de momento en el tintero para no sobrecomplicar esta misma entrada que ya por si misma tiene mucha información compleja.

Gracias por vuestra atención y mañana colocaré la cuarta entrada de la serie, no voy a decir de que va a tratar aunque se englobará dentro de la potencial evolución de Wii U a NX en lo que al desarrollo se refiere y como afecta este el hardware.

Anuncios