NX Opción A.

He estado unos días de vacaciones y me ha servido para ordenar ideas, no solo de temas que trato en el blog sino en muchas otras cosas, es decir, de poner a juicio mis ideas.En esta entrada voy a especular sobre la naturaleza de la APU/SoC de NX, tened en cuenta que esto no es un documento oficial sino que es simple y llanamente especulación informada acerca de como puede montar Nintendo el sistema a nivel de hardware. Antes que nada aclarar que en esta entrada estoy hablando de la opción A, es decir, la que tiene más números y consiste en una APU/SoC de AMD y que estoy seguro que algunas de las cosas ya las habéis visto en otras entradas, he pensado que estaría bien ordenar ideas y dar un planteamiento completo sobre uno de los posibles escenarios en cuanto al hardware de NX.

Os aviso antes que nada que la entrada es larga y no deja de ser un ordenamiento de varias ideas que circulan por mi cabeza, es decir, mientras escribo esto tengo una serie de cartas sobre la mesa.

En esta entrada veréis cosas que he comentado con anterioridad, pero esta entrada como he dicho antes es para poner a juicio los diferentes planteamientos posibles sobre la opción A.

#1 ¿APU o SoC?

Aunque puede parecer banal, esta pregunta es importante.

Tecnicamente un SoC es un chip que engloba todos los sistema lógicos de un ordenador en un solo chip, la diferente entre una APU y un SoC es que la APU no incluye los mecanismos de E/S para periféricos, es decir, los controladores SATA, USB… En cambio un SoC si que los incluye. En el caso de PS4 y Xbox One ambas consolas tienen una APU acompañadas de un chip secundario encargado del manejo de la E/S, esto además ha sido común en todas las APUs de AMD de escritorio de gama alta, dejando los SoC solo para la gama baja hasta hace poco con la nueva generación de APUs que son SoCs completos.

¿Qué es lo que me hace pensar en un SoC completo? Pues dos motivos:

  1. Desde N64 que Nintendo ha englobado en un mismo chip GPU+Controlador de Memoria+Controlador de E/S. Por lo dejar esta último fuera de la ecuación no tiene sentido si estamos hablando desde el punto de vista tradicional.
  2. Un chip adicional en la consola significan costes adicionales, en un sistema doméstico todo lo que se pueda hacer para reducir costes dentro de lo posible bienvenido sea.

Así pues creo que la opción más viable aquí es pensar en un SoC para NX y no en una APU+Chip Secundario, esto que por el momento es banal es importante de cara al siguiente punto.

#2 El Uncore

Se le llama Uncore a esa parte del SoC que no forma parte de la CPU ni la GPU, ni de la E/S pero que tiene el importante trabajo de comunicar estas partes entre si y estas con el controlador de memoria, el cual los comunicara con la RAM del sistema.

Actualmente en los SoC/APU de AMD tenemos dos tipos de uncore, dependiendo si integran el IOMMUv1 o el IOMMUV2, los que integran el IOMMUv1 tienen un esquema como el siguiente:

De forma resumida:

  • Un bus coherente entre GPU y CPU llamado Onion/Fusion Compute Link que comunica la CPU y la GPU de forma directa y que es utilizado por la GPU operaciones donde esta hace de apoyo a la CPU y por tanto ha de escribir en el espacio de memoria de la CPU.
  • Un bus no-coherente de la GPU con la memoria, GARLIC/Radeon Memory Bus, que le permite a la GPU coger todo el ancho de banda de la RAM si es necesario

Las APU/SoC con el IOMMUv2 tienen la siguiente configuración:

  • Otro bus coherente entre GPU y CPU llamado Onion+, más lento que el primero en ancho de banda pero que permite comunicar directamente con la CPU sin tener que pasar por los niveles de cache.KaveriUncore
  • Soporte de direccionamiento heterogeneo de memoria unificada, aka hUMA.

huma_03 huma_02

¿Sistemas que soportan IOMMUv2? Kaveri, Carrizo y Liverpool (PS4). ¿Sistemas que soportan IOMMUv1? La APU de Xbox One y el resto de APU/SoC de AMD en el mercado.

Según como sea la configuración de memoria de NX el sistema tendrá un IOMMU u otra, pero el IOMMUv2 no es compatible con dos pozos de memoria distintos a diferentes niveles y con accesos diferentes. Aunque eso ya lo veremos más adelante en la entrada, quedaos con este dato por el momento porque es importante.

#3 La memoria

Este tema es el más delicado de todos y complejo de todos .

En PC las GPUs incluidas en las APUs/SoC tienen un cuello de botella enorme por el hecho que el ancho de banda asociado a las mismas no es lo suficientemente grande para que su rendimiento sea del 100% y por tanto no es comparable a una GPU dedicada.

No hay que olvidar que las GPUs son procesadores de caudal y su rendimiento depende de tener un caudal de datos adecuado a la hora de procesar los datos. Para solventar este problema tanto Sony como Microsoft han optado por soluciones a la memoria diferentes al PC, estas son:

  • Una interfaz GDDR5 de 256 bits para PS4.
  • Una interfaz DDR3 de 256 bits para Xbox One y unos 32MB de memoria SRAM embebida dentro del chip.

La contrapartida de esto es que cuanto más ancho de banda tenga el sistema mas pines se necesitan para la intecormunicación y más grande y caro es el chip y no solo eso, necesitamos una mayor cantidad de chips de memoria de la placa base y eso va en contra de la filosofía de Nintendo. La cual es de reducir en el máximo posible el número de chips de la placa base utilizando memoria embebida, claro esta que con Xbox One hemos visto como la memoria embebida ha llegado a ser insuficiente en cuanto a densidad para los tiempos que corren, y es aquí donde aparece una solución perfecta que engloba los mejor de los dos mundos, me estoy refiriendo a la memoria HBM.

  • En primer lugar los chips de memoria HBM ocupan muy poco espacio, en comparación con otros chips como los chips GDDR5 y DDR3/DDR4.
  • En segundo lugar consumo mucho menor que la memoria GDDR5.
  • En tercer lugar no tiene que incluirse dentro del chip, por lo que no hay un aumento de area del mismo por incluirlo o no vemos parte del area ocupada por la memoria embebida, que en el caso de Xbox One y Wii U tal y como se puede ver en la litografía de sus chips es enorme.

Por ahora el único chip en el mercado que utiliza memoria HBM en estos momentos es el AMD Fiji,

Tiene una enorme área de unos 596mm^2, lo cual es una area enorme propia de GPUs de gama alta en PC y fuera de lo que se puede permitir una consola doméstica, pero no nos podemos olvidar que en el caso del AMD Fiji…

  • Estamos hablando de un sistema que utiliza cuatro chips HBM1 y por tanto tiene una interfaz de 4096 bits (1024 bits por chip).
  • Su ancho de banda es de 640GB/Seg, unos 160 GB/seg por chip, para NX no necesitamos estas barbaridades y con un chip de memoria HBM nos sería suficiente.
  • Dado que el tamaño del chip depende de las interfaces de memoria, reducir el número de chips HBM reduce el número de estas interfaces y podemos configurar sistemas con chips mucho más pequeños.

Dicho de otra manera, podemos tener un sistema con un solo chip HBM que ocupe un tamaño viable para una consola y tenga un ancho de banda utilizando memoria HBM de 160GB/seg si se utilizará la memoria HBM1, no obstante la memoria HBM de primera generación tiene el problema de tener una densidad de solo 1GB por chip por lo que haría falta una memoria externa adicional en la placa base como compensación, por suerte a nivel de fabricación ya hay disponibles chips HBM de segunda generación o HBM2, los cuales pueden alcanzar hasta los 8GB por chip y en ese caso no necesitariamos realmente más que esa cifra y por tanto esto descartaría el uso de un segundo pozo de memoria para tener la densidad adecuada.

Por lo que tenemos dos escenarios:

  • HBM1+DDR3/DDR4.
  • HBM2.

El primer escenario trae consigo una serie de problemas asociados, ya de entrada el simple hecho de utilizar dos pozos de memoria diferenciados supone el añadido de una serie de mecanismos adicionales e interfaces en el chip.

  • Un/os controlador/es de memoria adicional para acceder al segundo pozo de memoria y por tanto una interfaz de memoria adicional para la segunda memoria.
  • Un mecanismo DMA más complejo, con dos canales para pasar datos de una memoria a otra sin gastar ciclos de reloj del procesador.

En el segundo caso (HBM2) desde el momento en que CPU y GPU tendrían la memoria 100% unificada a un solo nivel entonces no harían falta dichas interfaces y mecanismos. Hay que aclarar además que la configuración con la memoria HBM2 sería la que dispondría de IOMMUv2 en el chip y por tanto tendría a su disposición el bus Onion+ y el soporte para direccionamiento hUMA.

Es decir, dependiendo de cual sea la configuración de la memoria el chip tendrá un uncore u otro.

#4 CPU

Tanto Carrizo como Kaveri utilizan CPUs de AMD de gama alta, los chips de Xbox One y PS4 utilizan CPUs de gama baja, los que correponden a la serie “Felina” de AMD y que en PC se utilizan en SoCs de gama baja.

En el caso concreto de las consolas de la competencia tenemos dos módulos Jaguar de cuatro núcleos cada uno a 1.6Ghz y con 2MB de cache L2 por modulo compartida..

¿Diferencias entre Puma+ y Jaguar a nivel de núcleo? Estamos hablando de la misma arquitectura y el mismo nodo, en realidad Puma+ es un rebranding del AMD Jaguar para hacerlo pasar por un chip nuevo (cosas del marketing). Por lo que una configuración con dos modulos Puma+ es lo mismo que una configuración con dos módulos Jaguar o lo que es lo mismo, una configuración con 8 núcleos Puma+ seria lo mismo que una configuración con 8 núcleos Jaguar a efectos prácticos. Es más, dado que Nintendo anda obsesionada con el consumo energético no creo que apuesten por las CPUs de gama alta y de alto consumo de AMD, sobretodo cuando no buscan adelantar a Sony y Microsoft

Una vez elegida la CPU hay que recordar una particularidad de la CPU de PS4 y Xbox One, la cual es la misma. Esta funciona al doble de la velocidad de reloj que la GPU, 1.6/0.8 para PS4 y 1.7/8.5 para Xbox One. Lo mismo podría ocurrir con el procesador de NX, ¿pero cual es la velocidad de reloj que puede tomar la GPU en NX? Es aquí donde entramos en el juego de la eliminación y es aquí donde entramos a uno de los elementos más peliagudos.

Tradicionalmente, la forma de utilizar la memoria por parte de Nintendo es que la CPU tenga acceso a todos los pozos de memoria del sistema, es decir que la CPU tenga acceso a la MEM1 (Memoria Interna) y la MEM2 (Memoria Externa), el escenario que corresponde a la forma en la que tradicionalmente Nintendo hace sus consolas es dela HBM1+DDR3/DDR4, en este caso la HBM1 sería lo que tradicionalmente Nintendo llama en la descripción de sus patentes como MEM1 y a esta tiene acceso tanto la CPU como la GPU. Esto es muy importante y complejo de explicar y lo intentare hacer lo mejor que pueda.

La única consola de la actual generación, a nivel técnico, con dos pozos de memoria diferenciados es Xbox One gracias a su uso de memoria SRAM embebida, si miramos el diagrama general del sistema veremos que dicha memoria en teoría puede ser accedida por la CPU:

XBox_One_SoC_diagram

Hay una linea negra muy fina que comunica la CPU con la ESRAM, no obstante, los propios arquitectos de la consola dicen lo siguiente:

ESRAMCPUSLow

En realidad esto no tiene nada de malo, son planteamientos distintos el de Microsoft y el de Nintendo, es más, no es de extrañar que el acceso a la ESRAM sera lento en el caso de Xbox One por parte de la CPU, solo hay que ver como esta esta conectada a la GPU y no solo se ve en el diagrama de arriba sino en la litografía del chip.

Teardown-Xbox-One-processor-die-2

En cambio en el caso de Wii U se puede ver como la CPU tiene acceso directo a la MEM1/eDRAM, solo hay que ver donde esta colocada la interfaz que comunica el Latte con el Espresso/CPU en el caso de Wii U.

wiiudie_blocks

En el caso de las APU/SoC utilizados hasta ahora solo hay un pozo de memoria externa al chip, el caso que nos ocupa significaría trabajar con dos memoria distintas, lo que complicaría de mala manera el uncore del SoC del que estamos hablando ya que haría falta duplicar los mecanismos para el acceso a la memoria, lo que significaría menos espacio disponible para otros elementos dentro del SoC.

¿La mejor solución al problema?

tableflip02

La mejor solución a este problema es optar por el escenario con la memoria HBM de segunda generación, la cual tiene suficiente densidad como para no tener que optar por ningún tipo de memoria externa, es decir que por ahora la cosa quedaría de la siguiente manera:

  • CPU: 8 núcleos Puma+ (velocidad indeterminada).
  • Uncore: Con soporte IOMMUv2 (Onion+, hUMA).
  • Memoria: 8 GB HBM2 (velocidad indeterminada).

#5 Los Render Backends/GPU

Dado que en las APUs/SoC de AMD la GPU puede quedarse con todo el caudal de ancho de banda cuando les es necesario (gracias al GARLIC/Radeon Memory Bus) y el ancho de banda de la escritura esta relacionado con los ROPS de la GPU que los encargados de escribir en el búfer de imagen, entonces esto nos puede dar una idea de cual puede ser la naturaleza de la GPU y su configuración.

Los RBE son mecanismos de la GPU de AMD encargados de escribir en la memoria asignada a la GPU para generar los búfers de imagen. Sus carácteristicas son las siguientes:

  • Cada ROP puede escribir por ciclo de reloj hasta unos 8 bytes, es decir 64 bits o lo que es lo mismo RGBA con hasta 16 bits por componente. Esto se ve en el modo solo escritura de la ESRAM de Xbox One que tiene el ancho de banda justo para 8 bytes por ROP.
  • Teniendo en cuenta los dos puntos anteriores, cada uno de los RBE necesita un ancho de banda de escritura de unos 32 bytes (256 bits) por ciclo de reloj de la GPU.

Ahora bien… ¿Cuántos RBE puede tener una GPU conectada a un chip de memoria HBM? La respuesta la tenemos en el diagrama del AMD Fiji donde vemos unos 16 RBE en total, 4 por cada chip HBM y en este caso hablamos de un solo chip HBM por lo que la configuración de 4 RBEs concuerda perfectamente con una configuración con un solo chip HBM2

Fiji

¿Pero a que velocidad iría la HBM2? La respuesta esta en la  siguiente diapositiva.

HBMN

La cual sitúa la velocidad de la HBM2 entre los 1.6 y los 2Gbps. Estas cifras por el momento las tenemos que coger con pinzas pese a venir del fabricante de dichas memoria, pero 1.6 Gbps es memoria HBM a 1.6Ghz con un ancho de banda de 204.8 GB/seg, 102.4 GB/seg para escritura. Teniendo en cuenta lo que he explicado antes, ese ancho de banda nos da para una GPU con 4 RBE a 800Mhz, por lo que ahora tenemos un poco más de información.

  • CPU: 8 núcleos Puma+ a 1.6 Ghz.
  • Uncore: Con soporte IOMMUv2 (Onion+, hUMA).
  • Memoria: 8 GB HBM2 a 1.6 GHz (204.8 GB/seg de ancho de banda).
  • GPU: 800Mhz AMD GCN 1.1+ con 4 RBE.

#6 Compute Units/GPU

No voy a entrar en la naturaleza de estas, en lo que si que voy a entrar es en el equilibrio entre el número de Compute Units y el número de RBEs en la arquitectura GCN 1.1 en adelante, cuyo número máximo es de 4 Compute Units por RBE tal y como se puede ver en los diagramas del AMD Fiji y del AMD Tonga.

Esta configuración de 4 CUs maximo se ve en diferentes GPUs contemporaneas de AMD, no solo en el AMD Fiji que os he mostrado arriba sino que también se puede ver en en el AMD Tonga y el AMD Hawaii.

AMD-Tonga-XT-Block-Diagram

Pero no es un número fijo ya que hay GPUs y APUs de AMD que no cumplen este configuración y hay una configuración irregular en muchos de los chips de AMD, es decir, hay APUs y GPUs donde cada RBE no tiene el mismo número de Compute Units respecto a otros en el mismo chip pero si que sabemos que una configuración con 4 RBEs como mucho tendría 16 Compute Units, aunque la cifra podría ser perfectamente más baja que esos 16 y no sabemos en ningún momento cual será.

Por lo que la cosa al final quedaría así:

  • CPU: 8 núcleos Puma+ a 1.6 Ghz.
  • Uncore: Con soporte IOMMUv2 (Onion+, hUMA).
  • Memoria: 8 GB HBM2 a 1.6 GHz (204.8 GB/seg de ancho de banda).
  • GPU: 800Mhz AMD GCN 1.1+ con 4 RBE y 16 Compute Units.

Gracias por vuestro tiempo, esto es todo.

Anuncios