Las GPUs de PS4 y PS3

Voy a hacerlo en orden cronológico inverso, el post es meramente informativo.

GPU PS4

La GPU de PS4 al contrario de lo que mucha gente piensa no es una Radeon HD 7870 ni una 7850 por varios motivos que voy a enumerar.

ps4-reverse-engineered-apu

En primer lugar pese a que la litografía del chip marca unas 20 CUs solo tiene 18 CUs activas, la 7870 tiene activas 20 CUs y su versión recortada tiene activas unas 16 CUs por lo que la configuración no es la misma. La otra diferencia es que las HD 78×0 son GPUs GCN 1.0 que no son compatibles con el uncore del AMD Kaveri, el motivo por el cual sabemos que PS4 y Kaveri utilizan el mismo uncore es por el Onion+, algo que requiere que la GPU tenga el set de instrucciones GCN 1.1 y no 1.0.

Visio-Kaveri_Trinity Architecture”äŠr_š.vsd

Captura de pantalla 2016-05-04 a las 11.30.33

No obstante en consolas que sea GCN 1.1 o no es algo que es relativo, porque hay instrucciones que en Xbox One están y en PS4 no y viceversa. Esto lo digo porque curiosamente la GPU de Xbox One también es GCN 1.1 según los arquitectos de la consola pero el IOMMU es de primera generación y no de segunda generación,  esto se ve en el siguiente diagrama de la Xbox One:

Captura de pantalla 2016-05-04 a las 11.31.16

Lo que tenemos un bus llamado Chive que comunica de forma coherente no con el Crossbar sino con el front-end, es decir, sirve para comunicar CPU y GPU en Xbox One de forma coherente haciendo bypass al Crossbar de coherente donde esta conectada la CPU. Es decir, la funcionalidad del Onion+ esta integrada en Xbox One pero de una manera distinta y esto tiene que afectar al conjunto de instrucciones de la Xbox One y no hacerla completamente igual a la GCN 1.1 y tener algunos cambios. Pero es que PS4 tampoco es 100% GCN 1.1 y tiene alguna que otra modificación.

Para dar apoyo en los casos en que quieras utilizar la cache L2 de la GPU para gráficos y computación sincronizada, hemos añadido un bit en los tags de la cache, lo llamamos el bit volátil. Puedes marcar de forma selectiva todos los accesos por la computación como “volátiles”, y cuando sea el momento en que sea el momento de que lea desde la memoria del sistema este puede invalidar de manera selectiva las lineas que lo utilizan en la L2. Cuando se trata de escribir de vuelta los resultados, puede escribir de manera selectiva en las lineas que esta utiliza. Esta innovación permite a la computación utilizar la cache L2 de la GPU y realizar las operaciones requeridas sin impactar las operaciones gráficas que ocurren al mismo tiempo. en otras palabras, reduce radicalmente la sobrecarga de correr computación y gráficos juntos en la GPU.

Dicho de manera simple, el bit volátil para utilizarse tiene que tener una serie de instrucciones asignadas… ¿Cual es su funcionalidad? Pues simplemente puedes reservar parte de la cache L2 para realizar computación sobre ella, en realidad esto en el caso de Sony tiene sentido porque en PS3 lo SPE del CBEA se encargaban de la computación y tenían una memoria local de 256KB, lo más lógico es pensar que para facilitarle las cosas y el traslado de PS3 a PS4 a los desarrolladores de Sony podemos pensar que esto permite a la cache L2 tener la misma funcionalidad que ls memoria local de los SPE del CBEA de PS3.

PS4_SDK_2_34

En tareas de computación los Shaders/Compute Units no utilizan las máquinas de función fija del pipeline gráfico (unidades de texturas, ROPS, rasterizador) por lo que su camino de datos es distinto, si miramos cada CU veremos que tiene unos 64KB de memoria local:

Compute Unit

La LDS es algo que también se encuentra en las CUs de Xbox One por lo que la explicación es válida en ambos casos, los shaders se cargan en esta memoria y en bloques de 64KB… ¿Os acordáis de las texturas parcialmente residentes? Pues son una tarea realizada por los shaders y por eso se manejan con datos de 64KB.

prt1crd1w

La propia Sony recomiendo utilizar los bloques PRT no solo para texturas sino también para otras tareas de computación.

PRT APP

SVCT

La idea es pre-cargar la textura en la LDS para luego copiarla hacía la cache L1 y procesarla desde allí (modo gráfico) o simplemente procesarla directamente sobre la propia LDS (modo computación). Pensad que esto es aplicable también a Xbox One desde el momento en que utilizan el mismo tipo de Compute Unit. En todo caso hay que tener en cuenta que la LDS es una memoria con un ancho de banda mucho mayor incluso que la cache L1.

gs4106-the-amd-gcn-architecture-a-crash-course-by-layla-mah-48-638

Pero en el caso del bit volatil se refiere a la cache L2, la cual se encuentra fuera de la Compute Unit.

gs4106-the-amd-gcn-architecture-a-crash-course-by-layla-mah-34-638

¿A que es debido esto? Bien, antes he comentado que esto es una reminiscencia de PS3. En PS3 los únicos momentos en que el CBEA podía ayudar no era durante el pipeline gráfico sino durante el per-procesado y post-procesado. Es decir, los SPE le hacían ganar tiempo a la GPU a base realizar los efectos de post-procesado, en algunos casos se copiaban ciertos Render Targets por bloques pequeños a la memoria local de los SPE para aplicarles un “shader” desde los SPE y devolver los datos de nuevo, esto se le llamo Tile Based Deferred Shading.

spubased-deferred-shading-in-battlefield-3-for-playstation-3-15-728

Captura de pantalla 2016-05-04 a las 13.35.28

¿Que es lo que ocurre en PS4? ¿Podemos hacer algo similar con la LDS no? El problema es que la LDS es solo de 64KB como hemos visto antes y la memoria local de los SPE era de 256KB… ¿La mejor solución? Buscar una memoria intermedia que pueda hacer caber los datos para procesar el bloque y que mejor que la cache L2. En todo caso perdón por la explicación pero he pensado que esto es importante, recordemos que PS4 tiene una serie de remasters de juegos de PS3 que aprovechan las capacidades del CBEA al haber sido juegos exclusivos de la propia Sony y este cambio en la GPU es para facilitar el traslado del código además que otros motores de editores independientes desarrollados para PS3 también utilizaban este mismo planteamiento como el Frostbite 2 de DICE.

GPU PS3

 

La configuración general de PS3 es la siguiente:

Captura de pantalla 2016-05-04 a las 13.38.33

Pero lo que interesa es el RSX y curiosamente este en potencia bruta debería algo más potente que el Xenos de Xbox 360 pero no lo es, pero antes de adentrarnos en los problemas del RSX tengamos en cuenta la comparación con la GPU de 360, aunque para ello primero hemos de tener en cuenta como Microsoft define a la GPU de Xbox 360:

Captura de pantalla 2016-05-04 a las 13.43.58

Tenemos unas 48 ALUs que combinan escalar+vector y cada una de estas ALUs puede procesar unas 96 instrucciones por ciclo, 1 para escalar y 1 para vector… ¿Pero cual es la longitud del vector?

Cada una de las 48 ALUs pueden trabajar conjuntamente con una instrucción de vector (Vec4) y una escalar al mismo tiempo.

Dado que todos los shaders del Xenos son iguales podemos deducir que hay unas 240 unidades FP32 en total, 48*(4+1), lo que significa una tasa de 240 GFLOPS a 500 Mhz utilizando instrucciones FMADD (un tipo de instrucción muy común en el código para las GPUs que realiza 2 operaciones por ciclo), pero la potencia en coma flotante de la GPU de Xbox 360 no acaba ahí, aún hay más pero esta no se encuentra relacionada con los shaders, pero antes irnos por el RSX se ha de tener en cuenta una diferencia fundamental y es que no hay correlación directa entre el número de unidades de texturas y de shaders en el caso del Xenos, al contrario de lo que ocurre con las series HD 2000 a HD 5000 y sus derivados (Wii U).

arch-big

Captura de pantalla 2016-05-04 a las 15.09.02

Es decir, las TMUs no forman parte de una Compute Unit sino que son elementos separados aunque conectados a los shaders, esto entra en contradicción con el RSX donde las unidades de texturas se encuentran directamente conectadas a los Pixel Shaders y existe una correlación directa.

Captura de pantalla 2016-05-04 a las 15.05.27

El pipeline es el mismo que el del  G71…

7900_blockdiagram

… pero con un cambio sustancial, lo ROPS que en el diagrama se encuentran entre el Fragment Crossbar y las Memory Partition son 8 en el RSX en vez de 16 haciendo que el ancho de banda externo con la GPU este recortado a la mitad. Es decir, 8 ROPS y un bus de 128 bits. El resto de la configuración es igual con 8 Vertex Shaders y 24 Pixel Shaders y en multitud de Wikis se pueden leer las siguientes especificaciones:

Captura de pantalla 2016-05-04 a las 14.48.46

Esto a simple vista es suficiente para enviar a la porra al Xenos ya que estamos comparando 400 GFLOPS con 240 GFLOPS, el problema es que dicha comparación es tramposa y contradice lo que dice Sony en su documentación.

 

3dps309

La diapositiva hace referencias solo al Pixel Shader… ¿Pero como es que se pasa de los 648 FLOPS/ciclo a los 384 FLOPS/ciclo? ¿Es que acaso estamos hablando de dos GPUs distintas? Ni mucho menos, solo que quienes hacen esos números son bastante trileros…

pixelshader

El RSX tiene dos ALUs (FP32 Shader Unit n en el diagrama) que pueden realizar 8 operaciones por ciclo que en FMADD serían 16 y por tanto 24*16=384 y es de ahí donde viene la cifra de los 384 que sumados a los 80 de los VS dan un total de 464 operaciones por ciclo en FMADD frente a las 480 del Xenos. Aunque en todo caso la configuración de shaders del RSX deja de tener importancia ante lo que os voy a contar ahora, que es cuanto menos de…

picard-facepalm

Lo comente hace bastante tiempo pero digamos que la GPU de PS3 es mucho peor que la de Xbox 360 y que el motivo por el cual PS3 da mejores gráficos en ciertos juegos respecto a 360 es por el apoyo del CBEA. ¿El motivo? Hay una cosa en todas las GPUs que son los Vertex Inputs, como habréis adivinado por su nombre son los parámetros que se colocan en los vértices, pues bien… El RSX tiene un problema enorme sobre eso:

“Tengo un shader que requiere unos 8 vertex inputs, Posición, Normal, color, y Texcoord1 a Texcoord5. Asumiendo que todos los inputs están empaquetados (por lo que x,y,z, y w son utilizados). Además, necesito que ese shader se aplique en una masa de cien enemigos que está cerca de la cámara (y por tanto utilizar el mejor lod) y cada uno de ellos tiene 5000 vertices. O si preferís, imaginad una escena 3D con 500K vértices. Estos escenarios son comunes y matan el rendimiento del RSX.”

“Asumo que también sabéis que las unidades de procesamiento de los vértices en PS3 son terribles, cada uno de los vertex shader inputs añaden un ciclo de retardo. De la misma manera, sabréis que la única manera de saltarse esta limitación en PS3 es utilizar los SPU para per-procesador toda la geometría y realizar un backface curling en el Cell primero antes de enviarlos a la GPU.”

“El vertex pipeline no importa cuando tienes que gastar un ciclo para el vertex input. En otras palabras, la GPU se para hasta que esta puede captar todos los datos antes de que pueda incluso empezar a ejecutar el vertex shader. ¿Por qué estoy s importante= Pues por el hecho que los juegos de siguiente generación necesitan un montón de “lookup maps” para verse bien, esto significan montones de coordenadas u/v (cartesianas) y otros datos que necesitan ser pasados al Vertex Shader, y por lo tanto un montón de inputs/entradas. En el caso del RSX, esto significa que la GPU se para. Este es el conocido talón de aquiles de PS3 y esta bien documentado. La única manera de trabajar alrededor de este es utilizar los SPU del Cell como otra “GPU”, en este caso como una “Culling GPU”, y limitar el número de vértices enviado al RSX”.

¿Que importancia tiene esto? El proceso gráfico son una serie de etapas donde los datos se van transformando.

gl-pipeline

Dado que las GPUs son procesadores de caudal y todo el pipeline empieza en el Vertex Input si este esta limitado en el caudal de datos que reciben el resto de etapas del pipeline queda afectado. Es decir, el número de vértices de entrada se acabaran convirtiendo en fragmentos que procesar y si limitas los primeros acabas limitando los datos de entrada de los segundos.

captura-de-pantalla-2012-10-04-a-las-10-24-53

Es decir, es completamente igual que la configuración en cuanto a shaders del RSX fuera el de la GF7900 cuando realmente no operaba como esta en rendimiento. El otro problema son los Pixel/Fragment Shaders, estos dependen enormemente de los ROPS para ejecutar ciertas operaciones y recortarlos de 16 en la GF7900 a 8 en el RSX afecta al rendimiento pero esto no  es un problema desde que el Vertex Input que es una etapa muy anterior es un problema aún mayor, otro problema que tiene que ver con tener un bus de 128 bits en vez de uno de 256 bits son las unidades de texturas. Ya he comentado más de una vez que el rendimiento de las TMUs dependen del ancho de banda de estas con la RAM donde se encuentran las texturas, el hecho de que el caudal de datos pase a ser de 128 bits afecta al rendimiento. ¿El motivo por el cual es de 128 bits? Pues simplemente el colocar un bus de 256 bits hubiese aumentado los ya más que hinchados costes de PS3.

Por culpa de estas limitaciones el RSX no opera con el rendimiento con el que debería operar, personalmente no se si esto es un handicap para forzar el CBEA a los desarrolladores pero con esto la GPU de PS3 esta más que explicada.

Sobre los costes de producción en la actual generación y el potencial futuro

Fuente:

“El primer juego de Gears of War costo $12 millones en desarrollar, e hizo sobre unos $100 millones en ingresos.”

Veamos de otra fuente el coste de Gears of War 2 para poder comparar, esto viene de la misma Epic:

Captura de pantalla 2016-05-03 a las 10.34.35

Volvamos a la noticia de antes:

Al final del ciclo, Gears of War 3 costo sobre unas cuatro o cinco veces más (entre $48 y $60 millones) de hacer que el original“… “Los beneficios estaban disminuyendo y disminuyendo. Calculamos que, si construíamos Gears of War 4, el presupuesto estaría por encima de los $100 millones y si era un enorme éxito cubririamos los gastos. Cualquier cosa menos de eso nos echaría del negocio.

¿A que es debido esto? A una Ley de la Economía introducida por David de Ricardo llamada “Ley de los Rendimientos Decrecientes“.

En economía, la ley de los rendimientos decrecientes (o ley de proporciones variables, principio de productividad marginal decreciente o retornos marginales decrecientes) es la disminución del incremento marginal de la producción a medida que se añade un factor productivo, manteniendo los otros constantes. Afirma que en todos los procesos productivos, añadir más de un factor productivo mientras se mantienen los otros constantes (ceteris paribu) dará progresivamente menores incrementos en la producción por unidad.

Es un principio fundamental de la economía  y tiene un rol principal en la teoría de la producción

Esta ley dice que a medida que se aumenta la mano de obra o el capital en la producción el rendimiento económico, va disminuyendo. En este panorama, la razón humana sólo puede adoptar una postura pasiva y de inevitabilidad de la misma y adaptarse a las exigencias de dicha ley. De los rendimientos decrecientes viene una de las principales y más controvertidas teorías de este Ricardo, quien planteó lo que para él era una gran paradoja: la consecuencia del crecimiento económico es que se irían reduciendo los márgenes de ganancia de las empresas, hasta llegar a ser prácticamente cero. Curiosamente la influencia de Ricardo sobre el Das Kapital de Marx es sumamente importante porque Marx nunca hablo de revolución proletaria espontánea sino que dijo que la revolución obrera llegaría cuando los amos de lo bienes de producción los abandonaran provocando la toma de estas por parte de la clase proletaria.

Espera, espera… Urian… ¿No crees en el Marxismo y en cambio lo utilizas para analizar el mundo de los videojuegos? ¿No es un poco contradictorio?

Tanto Marx como Ricardo tenían influencias de lo que llamamos Economía Clásica del Liberalismo, donde existía el concepto del plusvalor, es decir… El plusvalor es el diferencial entre las ganancias y el salario del obrero. El concepto es muy simple porque en la producción de muchos bienes participa el coste de las materias primas, los costes de distribución de las mismas… ¿Pero que ocurre en los videojuegos? Todo, absolutamente todo el trabajo que hay en un videojuego es de origen humano en lo que a la producción se refiere, es por ello que los desarrolladores cuentan los costes de producción siempre por el personal asociado.

Pero mirad por donde que en la anterior generación los costes subieron una barbaridad respecto a las otras… ¿Esto a que fue debido? En realidad en todas las generaciones anteriores el coste fue subiendo pero en la anterior se acelero y el motivo de ello es muy simple, el aumento de especificaciones supone el aumento de personal y en la anterior generación vimos un hecho que no se ha dado en esta. Las dos compañías sacaron de salida hardware de gama muy alta para una consola, tan alta que tanto Sony como Microsoft tuvieron perdidas astronómicas y Nintendo huyo de dicha batalla técnica para evitar la auto-aniquilación económica.

sony-nintendo-microsoft-operating-income-chart-fix

El problema de los rendimientos decrecientes es muy sencillo de explicar, el mercado es finito en tamaño y el aumento de los costes ha ido mucho más rápido que el crecimiento del mercado que además no solo se ha centrado en el mundo de los juegos AAA sino también en otros mercados, por ejemplo el género MOBA esta fuera y genera cantidades ingentes de dinero… ¿Y que ocurre al final? Que el diferencial en beneficios va bajando, la gente tiene la tendencia en pensar que cuando pagas por un juego actual pagas la producción del que en este momento esta en desarrollo… Es decir, el enorme crecimiento en costes fue debido a que los márgenes eran lo suficientemente altos para realizarlos y la gran mayoría de empresas se han ido descolgando o cambiando su mercado objetivo a medida que han visto que no son competitivas.

Eso si, hay que tener en cuenta que el coste de los juegos depende de los salarios de lo países de origen… ¿Que es lo que tradicionalmente hacen las empresas cuando los costes de personal son demasiado altos para sus cifras? Las deslocalizan, por eso en países donde los salarios son más bajos están apareciendo escuelas de formación de profesionales y/o se están formando nuevos estudios por el hecho que el coste del personal es menor. Esto lo digo porque existe un diferencial entre el coste de Gears of War y las cifras dadas en el gráfico de Factor 5. Aunque el siguiente enlace es de 2010 nos puede dar una idea de como están las cosas, ya que los salarios no han cambiado lo que se dice mucho:

Captura de pantalla 2016-05-03 a las 11.10.33

Es decir, el coste por trabajador de un juego producido en los EEUU es de $79K anuales, en Japón es de $57.6K anuales… Y estamos hablando de paises del primer mundo avanzados donde los salarios son altos, en otras partes del mundo los salarios son mucho más pequeños por la misma capacidad de producción. Pero supongamos una superproducción hecha por cien personas reciente… A ver… ¿Que juego podría sacar? Ah si… Ya se cual y os parecerá irónico pero…

El personal de Star Fox Zero es de unas 100 personas aproximadamente y el salarió medio japonés lo hemos establecido en $57.6K por trabajador, aunque siendo Nintendo podría ser mayor. El juego ha estado unos dos años en desarrollo (se vio un prototipo en el E3 de 2014) por lo que el coste del juego han sido $12 millones… Es decir… el mismo coste que el primer Gears of War pero al contrario que Gears of War ha sido un enorme fiasco en ventas. Como no me gusta hacer leña del árbol caído lo mejor es tener en cuenta cual sería el número de copias de salida necesario para recuperar los costes.

De un juego de $60, el editor independiente se lleva entre un 50% y un 60% de los beneficios de acuerdo como haya pacto con las tiendas, es decir… Entre $30 y $36 por copia vendida. En el caso de Star Fox Zero al ser el juego de un fabricante este no se tiene que pagar la regalía por lo que se lleva $7 de más, por lo que por copia Nintendo se puede llevar entre $37 y $43 brutos… Bueno, en realidad menos porque no estamos teniendo en cuenta el coste de los impuestos pero se supone que vienen incluidos en los costes por trabajador y tampoco el coste del marketing, lo digo porque la información no es precisa al cien por cien y no es más que una aproximación de lo que se necesita para recuperar los costes de producción de los juegos.

12.000.000/43= 280K copias vendidas.

12.000.000/37= 325K copias vendidas.

El coste del juego si se hubiese producido en los EEUU sería de 16 millones por tanto:

16.000.000/43= 373K

16.000.000/37= 433K

Pero volvamos a Gears of War… Que es la saga desde la cual estoy haciendo la comparación.

gears-of-war-3-7

Dado que Epic es un editor independiente, ya se que GoW fue un exclusivo pero lo tomo solo como ejemplo, esta tiene que paga una regalía por lo que las cifras para dar beneficios eran las siguientes:

12.000.000/36= 334K

12.000.000/30= 400K

Hay que tener en cuenta que los costes de marketing acaban duplicando, triplicando e incluso cuadriplicando en algunos casos los costes asociados a los juegos pero esto no son costes de producción. Si aplicamos esto a Gears of War 3 donde sabemos que el presupuesto máximo es de 60 millones entonces nos sale que la cantidad de copias vendidas necesarias se va a los 2 millones de unidades para que el juego sea rentable y si tenemos en cuenta el coste de $100 millones de Gears of War 4 nos vamos a los 3.2 millones… ¿Pero es que acaso no hay más mercado? ¿Es que acaso no hay juegos que venden más? Si que los hay pero el rendimiento de la saga es ese en lo que a mercado se refiere y el riesgo es enorme.

¿Que es lo que pasa al final? Muchos conceptos, muchas sagas… Llegaron hace tiempo a su límite presupuestario a nivel técnico y no pueden competir contra los AAA porque lo que es el baremo de los AAA va aumentando con el tiempo por intereses de unos editores independientes que saben que es más fácil vender por la estética. Obviamente estos editores independientes lo que más temen es que aparezcan editoras en paises con salarios más bajos que les hagan la competencia y actualmente se están moviendo para trasladar la industria a esos países para evitar ser desplazados en su propio juego. Pero es que además esto supone un caso curioso, dado que los AAA en su mayoría se encuentran con uno márgenes cada vez más bajos el hecho de unos AAA de siguiente generación están muy en duda en estos momentos… Es más, buena parte del producto de la actual generación son remasterizaciones de juegos AAA de la anterior, los cuales son más baratos de realizar que un juego AA de la actual generación y son más atractivos para el público.

Para mi la mejor solución son los juegos AA, es decir… Lo que yo en una entrada hace tiempo dije que son juegos HBO, es decir… El sector debería plantearse hacer una gama media de juegos y dejarse por completo de apostar en el número más alto, bueno, en realidad parte del sector que va a ver que con el tiempo se va a cumplir la predicción de Ricardo y veremos como los grandes editores colapsaran a no ser que encuentren una salida. A todo esto hay que sumarle el hecho de que existe una devaluación que encima reduce aún más las ganancias. Quizas estoy siendo muy negativo pero lo que esta claro es que la carrera espacial no tiene mucho sentido si se basa en el aumento de personal y por tanto de los costes de producción.

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.

Fe de Erratas de la Fe de Erratas sobre PS “Neo”

Estaba realizando la tercera parte de la serie sobre el traslado de Wii U a NX cuando realizando esta he caído en algo concreto y que es muy pero que muy posible que el SoC de la PS4 “Neo” si que este realizado bajo 14nm FinFet pese a Jaguar… ¿Como lo ser? Bueno, la historia empieza con el cancelado Project Skybridge que era la gama de SoCs/APUs bajo el proceso de 20nm de Global Foundries.

amd-project-skybridge

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.

Pero AMD anunció no la cancelación sino el salto de dichas tecnologías de los 20nm a los procesos FinFet.

Captura de pantalla 2016-05-01 a las 13.15.36

Esto significa que si que hay una versión de la arquitectura Jaguar (Puma+) bajo FinFet y el motivo por el cual dije que el SoC de PS4 “Neo” iba a ser de 28nm es completamente falso y esto viene de información de primera mano. Es más, Puma+ al contrario de Jaguar soporta el HSA por lo que AMD puede que utilice el Onion3 como uncore de dicho sistema. Por otro lado el hecho de sea FinFet hace posible que la GPU pase a ser Polaris y por tanto esta si que tendría soporte HDR… Si, se que la cosa es muy confusa pero sobre lo dice GlobalFoundries prefiero descartarlo frente a lo que dice AMD que pienso que tiene más autoridad en este tema aunque no hable directamente de PS4 “Neo” aunque hay cosas que se sobreentienden.

Por otro lado, no olvidemos las especificaciones de PS4 “Neo” en cuanto a GPU:

Captura de pantalla 2016-05-01 a las 13.20.44

Y las especificaciones filtradas del chip Polaris 10:

Captura de pantalla 2016-05-01 a las 13.22.53

Perdón por dar tantas vuelta sobre el tema y marear al personal. Es por ello que os pido disculpas:

maxresdefault

Esto es todo.

Trasladando de Wii U a NX (II): GPU, DMAE y Memorias

Antes que nada os voy a traducir la siguiente réplica escrita por Sebbbi, quien es programador de la saga Trials y sus perlas de sabiduría  técnica sobre consolas son siempre bienvenidas, es importante leerla para entender el contexto respecto a un elemento en concreto del hardware de Xbox One, la memoria embebida, esto es importante para lo que viene después en la misma entrada en lo que a Wii U respecta y el salto de Wii U a NX.

Mirad algunas de las presentaciones de la GDC y el SIGGRAPH (en los últimos tres años). Se mencionan optimizaciones a medida de la ESRAM por varios equipos. Y estoy seguroque cada juego AAA utiliza fuertemente la ESRAM hoy en día y tiene montones de código para esta. Sin la ESRAM el ancho de banda total de la Xbox One es de 68 GB/seg. Incluso los juegos Indie se están volviendo tan gráficamente intensivos que perder 2/3 del ancho de banda total ya no es una elección realista.
Necesitas dirigir manualmente tu uso de la ESRAM y políticas de localización de esta, mover los datos hacía dentro/fuera y escribir/leer datos hacía/desde la ESRAM utilizando la ESRAM y los Compute Shaders. La ESRAM de Xbox One no es una cache automática, esta es una memoria scratchpad completamente manual. La cache eDRAM L4 de Intel (en algunos  modelos Broadwell y Skylake) por el otro lado es una cache automática. Las caches necesitan un espacio considerable en el chip para los tags de la cache y el hardware coherente. Microsoft (AMD)  probablemente decidieron que una cache manual era más adecuada para una consola, debido a que el código a medida será escrito para la consola de todos modos. Intel por otro lado escogio implementar una cache eDRAM de 64MB/128MB completamente automatizada porque en el software de PC casi nunca se optimiza para una sola arquitectura.
La arquitectura de memoria UMA de las consolas modernas (Xbox 360, Xbox One, PS4) hacen dificil emular juegos en una plataforma con una GPU dedicada (como es el PC). Los juegos de estudios internos de los fabricantes pueden utilizar algoritmos donde la CPU y la GPU estén colaborando estrechamente. Este nivel de (baja latencia) cooperación no es posible en un PC con una GPU dedicada. En general ninguna consola con la que he trabajado ha sido diseñada para ser completamente compatible hacía adelante (he trabajado con 7 consolas). Es siempre un sacrificio hacer la consola anterior completamente compatible hacía atrás. Mientras los desarrolladores tengan permiso para acceder al hardware a bajo nivel, la compatilidad 100% a lo fácil no ocurrira.
La cosa esta en que si Microsoft o Sony no permitieran acceso al hardware a bajo nivel, pero su competidor lo permitiera, los juegos se verían y se moverían con un framerate más suave en la consola del competidor. A nadie le gustaría esto, ni a los clientes y tampoco a los fabricantes. Es mejor dejar a los desarrolladores utilizar el hardware al completo ya que resulta en los mejores juegos.

Voy a aplicar lo que dice Sebbbi a otro sistema con una GPU con memoria embebida y con una organización del hardware muy parecida a la de Xbox One, me estoy refiriendo a Wii U:

wiiu

Wii U tiene en el SoC donde se encuentra la GPU, Latte, unos tres pozos de memoria embebida, estos son:

  • MEM0: Compuesta por unos 2MB eDRAM y 1MB SRAM… Hacen la misma función que el eFB y el eTC de la GX GPU de GameCube y Wii, son memorias automáticas por lo que no requieren el manejo por parte de los desarrolladores para funcionar, aunque su uso solo es para la compatibilidad hacía atrás.
  • MEM1: Compuesta por unos 32MB de memoria embebida, esta memoria no es automática sino manual por lo que ocurre lo mismo que la ESRAM.
  • MEM2: Los 2GB de memoria externa DDR3

Esto se ve mejor definido aquí:

Captura de pantalla 2016-04-29 a las 16.16.23

El hecho que la MEM2 sea la dedicada para texturas es importante por la relación entre ancho de banda de la memoria donde están las texturas, número de unidades de texturas y los shaders. En todo caso hay una cosa me llama la atención de la información del SDK que es la siguiente:

Captura de pantalla 2016-04-29 a las 16.19.01

Lo de los 3GB para la MEM2 llama la atención desde el momento en que si hubiese un modelo con 3GB entonces tendríamos una placa base con 6 chips de memoria en vez de cuatro, el ancho de banda sería mayor en un 50% y el número de Shaders físicos para gráficos pasaría de los 160 a los 240. Es solo un pequeño inciso de algo que me llama la atención.

¿Y que hay de la MEM1? Pues al igual que la ESRAM de Xbox One es de manejo manual como he dicho antes… ¿Y como se que es manual? Pues porque existe una API en el sistema que se encarga del manejo del traslado de memoria desde la MEM2 (memoria principal) a la MEM1 memoria embebida.

Captura de pantalla 2016-04-29 a las 16.25.15

Es decir, el DMA Engine es lo mismo que los Move Engines de Xbox One, realizan la misma función, la cual no es otra que el hecho de poder trasladar datos desde la memoria interna del chip a la memoria externa y viceversa. Por cierto, el rendimiento de las transferencias de una memoria a otra utilizando el DMAE se puede ver en el siguiente gráfico

Captura de pantalla 2016-04-30 a las 15.17.57

El portar un juego de Wii U a una NX con una configuración distinta de memoria y sin el DMAE llevaría consigo los mismos problemas que se enfrentaría un juego a la hora de ser portado a un hardware futuro de Nintendo que prescindiera de la eDRAM y por tanto del DMAE que un juego de Xbox One a un futuro hardware que prescindiera de los Move Engines y la ESRAM… Pero las similitudes no terminan aquí. ¿Verdad que en la documentación de Xbox One los Move Engines/DME son llamados también unidades Swizzle?

xbox-one-gpu-diagram-100051501-orig

En el caso de Wii U/Cafe ocurre lo mismo y es aquí donde entramos en un elemento que es importante y que tienen compartidas ambos hardware… ¿Cual es la ventaja que tiene que la memoria embebida sea de manejo manual? Más que nada el hecho de tener control absoluto sobre como funciona la misma, el handicap es perder ciclos de reloj e instrucciones en manejar en la copia de datos de una memoria a otra.

Una vez explicado de manera general el DMAE veamos la MEM2 y su relación con la GPU.

MEM2 y GPU.

Con tal de evitar conflictos en el acceso a las texturas o partes de estas la memoria principal MEM2 se divide en dos canales (1GB cada una) de 8 bancos distintos:

Captura de pantalla 2016-04-29 a las 16.43.48

Para acceder a un canal u otro de la la MEM2 de manera manual la GPU utiliza el siguiente formato de instrucción de direccionamiento de 32 bits:

SurfaceAddressBits

Los bits 0 a 7 son ignorados, el bit 7 nos marca en cual de los dos canales de la MEM2 se encuentra el dato, los bits 9, 10 y 11 (2^3=8) marcan en que banco puede encontrarse el dato, los bits 12 a 31 sirven para marcar la dirección de memoria dentro de dicho banco. El resto son unos 20 bits que marcan las diferentes páginas de 4KB, la cifra de 32.768 es un direccionamiento de 15 bits realmente por lo que realmente un futuro  sistema podría soportar una cantidad de memoria RAM mayor.

(2^15)*4KB= 131.072 KB = 128 MB

(2^20)*4KB= 4.194.304 KB = 4 GB.

No deja de ser algo anecdótico y es muy difícil que cada uno de los bancos tenga un formato de 4GB cada uno en un futuro pero es importante porque esta es la forma en la que el controlador de memoria de la GPU7/GX2 accede a la memoria principal del sistema. En todo caso hay un handicap en el hardware de Wii U y es que el tercer bit para escoger banco no esta activo, por lo que el total de memoria con el que puede operar la GPU de Wii U es solo con 4 bancos y por tanto 512MB/0.5GB.

Captura de pantalla 2016-04-29 a las 17.05.44

El hecho de esta limitación es curiosa, porque si miramos la placa base de Wii U veremos que tiene 4 bancos de memoria, es decir… 4 chips de memoria, los cuales están encuadrados en amarillo en la siguiente fotografía de la placa base de la consola:

WiiUBoard

Es decir, tenemos uno cuatro bancos que comparten los dos canales entre ambos, no olvidemos que la memoria DDR funciona con con dos canales simultáneos pero es curioso comprobar como el diseño del sistema se hizo pensando en 8 bancos de memoria y que hay posibilidad para ello en un futuro sistema si este parte desde lo hecho en Wii U. Hay que tener en cuenta que estamos hablando de un escenario con los pozos de memoria: interna (MEM1) y externa (MEM2) y el uso del DMAE, todo ello para facilitar la transición de Wii U a NX, por lo que en el caso de la MEM2 tenemos las siguientes configuraciones posibles:

Memoria Bancos Bus Ancho de banda  Densidad
DDR3-1600 4 64 bits 12.8 GB/seg 2 GB
DDR3-1600 8 128 bits 25.6 GB/seg 4 GB
DDR3-1866 4 64 bits 14.9 GB/seg 2 GB
DDR3-1866 8 128 bits 29.15 GB/seg 4 GB
DDR3-2133 4 64 bits 17 GB/seg 2 GB
DDR3-2133 8 128 bits 34 GB/seg 4 GB
DDR4-2133 4 64 bits 17 GB/seg 4 GB
DDR4-2133 8 128 bits 34 GB/seg 8 GB
DDR4-2400 4 64 bits 19.2 GB/seg 4 GB
DDR4-2400 8 128 bits 38.4 GB/seg 8 GB
DDR4-2666 4 64 bits 21.33 gB/seg 4 GB
DDR4-2666 8 128 bits 42.7 GB/seg 8 GB
DDR4-3200 4 64 bits 25.6 GB/seg 4 GB
DDR4-3200 8 128 bits 51.2 GB/seg 8 GB
GDDR5-5000 (Clamshell) 4 64 bits 40 GB/seg 4 GB
GDDR5-5000 4 128 bits 80 GB/Seg 4 GB
GDDR5-5000 (Clamshell) 8 128 bits 80 GB/Seg 8 GB
GDDR5-5000 8 256 bits 160 GB/seg 8 GB
GDDR5-6000 (Clamshell) 4 64 bits 48 GB/seg 4 GB
GDDR5-6000 4 128 bits 96 GB/seg 4 GB
GDDR5-6000 (Clamshell) 8 128 bits 96 GB/seg 8 GB
GDDR5-6000 8 256 bits 192 GB/seg 8 GB
GDDR5-7000 (Clamshell) 4 64 bits 56 GB/seg 4 GB
GDDR5-7000 4 128 bits 112 GB/seg 4 GB
GDDR5-7000 (Clamshell) 8 128 bits 112 GB/seg 8 GB
GDDR5-7000 8 256 bits 224 GB/seg 8 GB
GDDR5-8000 (Clamshell) 4 64 bits 64 GB/seg 4 GB
GDDR5-8000 4 128 bits 128 GB/seg 4 GB
GDDR5-8000 (Clamshell) 8 128 bits 128 GB/seg 8 GB
GDDR5-8000 8 256 bits 256 GB/seg 8 GB

Tenemos un abanico de configuraciones posibles bastante grande, no obstante tenemos que descartar todas aquellas que no nos permitan llegar a un mínimo de rendimiento visual, hay que tener en cuenta que existe una relación directa entre la MEM2 y las unidades de texturas de la GPU y estas con las unidades shader al estar acopladas a estas. Dado que es muy seguro que Nintendo haga uso de la arquitectura GCN para la GPU de NX tenemos que tener en cuenta como son sus controladores de memoria:

Cada controlador de memoria tiene una anchura de 64 bits para dos canales de 32 bits GDDR5 independientes. Para productos de bajo coste, la GDDR5 puede ser reemplazada por memoria DDR3. Para grandes cantidades de memoria, la GDDR5 puede operar en modo clamshell y hacer uso de dos DRAM por canal, doblando la capacidad.

Si miráis la la tabla de arriba veréis que la DDR3 a igualdad de bits que la GDDR5 no es comparable sino que su rendimiento es mucho menor, en realidad la equivalencia es que 64 bits GDDR5 se suelen sustituir por 128 bits DDRn por temas de ancho de banda, es por ello que he decidido tachar todas las configuraciones de 64 bits DDRn de la tabla de arriba, sabiendo esto y teniendo las configuraciones posibles en cuanto a CUs he hecho esta otra tabla:

Bus TMUs CUs Stream Processors
64 bits DDRn/32 bits GDDR5 12 3 192
64 bits/32 bits GDDR5 16 4 256
128 bits DDRn/64 bits GDDR5 24 3+3 384
128 bits DDRn/64 bits GDDR5 28 3+4 448
128 bits DDRn/64 bits GDDR5 32 4+4 512
256 bits DDRn/128 bits GDDR5 48 3+3+3+3 768
256 bits DDrn/128 bits GDDR5 52 3+3+3+4 832
256 bits DDRn/128 bits GDDR5 56 3+3+4+4 896
256 bits DDRn/128 bits GDDR5 60 3+4+4+4 960
256 bits DDRn/128 bits GDDR5 64 4+4+4+4 1024

Las configuraciones de 64 bis DDRn han sido eliminadas de la ecuación por motivos obvios ya explicados y teniendo en cuenta lo que explique en la entrada anterior  he eliminado lo que no supone el mínimo de colocar los juegos de Wii U de 720P a 1080P, por lo que he marcado en rojo la configuración con 384 Stream Processors. Cada array de hasta 4 CUs tiene conexión con la Cache L2 y esta con el controlador de memoria, la jerarquía de cache se ve mejor en el siguiente diagrama:

Captura de pantalla 2016-04-30 a las 10.47.55

Cada 4 CUs en la arquitectura comparten el acceso a la cache L2 y en algunas excepciones por redundancia se colocan hasta 3 CUs por bloque dejando la 4 inactiva y de de ahí la tabla que he hecho antes en cuanto al número de CUs, aquí se ve mucho mejor con configuraciones de 4 CUs:

Captura de pantalla 2016-04-30 a las 11.11.50

Y de 3 CUs:

Captura de pantalla 2016-04-30 a las 11.11.50

Esto se ve mejor mirando la organización de la arquitectura GCN:

gs4106-the-amd-gcn-architecture-a-crash-course-by-layla-mah-34-638

Es decir, la configuración con la memoria externa es la que va a afectar el número CUs y con ello el rendimiento gráfico de la potencial GPU de la consola, dado que hemos establecido que los mínimos son los juegos de Wii U a 1080P y lo deseable de 720P30 a 1080P60 si tomamos lo que dije en la anterior entrada:

Como no podemos tener shaders parciales esto redondeando serían unos 448 hilos de ejecución simultaneos, o lo que es lo mismo, unas 7 CUs de la arquitectura GCN ejecutando código por lo que si el mínimo sería colocar los juegos de Wii U de 720P a 1080P con un simple cambio de resolución entonces una GPU con 7 CUs es suficiente, si en cambio se busca ir a los 1080P60 desde los 720P30 entonces estaríamos hablando de 14 CUs, pero se ha de tener en cuenta que la GPU7/GX2 funciona a 550Mhz por lo que puede ser que el número de CUs sea inferior a esa cifra de 14 o simplemente con tal de ahorrar en consumo la velocidad de reloj sea inferior.

Una vez explicada la relación de la MEM2 con la GPU toca explicar la de la MEM1. En cuanto la relación CPU-MEM2 la explicare en otra entrada.

MEM1/eDRAM, relación con la CPU y la GPU.

Antes os he comentado como la presencia del DMAE y su uso para el traslado de datos de la MEM1 a la MEM2 y viceversa supone que el hecho de eliminar el esquema de memoria que tiene Wii U en el nuevo sistema supone re-escribir de nuevo el código del juego. Pero antes de ir a la MEM1 hay que tener en cuenta que la configuración de Wii U es la de un sistema con memoria no unificada y que pese a utilizar memoria embebida tiene ciertas diferencias con la memoria embebida de Xbox One en cuanto al acceso a esta, si miramos la litografía de Xbox One veremos como la ESRAM se encuentra al lado de la GPU pero muy alejada de la CPU:

Teardown-Xbox-One-processor-die-2

Mientras que en Wii U la eDRAM no solo esta al lado de la GPU sino que se encuentra directamente al lado de la interconexión GP I/O/(60Xe) que comunica con la CPU del sistema.

wiiudie_blocks

Esto tiene una explicación, la ESRAM de Xbox no esta pensada para que la CPU acceda a la misma:

Xbox-One-ESRAM

Mientras que en el caso de Wii U y el SDK nos los deja bastante claro, la CPU tiene acceso a dicha memoria:

Captura de pantalla 2016-04-30 a las 9.12.02

Lo que ocurre es que en el acceso por parte de la CPU es que no hay un sistema de coherencia con la memoria, esto es curioso y me llama poderosamente la atención porque es habitual que exista dicha coherencia en sistemas con cache compartida, claro esta que en el caso de la CPU de Wii U dicha cache L2 de la CPU realmente no es compartida sino que cada núcleo de la CPU tiene la suya propia:

espresso_annotated

espresso_intro

Es más, Nintendo en el SDK recomienda utilizar el mecanismo DMA de los núcleos del Espresso, los cuales se comunican con el DMAE del Latte para el acceso tanto a la MEM1 como a la MEM2.

Captura de pantalla 2016-04-30 a las 9.16.06

¿Pero como es que la CPU tiene acceso a la MEM1? El motivo de ello es simple, para ejecutar los juegos de Wii se necesita tener el esquema con dos pozos de memoria principal que esta tenia, los 24MB de memoria interna y los 64MB de memoria externa. En modo Wii la MEM1 hace el trabajo de la memoria interna para la CPU y la MEM2 (DDR3) la de la memoria externa. Pero una vez explicado el motivo por el cual la CPU se encuentra conectada a la eDRAM nos toca hablar de la GPU, en concreto de la relación de esta con la MEM1/eDRAM.

En realidad en lo que a la relación GPU-Memoria en Wii U tenemos una relación como en el PC donde la GPU tiene una memoria local para si misma y luego puede acceder a la memoria principal del sistema. El problema aquí es que la memoria local no tiene suficiente densidad como para almacenar las texturas, aunque se puede texturizar desde la misma… Aunque sobre ello en concreto ya entraré más adelante.

Captura de pantalla 2016-04-29 a las 16.58.27

Tenemos 8 canales distintos en vez de 2 en la MEM1, si miramos la litografía del Latte de Wii U podremos ver que esta dividida en 8 bancos iguales…

Captura de pantalla 2016-04-29 a las 17.11.33

… como este:

Captura de pantalla 2016-04-29 a las 17.12.36

El motivo de dicha división es porque la GPU soporta hasta 8 muestras de búfer de imagen, estas se pueden utilizar haciendo uso de Forward Rendering o del Deferred Rendering, en el primer caso la GPU pueda hacer uso del MSAA hasta 8x a nivel teórico pero no tiene suficiente memoria para ello incluso a 720P, el motivo de ello es que la formula para el MSAA es la siguiente:

Resolución*(Color+Profundidad)*Número de muestras.

Por lo que en MSAAx8 y a 720P la memoria ocupada sería:

1280*720*8*8= 56.25 MB

Nintendo recomiendo el uso del FXAA y también el renderizado por diferido donde también hay unas 8 muestras pero el búfer de profundidad no se vuelve redundante y solo tiene que ser utilizado en una de las 8 muestras para tener su acceso al mismo.

Captura de pantalla 2016-04-30 a las 9.33.25

No obstante el sistema en cuanto a densidad tiene sus problemas, unos 32MB se hacen limitados para un búfer de imagen de 1080P en 16:9, en dicho caso cada uno de los bancos de la eDRAM debería pasar de los 4MB de memoria a unos 9MB de memoria aumentando el total de memoria embebida de los 32MB a los 72MB. La memoria utilizada en Wii U es de 40nm de Renesas:

necele_08

La densidad es de 0.06 y la eDRAM disponible en el mercado que tiene más números de ser utilizada por Nintendo sería la de 28nm de TSMC, no tengo datos de eDRAM en procesos más avanzados y es por este motivo que ayer os puse esto:

Captura de pantalla 2016-04-30 a las 9.39.21

Ahora bien, la eDRAM no es la mismo que la eSRAM y la densidad de esta última es de 0.16um^2, esto es debido a que en densidad la eDRAM tiene una ventaja de 3:1 pero una gran cantidad de eDRAM también es contraproducente pero hemos de tener en cuenta que esto es diferente a la eDRAM de GameCube/Wii, aquí el desarrollador tiene acceso libre a la memoria embebida para gestionarla como quiera y es aquí donde se ve como el trabajo de la eDRAM no es el de almacenar los búfers de imagen sino que estos pueden estar en cualquier sitió, esto plantea dos problemas adicionales:

  • Los efectos de post-procesado.
  • Los efectos de los Pixel Shaders que dependen de los ROPS (como los mapas de sombras).

Para que los mapas de sombras sean eficientes necesitas que se encuentren en la misma memoria a la que se encuentran conectados los ROPS por lo que el mapa de sombras se encontrará dentro de la MEM1/eDRAM junto a no ser que se desplace alguna muestra fuera de la MEM1, este es el motivo por el cual los juegos de Wii U normalmente prescinden de los mapas de sombras. Y en cuanto a los efectos de post-procesado tiene que ver no solo con el espacio sino con el ancho de banda de la eDRAM, el cual en modo lectura+escritura no duplica el ancho de banda como la ESRAM de Xbox One al no tener un modo duplex sino que la divide en ambas direcciones. Aunque realmente la eDRAM tampoco es mala idea, el problema es la densidad de la eDRAM y perdonad si vuelvo a citar a sebbbi de nuevo pero es importante en el contexto en el que estoy hablando:

Una eDRAM de lectura/escritura practicamente anularia todos los costes de ancho de banda de la generación/sampleado del g-buffer y el rendering de post-procesado (es decir, efectos a pantalla completa que son consumidos en las etapas tardias del pipeline). Y sería genial para la computación desde la GPU.

Sin embargo no anularía el coste en ancho de banda de los shadow maps, a no ser que tengas una enorme cantidad de eDRAM. Un solo atlas de shadow maps toma unos 64MB, e incluso este no es suficiente si quieres renderizar por encima de los 720P con mapas de sombras/shadow maps de buena calidad.

Un mapa de sombras de 64MB no es suficiente para resoluciones encima de los 720P y dado que estos aumentan en potencias de 2 entonces el mapa de sombras ideal para 1080P es de 256MB por lo que el total de memoria embebida que necesitamos para no tener ningún handicap sería de 256MB+72MB, es decir… Un total de 328MB de memoria. Es por ello que es importante tener en cuenta que una de las ventajas del manejo manual de la eDRAM es que permite hacer cosas como ir desplazando de la eDRAM hacía la MEM2 aquello que ya esta resuelto y/o cuyos datos en ese momento no se necesitan para ser utilizados en ese mismo momento. Esto es otro de los elementos que Wii U tiene en común con Xbox One y es por ello que la cita de sebbbi del principio de la entrada es importante.

El DMAE hace la misma función que los Move Engines/Swizzle Copy que existen en Xbox One, exactamente la misma. Es más, al igual que ocurre en las Xbox (360 y One), Wii U soporta un mecanismo de Tiling… Pero este es descrito de la siguiente manera en el SDK de Wii U:

Captura de pantalla 2016-04-30 a las 10.05.10

Una superficie puede ser una textura o un búfer de imagen, la referencia es a la MEM2 donde tenemos 2 canales como hemos visto antes con 4 bancos cada uno, pero no tenemos acceso a 8 bancos en el caso de la MEM2 tal y como se ha visto antes… ¿El motivo? El hecho de poder colocar los otros 4 bancos en la MEM2 por el simple hecho de que Nintendo reconoce que hay shaders cuyo rendimiento al ejecutarse bajo la MEM2 es nefasto, lo dicen ellos mismos en el SDK:

Captura de pantalla 2016-04-30 a las 10.12.38

¿Se puede texturizar desde la MEM1? Es que aquí esta la trampa y mucha gente lo compara con el Virtual Texturing que se puede realizar en Xbox One cuando no lo mismo en absoluto. Si que se puede texturizar pero esto supone que los 4 de los 8 canales de la MEM1 se usen para lectura y no para escritura, afectando al ancho de banda. Pero es que lo mismo ocurre con los efectos de post-procesado así como para los mapas de sombras donde también se tienen que utilizar los canales para lectura. Es decir, el código de Wii U al igual que ocurre con el de Xbox One esta lleno de operaciones con la unidad DMA para ir desplazando los datos entre la MEM1 y la MEM2.

El siguiente elemento a tener en cuenta son los RB del sistema, tenemos unos 2 en total con 4 ROPS cada uno de ellos:

GPU7BlockDiagram

Los RB o Render Back-End son descritos de la siguiente manera en el SDK de Wii U/Cafe

Captura de pantalla 2016-04-29 a las 17.25.25

Pues bien, los RB han sido una de las piezas que desde el R700 no han evolucionado incluso en las GPUs más modernas de AMD y el ancho de banda por cada uno de ellos es 8 bytes por ciclo por que en RGBA8 pueden escribir color+profundidad en un solo ciclo por lo que por ROP el ancho de banda de la GPU es de:

550 Mhz* 8 bytes= 4.4 GB/seg.

Esto es menos que los 6.4 GB/seg por canal de la MEM2 pero si los juntamos todos:

4.4 GB/seg*8 ROPS = 35.2 GB/seg.

Dados los problemas existentes que he comentado unas pocas lineas más arriba lo ideal sería integrar en el siguiente sistema una memoria embebida con dos canales (DDR) por banco, si esto se hubiese hecho en Wii U entonces el ancho de banda de la eDRAM sería de 70.4 GB/seg y las operaciones de lectura no entrarían en conflicto con las de escritura pero esto significaría tocar el acceso a la MEM1 en NX, haciendo que uno de los bits inactivos pase a estar activo para elegir el segundo canal.

Además existe una relación entre la anchura en bits de la interfaz con la memoria embebida y el número de RBs y es un simil que se da también en Xbox One. La interfaz de la GPU7/GX2 con la MEM1 es de 512 bits para 2 RB, curiosamente si comparamos con Xbox One veremos que el ratio es el mismo ya que Xbox One tiene una interfaz de 1024 bits (256 bits x 4) para una GPU con 4 RB (16 ROPS).

XBox_One_SoC_diagram

Hay que tener en cuenta que no existe una relación directa entre el número de RBEs y el número de CUs, pero hay que tener en cuenta que no tener el suficiente ancho de banda supone un handicap para los ROPS al mismo tiempo que no tener la tasa de relleno teórica suficiente es un desperdicio del ancho de banda de la memoria a la que estén asignados. En Wii U tenemos unos 8 ROPS (2 RBs) y es posible que Nintendo repita dicha configuración en NX si esta lleva memoria embebida u opte por una de 16 ROPS (4 RBs) en todo caso el ancho de banda ideal pasa a ser:

Velocidad de reloj*Número de ROPS*16 bytes.

Dado que los búfers de imagen se procesan en la memoria embebida (MEM1), la MEM2 deja de tener importancia en el tema del ancho de banda con los ROPS. Desconozco la densidad que escogería Nintendo para NX en el caso de que esta utilice memoria embebida, en todo caso el mínimo sería una cifra de 32MB y el número de RBs sería de 2 con unos 8 ROPS. Tened en cuenta que estamos hablando de un escenario en el que el sistema hereda el esquema de memoria de Wii U y eso tiene unas consecuencias que he ido explicando en esta entrada. ¿La siguiente? El peliagudo tema de la CPU y el Café Core OS.

Trasladando de Wii U a NX (I): GPU

Esto lo he comentado varias veces, pero el diagrama que viene a continuación es de la GPU de Wii U… ¿Que particularidad tiene con lo anteriormente dicho? Vienen del SDK oficial de la consola, la primera información es acerca de la naturaleza de la GPU y cual es su arquitectura, algo que ya he demostrado varias veces en este blog, pero esta vez lo haré con fuentes primarias:

Captura de pantalla 2016-04-29 a las 13.25.27

El diagrama general de la GPU que se puede encontrar en el SDK es el siguiente:

GPU7BlockDiagram

Tenemos dos unidades de texturas, dos SIMD y 2 RB (Render Back-End) cada RB equivale a unos 4 ROPS por lo que la configuración es de 8 ROPS en total, pero por el momento lo que me interesa es la unidad SIMD:

GPU7SIMDDiagram¿Como se explica esto? Ya lo explique en su día, por lo que me voy a autocitar:

Ahora vayamos a la que utiliza Wii U, su GPU es de la familia R700 por lo que la configuración de sus Compute Units es distinta a la de la arquitectura GCN. Si miramos la configuración de la arquitectura R700:

RV770_2

Cada “núcleo” tiene 80 unidades, lo pongo entre comillas porque aquí núcleo no corresponde a Compute Unit y se puede confundir. El caso es que las 80 unidades están compuestas en unidades de 16 de estas:

shaderproc

Que son lo que la diapositiva de arriba llama ALUs. ¿Verdad que antes he dicho que los Wavefronts entran en grupos de 16? La diapositiva no es muy clara cuando habla del ratio 4:1 pero se refiere a que cada grupo de 5 Stream Processors (ALU) le toca una TMU, es decir… el ratio en la arquitectura R700 es de 20 ALUs por TMU, pero esto tiene una pequeña desventaja, dado que la gran mayoría de operaciones gráficas se hacen con cuatro componentes la mayoría de veces el quinto stream processor quedaba completamente en desuso por lo que AMD en arquitecturas posteriores decidió pasar al ratio 16:1 para las TMUs, tal y como se ve en la Compute Unit de la arquitectura GCN.

En Wii U tenemos 8 unidades compuestas cada una de ellas por una TMU y sus respectivas ALUs. Marcadas con la letra N en el Latte que es donde se encuentran las Compute Units de su GPU:

wiiudie_blocks

Cada N corresponde a una TMU distinta, por lo que en realidad tenemos 2 unidades SIMD por tanto 160 Stream Processors.

Es decir, la documentación oficial me da la razón sobre el número de unidades shader del sistema. En todo caso lo del número de Shaders y la configuración esta en la siguiente tabla:

Captura de pantalla 2016-04-29 a las 15.05.18

Sin salir de los Shaders hay que tener en cuenta que la GPU puede renderizar en dos modos distintos, con el Geometry Shader activado (OpenGL 3/DX10) o con este desactivado.

Captura de pantalla 2016-04-29 a las 13.46.47

El camino de datos en el caso de no utilizarse los Geometry Shaders es el siguiente:

NoGeometryShaderPath

Mientras que en el caso de utilizarse los GS la cosa cambia:

NoGeometryShaderPath

Ahora bien, el rendimiento de los shaders es diferente respecto al modo de usarse ya que la localización de recursos cambia por completo.

Captura de pantalla 2016-04-29 a las 13.50.05

¿Cual es dicha localización de recursos?

Captura de pantalla 2016-04-29 a las 13.50.19

Tenemos 192 hilos de ejecución en total, pero tenemos solamente unos 2 SIMD por lo que tenemos cargados dos wavefronts, uno por cada SIMD y el tercero en espera. Cada uno de los hilos de ejecución corresponden a una ALU distinta. Pero hay un elemento que me ha llamado poderosamente la atención y son los Compute Shaders… Dado que el R7xx no soporta OpenGL 4.x ni DX11 pensaba que no los íbamos a ver y están pero no de la forma estándar sino de una forma exclusiva y de una manera que me ha llamado poderosamente la atención:

Captura de pantalla 2016-04-29 a las 13.56.50

La parte importante es la que dice:

La GPU7 es incapaz de implementar la especificación completa de la extensión ARB GL_ARB_compute_shader. Proveemos una extensión para Café para que sea compatible hacía adelante compatible con la extensión ARB estándar pero aún tomando ventaja de las capacidades Compute Shader de la GPU7.

Es decir, no soporta el set completo de los Compute Shaders pero si una versión parcial. El problema es que no hay soporte de múltiples contextos en Wii U debido a que la versión vitaminada del OpenGL 3 que es el GX2 no añade la capacidad de crear multiples contextos en la GPU, al fin y al cabo la arquitectura R700 no trabaja con multiples contextos simultaneos al ser una GPU DX10/OpenGL3.

01 03

La diapositiva dice soporte gráfico al nivel DX10. La mención de DX10 respecto no al renderizado sino a los Compute Shaders se pueden leer en la siguiente parte del SDK:

Captura de pantalla 2016-04-29 a las 14.11.25

Dado que cada Compute Shader ocupan unos 64 hilo esto significa que ocupan un Wavefront entero y por tanto se comen el 50% del rendimiento, lo interesante es que están pensados para ser compatibles hacía adelante.  El otro tema relacionado con los shaders es el lenguaje en el que están escritos estos, GX2 es una API gráfica modelada a partir de OpenGL, en realidad se sobre-entiende que es OpenGL con extensiones para tomar ventaja del hardware de la consola, curiosamente en Wii U y al contrario de lo que yo pensaba que ocurría no existía OpenGL como API de alto nivel y GX2 como API de bajo nivel… Pues no, sino que como ocurre en el caso de PS4 con GNMX en alto nivel y GNM en alto nivel ambas son una misma API siendo la versión de alto nivel una parte de la de bajo nivel, dado que GX2 no es más que una versión vitaminada con extensiones de OpenGL 3.3 y a medida no nos debería extrañar ese detalle, pero hay un elemento que da soporte a dicha teoría y es el hecho que el lenguaje de los shaders de OpenGL  no es el HLSL sino el GLSL, bueno, en Wii U/Cafe se hace servir una versión extendida del GLSL, lo que marcaría el origen en OpenGL de la API GX2.

Captura de pantalla 2016-04-29 a las 15.17.07

Captura de pantalla 2016-04-29 a las 15.18.02

El hecho que GX2 sea una versión con extensiones de OpenGL explicaría el motivo por el cual Nintendo habría adoptado Vulkan de cara a NX, más que nada parece ser que Nintendo adopta APIs gráficas que son estándares abiertos y luego las adapta a bajo nivel y las necesidades de su hardware.

api-vulkan-nintendo-nintendon1 VulkanStatus

Curiosamente Nintendo separa la API de manejo de memoria (DMAE) de la API gráfica en Wii U pero el caso esta en que si Nintendo ha utilizado una versión de OpenGL modificada (la ventaja es que dicha API soporta extensiones y por tanto puedes hacerte un OpenGL a medida) y la política con Vulkan parece ser la misma, es decir, los diferentes fabricantes o poseedores de una plataforma pueden crear sus propios perfiles de Vulkan como ocurre en OpenGL.

VulkanFeatureSets

 

¿Cual es la importancia de esto? Las extensiones como los “Compute Shaders” para Wii U/Cafe están pensadas para ser compatibles hacía adelante y poderse llevar a una GPU más avanzada. Es decir, es muy posible que una GPU con arquitectura GCN tenga soporte completo para GX2 y por tanto en el aspecto gráfico Nintendo lo tenga muy fácil para portar los juegos. Hay que tener en cuenta que la API gráfica es la que comunica la GPU con el hardware gráfico y no tiene porque ser dependiente de un sistema operativo en concreto o incluso de una ISA de la CPU en concreto sino que son elementos completamente independientes, quiero decir que la API GX2 pueden ser ejecutadas una GPU más potente y avanzada que la GPU7 independientemente del conjunto de instrucciones de la CPU (x86, ARM, PPC, MIPS…) o del SO en el que se este ejecutando.

Ahora bien… ¿Como se traslada esto en un hardware más potente? Voy a intentar simplificar esto al máximo pero hay que tener en cuenta que las APIs OpenGL 4/DX11 en adelante trabajan con múltiples contextos, bueno… Si Vulkan es la referencia entonces estamos hablando de trabajar en múltiples listas de comandos en paralelo en vez de una sola.

Vulkan2

Por otro lado y esto no me lo esperaba (y esto es una edición después de hacer la entrada) por lo visto con GX2 se pueden realizar multiples listas de comandos con múltiples CPUs, el problema es que paradójicamente la GPU no esta diseñada para múltiples contextos:

Captura de pantalla 2016-04-29 a las 17.38.55

Esto ayuda enormemente a reducir la sobrecarga provocada por la CPU a la hora de crear las listas de comandos para la GPU tristemente no trabaja con ellas en paralelo:

Captura de pantalla 2016-04-29 a las 17.41.33

¿El motivo que hay detrás de que se puedan crear 3 listas de comandos gráficos distintas? No se trata de listas de computación… Bueno, esto tiene una explicación bien simple…

nintendo-wii-u-gamepad

La consola soporta hasta 2 DRC (nombre del Wii U Gamepad en el SDK de Wii U/Cafe) y se necesitan 3 listas de comandos gráficos, las cuales no van en paralelo, una para la TV, otra para el mando y otra para el hipotético segundo mando que nunca se ha utilizado en ningún juego.

Captura de pantalla 2016-04-29 a las 17.47.55

Es decir, GX2 es una variación de OpenGL 3 pensada para operar a nivel de CPU con múltiples listas de comandos, por lo que esta preparada en un futuro para un entorno multinúcleo a nivel de CPU en que cada núcleo realice una lista de comandos. Pero las dos listas de comandos para los 2 DRC las voy a dejar de lado por el momento y me voy a centrar solo en el pipeline principal que es el de la HDTV. De entrada si en Wii U/Cafe la GPU trabaja con 2 Wavefronts activos de 3, entonces es posible colocar un tercer Wavefront activo para la computación haciendo que sean 3 Wavefronts activos (2 para gráficos y 1 para computación) aunque esa no tiene porque ser siempre la organización y puede ser de 3+0 (Sin computación), 2+1, 1+2 o 0+3. La consola esta pensada para 720P por lo que…

(1920*1080)/(1280*720)= 2.25.

Como no podemos tener shaders parciales esto redondeando serían unos 448 hilos de ejecución simultaneos, o lo que es lo mismo, unas 7 CUs de la arquitectura GCN ejecutando código por lo que si el mínimo sería colocar los juegos de Wii U de 720P a 1080P con un simple cambio de resolución entonces una GPU con 7 CUs es suficiente, si en cambio se busca ir a los 1080P60 desde los 720P30 entonces estaríamos hablando de 14 CUs, pero se ha de tener en cuenta que la GPU7/GX2 funciona a 550Mhz por lo que puede ser que el número de CUs sea inferior a esa cifra de 14 o simplemente con tal de ahorrar en consumo la velocidad de reloj sea inferior.

En todo caso:

1080P30: 448 Shaders*2 (FMADD)*550 Mhz= 0.493 TFLOPS aprox.

1080P60: 896 Shaders*2 (FMADD)*550 Mhz= 0.986 TFLOPS aprox.

Aunque personalmente pienso que Nintendo va como mínimo a cumplir la especificación mínima del Unreal Engine 4 que es 1 TFLOP.

SweeneyTFLOPS

¿El motivo por el cual tomo los 550 Mhz? Ya os lo comentare más adelante en la segunda parte, por el momento quedaos con esto:

Captura de pantalla 2016-04-29 a las 16.09.21

Más que nada porque es un adelanto a la segunda parte.

3DS no va a tener sucesora natural (II)

Comentario original:

¿Y entonces qué pasó con todas las suposiciones de una NX portátil? Según lo que logro entender Nintendo estaría haciendo pruebas con estos juegos que lanzará en móviles para estudiar dicho mercado y sus implicaciones ¿así que lo de la NX portátil sería más bien un móvil que una portátil como las que conocemos? Estoy algo confundido :S.

Antes de nada hemos de tener en cuenta todo lo que le ha llevado a Nintendo a estar en la actual situación en lo que a portátiles se refiere. Para ello antes de nada voy a tomar datos oficiales y por tanto fuentes primarías para realizar una curva de ventas de 3DS para que podáis ver cual es la situación real de la consola y en particular del mercado de las consolas portátiles. Esta entrada es completamente comparativa.

Lo normal es que una curva de producto sea así:

6a01310f54565d970c014e8ab2579e970d-800wi

Pero si pasamos esos datos y hacemos una gráfica lineal tenemos una curva de otro tipo:

Captura de pantalla 2016-04-28 a las 11.51.07

En el caso de DS la curva de ventas, he utilizado la siguiente tabla para ello, en el mismo periodo de ventas fue la siguiente:

Captura de pantalla 2016-04-28 a las 12.15.03

La cual se parece más a una curva de producto normal durante sus primeros años, si las superponemos se ve claramente cual es el problema del comportamiento en el mercado de 3DS:

Captura de pantalla 2016-04-28 a las 12.18.01

En el caso de 3DS la consola empezó mucho más fuerte que DS por lo que esto auguraba a simple vista de que en poco tiempo la consola superaría los 20 millones de unidades anuales vendidas como DS a partir del segundo o tercer año en el mercado. Pero resulta que 3DS realmente no tuvo jamás fase de crecimiento después de la fase de introducción y llego rápidamente a su pico de ventas. Pero… ¿han sido tan malas las ventas de 3DS? Depende del periodo y ese es el problema con el que se ha encontrado Nintendo ya que 3DS en sus primeros años vendió mejor que DS en el mismo periodo y esa situación fue lo que creo el espejismo en Nintendo de un futuro con 3DS igual que el de DS y les hizo apostar por el modelo de negocio tradicional de las consolas portátiles. ¿Y que consecuencias tuvo esto? El hecho que a Nintendo con el formato físico le ha ocurrido lo mismo que le ocurrió a Polaroid en su día que no dio el salto a la fotografía digital por las excelentes ventas de sus cámaras de fotos instantaneas y no vieron incentivo a corto plazo para cambiar.

¿El mayor error de Nintendo en portátiles?

New-Nintendo-3DS-26

New 3DS  debería haber sido un salto generacional pero basado en la distribución digital en vez del formato físico (eso si, manteniendo el slot de tarjetas de 3DS) por los cambios que han habido en el mercado en los últimos años, estamos viviendo en dispositivos embebidos de bolsillo la misma transformación que se vio con el paso del cartucho al CD-ROM. La idea de adoptar la DD no es la de hacer smartphones sino cambiar el modelo de distribución del contenido, New 3DS es una oportunidad perdida, un producto que no debería haber aparecido en la forma en la que lo hizo sino que tendría que haber sido un salto generacional completo respecto a 3DS paliando de base todos los defectos de 3DS. Es decir, Nintendo debería haber lanzado a finales de 2014 una consola que fuese un salto generacional de 3DS pero compatible hacía atrás con la misma, una consola mucho mejor que New 3DS a nivel de hardware que:

  • Tuviese una CPU que fuese un Cortex An como mínimo con mayor capacidad de instrucciones por ciclo que el ARM11 de 3DS.
  • ¿256MB de RAM? No, mejor 1GB.
  • ¿GPU OpenGL ES 1.1? No, lo mejor sería una GPU OpenGL ES 2.0 pero manteniendo la compatibilidad hacía atrás con 3DS, algo que se hubiese conseguido cambiando el PICA200 por el SMAPH-S de la misma marca (DMP) que es el núcleo con soporte OpenGL ES 2.0 en adelante.
  • La pantalla 3D se podría haber mantenido a mayor resolución, Sharp que es la proveedora tiene móviles con el mismo tipo de pantalla a mayor resolución.
  • Pantalla superior capacitativa con tal de poder ejecutar los juegos de móvil que se podrían vender en la eShop.

Por cierto, ayer los creadores del emulador Citra colocaron imágenes comparativas de como se ven los juegos de 3DS a mayor resolución, algo que sería posible con una pantalla de móvil de las actuales, la mejora en la nitidez de imagen por el simple aumento de resolución es espectacular, parece una consola completamente distinta.

super_mario_3d_land_hd.0.0

Grand_Tail_Goomba_-_World_1-1_-_Super_Mario_3D_Land

El hecho de lanzar una 3DS HD de este tipo en 2014 hubiese cambiado las cosas para Nintendo en estos momentos y pese al declive de Wii U tendrían una portátil mucho más fuerte que 3DS en el mercado en estos momentos… ¿Pero acaso no sería adelantar demasiado rápido la nueva generación de portátiles según la sabiduría popular? Estamos viendo como en el mercado de los smartphones cada poco tiempo tenemos modelos nuevos con nuevas especificaciones… ¿Hubiese sido algo malo una 3DS con una pantalla a más resolución y con la capacidad de ejecutar los juegos de smartphones aparte de los de 3DS? Ni mucho menos…  Pero la clave de todo esta como el fenómeno de los smartphones ha cambiado por completo la perspectiva de la gente sobre los dispositivos embebidos de bolsillo y su vida comercial, en especial si tenemos en cuenta como el motivo de que las consolas portátiles no se consuman es porque los padres de los críos cambian rápidamente de smartphone y no por el hecho que el terminal se estropee sino por el hecho que toman interés y adquieren un producto superior y más nuevo dejando como herencia el antiguo smartphone aún plenamente funcional a sus hijos e hijas.

Pero cuando aparece una nueva portátil los early adopters no son los críos, estos simplemente se mueven por modas y no tienen un criterio desarrollado más allá del de la moda, es decir… Nintendo con 3DS vendió mucho entre la gente aficionada a los videojuegos que le gustaban las consolas de Nintendo pero cuando toco la fase de crecimiento se habían dado contra una pared de cristal impenetrable. La mayoría de padres les habían legado sus antiguos smartphones y los juegos F2P permitían o de bajo coste permitían tener distraídos a los críos… ¿Y cual fue la reacción de Nintendo a esto? Hay que tener en cuenta que los planes no se ejecutan de un día para otro, cuando Nintendo ya tenía en producción la New 3DS sus planes de futuro aunque estaban desarrollados en otro sentido no podían hacer cambiar el desarrollo y lanzamiento del producto por lo que como he dicho antes Nintendo se vio engañada por el éxito de su propio producto en los primeros años y esto es lo que le impidió tener margen de maniobra.

Iwata presento el plan de negocio basado en el QoL en Enero de 2014, New 3DS salió a finales de ese año por lo que su producción y plan de lanzamiento ya se estaban ejecutando. La idea del QoL mucha gente no la entiende pero no es otra cosa que Nintendo haciendo un dispositivo de proposito general, es decir… Que no solo tenga aplicaciones lúdicas sino también de otro tipo. De ahí la comparación de Iwata en su día con iOS y Android y de ahí la siguientes diapositivas:

original 50l

A nivel de plataforma de software, Sistema Operativo, no tiene sentido que Nintendo realice dos plataformas cuando puede realizar una sola para ambas cosas, al fin y al cabo lo del QoL en realidad no es un océano azul, ya lo estamos viendo en el caso de Apple e iOS con diferentes tipos de aplicaciones como por ejemplo la aplicación de salud que ha sido integrada en lo últimos iOS, el problema es que desde el momento en que los smartphones tienen esto de serie no resulta una ventaja y no suma a no ser que el plan de Nintendo sea tener una plataforma de propósito general que vaya más allá de una plataforma de juegos, es decir… La transformación de Nintendo de una empresa de consolas de videojuegos e idems a una empresa al estilo Apple.

Pero la pregunta es… ¿Significa esto que Nintendo va a lanzar su propio smartphone? No lo se, pero es una posibilidad, en el 2014 en uno de los sets de preguntas con los inversores Shigeru Miyamoto dejo ir los siguiente:

No puedo predecir lo que ocurrirá en diez años. Pero es verdad que tengo la sensación de miedo que los “Smartphones que se heredan” como ha apuntado otro accionista, se están convirtiendo en sistemas de hardware en los que jugar a juegos debido a que sus precios son más bajos que el sistema más barato en nuestra historia.

Es decir, Nintendo conoce el problema con el que se enfrentan, pero aún hay más y la siguiente parte es muy interesante:

Tomando en consideración que más y más niños tienen un buen control de esos tipos de medios (smartphones), lo cual ayuda que esos medios se escampen, la tarea más importante para Nintendo es como proveer nuevos estilos de entretenimiento utilizando esas tecnologías, y como hacer que esas nuevas formas de entretenimiento traigan importantes ventas y beneficios.

Esto es de 2014… ¿Y que tuvimos al cabo de un año?

pokemon-go-miyamoto

Pero Nintendo se enfrenta a un problema enorme, el hecho de que el mercado de los smartphones en estos momentos es un mercado altamente competitivo y Nintendo no tiene las habilidades desarrolladas para ser competitiva frente a Apple y Google, incluso tiene carencias para competir en el mundo de los videojuegos frente a Microsoft y Sony… El salto cualitativo de las capacidades de Nintendo resulta una montaña enorme que tiene que atravesar y es mucho más compleja que hacer un nuevo sistema de videojuegos dedicado pero lo importante aquí es el timing, desde el lanzamiento de la DSi hemos ido viendo como Nintendo realiza sus nuevas propuestas en cuanto a portátiles cada tres años por lo que la siguiente propuesta vendría en 2017… ¿Y en que forma vendría? Pues en forma de smartphone con el SO de Nintendo de forma integrada para entrar en dicho mercado.

7170124_nintendo-patent-for-crazy-controller-hints_c6765657_m

 

Pero el lanzamiento de una plataforma de este tipo requiere unas políticas distintas que el lanzamiento de una consola de videojuegos bajo el modelo tradicional y por tanto una estrategia diferente, los cambios más importantes vendría a ser:

  1. La plataforma deja de estar definida por un hardware en concreto para estar definida por el SO.
  2. La distribución deja de ser física, cartuchos, para pasar a ser digital y con el control exclusivo de la misma del poseedor de la plataforma.
  3. Libertad de precios, la regalía del poseedor de la plataforma pasa de ser fija a ser porcentual.

Al igual que ocurrió con DS donde primero se hizo un test del mercado el smartphone de Nintendo será lanzado como una prueba mientras 3DS continuará recibiendo juegos y dependiendo del éxito que tenga reemplazará al negocio de las portátiles de Nintendo o no. Hay que tener en cuenta un detalle importante, Nintendo si llega a dicho mercado lo va a hacer no como pionera ni emigrante sino como colona:

pms-map

En el caso de los smartphones actuales los que llegaron tarde (caso Microsoft y Blackberry) se han quedado con una porción minúscula del mercado de los smartphones, una porción que esta muy lejos de poder llegar al 10%… ¿Que es lo motiva a Nintendo a dar el salto? Lo he comentado antes pero en especial el hecho de que el mercado de la consolas portátiles se esta desintegrando y a medio plazo pasará a ser menos interesante para Nintendo que el de los smartphones. Es igual que tengan un enorme éxito, es como ser los reyes de una isla que se va marchitando poco a poco y pronto morirá. El gran error de Nintendo fue 3DS y ahora pese a su enorme éxito la consola reina sobre un reino desolado del que todo el mundo ha huido.

Sacar una nueva portátil para Nintendo en 2014 tenía cierto sentido, pero en la situación actual y en 2017 no, de ahí a que busquen transformar el negocio.