NX… Opción ARM en AMD

Una de las cosas que se han añadido en esta generación de consolas son las GPUs müulticontexto/multihilo en la que el potencial de estas no solo se puede utilizar para gráficos sino para otras tareas también, las cuales entran dentro del contexto “Computación” y en el que la GPU actúa como coprocesador de la CPU y por tanto en el espacio de memoria de la misma.

¿Pero que entendemos como espacio de memoria? Muchos pensarán en memorias locales para cada procesador, que es lo que existe en el PC:

02-direct3-dpipeline-4-638

Pero el concepto no tiene que ver con lo físico ya que pueden existir memorias fisicamente unificadas pero con diferente direccionamiento. Es como si en un mismo vecindario hubiesen dos empresas de correos y cada una de ellas tuviese un sistema de direcciones distinto a la hora de llevar las cartas a cada casa. ¿Que es lo que ocurre en los sistemas de hoy en día? Pues que esto tienen dos espacios diferenciados, uno de ellos es el local para los gráficos y el otro es el de la CPU donde la GPU puede acceder para hacer tareas de computación como co-procesador.

El elemento utilizado por los SoC de AMD para comunicar los diferentes componentes entre si y estos con la memoria es el llamado “uncore”. Estos se encuentran solamente en los SoCs/APUs de AMD por el hecho que su existencia solo se da en este tipo de procesadores ya que cuando los elementos están separados son los elementos repartido por la placa base los que se encargan de hacer la tarea del uncore:

KaveriUncore

Cuando la GPU esta en contexto gráfico lo que hace es acceder a la memoria a través del bus Garlic desde el GNB (Graphics Northbridge) y cuando necesita entrar en modo “Computación” lo hace accediendo desde el GNB al UNB (Universal Northbridge) para leer tanto el espacio de memoria de la CPU como para poder comunicarse directamente con la CPU. ¿Pero como se comunica con el espacio de memoria de la CPU? Fácil, es capaz de leer el sistema de direcciones de la CPU, en este caso es el x86-64.

¿Pero que ocurre cuando queremos poner una CPU con conjunto de instrucciones ARM? Pues que básicamente tenemos que hacer que la GPU pueda entender el direccionamiento de memoria de las CPU ARM y es aquí donde entra el cancelado Styx/Amur, un SoC de AMD a 20nm que recibió el nombre de Skybridge en el marketing.

amd-project-skybridge-arm-x86-640x360

En el mapa de ruta era conocido como Amur y su sucesor se le llama Styx, fijaos como Styx va a llevar un AMD K12.

AMD_ARM_Roadmap

¿El problema del K12? No lo vamos a ver como muy pronto hasta 2017 y si Nintendo ya esta repartiendo los SDK de NX y lleva un ARM esto significa que no lleva un K12 sino que posiblemente un A57.

AMDK12_678x452

No olvidemos como funciona el negocio de los chips a “medida” de AMD, los cuales son montados como piezas de lego entre si para conseguir diferentes configuraciones. Algo que ya hemos visto en PS4 y Xbox One, algo que podríamos ver en NX pero esta vez que un SoC/APU a 16nm FinFET (TSMC) utilizando no en el AMD Zen ni tampoco el K12 sino un núcleo ARM como el Cortex A57 como CPU y una GPU AMD GCN 2.0.

AMD-Roadmap-2016-720x380

Sobre el proceso de 16nm de TSMC podemos leer:

La tecnología 16FF (FinFet Plus) de TSMC puede proveer un 65% de velocidad adicional, sobre dos veces la densidad o un 70% menos consumo que la tecnología 28HPM.

Es decir, si el SoC de Xbox One…

XBox_One_SOC

Se realizara a unos 16nm FF+ entonces el área que pasaría a ocupar sería de 181.5 mm^2 aproximadamente, no obstante el reducir un chip de tamaño de forma directa no se puede realizar así como así… ¿Y a que viene hablar del chip de Xbox One en una entrada sobre NX? Tenemos que tener en cuenta la conectividad con la memoria externa, es decir, los pines de señal que están por la parte externa del procesador que no pueden se reducidos con la disminución del tamaño de un chip.

die1

Si miramos la litografía de Xbox One (DDR3) y la comparamos con la de PS4 (GDDR5) veremos como el controlador de memoria es distinto y con ello el número de pines interconectados y el area ocupada por estos.

Teardown-Xbox-One-processor-die-2

ps4-reverse-engineered-apu

Los 256 bits de memoria GDDR5 ocupan un espacio mucho mayor que los 256 bits de memoria DDR3 por el hecho de necesitar una cantidad mucho mayor de pines. ¿Y que importancia tiene esto? Pues que si reducimos el tamaño del chip tenemos que reducir el número de pines, con ello el ancho de banda de la memoria y entonces nos encontramos con un problema desde el momento en que las GPUs son procesadores de caudal que requieren de un ancho de banda concreto para funcionar. Si reduces el ancho de banda entonces el rendimiento baja por lo que tienes una GPU muy potente desaprovechada por lo que al final acabas por colocar una versión con menos unidades de procesamiento cuyo rendimiento se pueda aprovechar al 100%.

Ya he dicho muchas veces que la preferencia de Nintendo es la creación de sistemas donde el número de chip de memoria sea el más bajo posible, esto significan menos pines y chips por lo tanto más pequeños. ¿La forma clásica de evitar esto? Memoria embebida que se puede encontrar tanto en el mismo chip (caso de Xbox One), como dentro del mismo encapsulado pero comunicado a través de un sustrato/interposer como ocurre en los Intel Iris de gama alta…

intel-haswell-gt3-01

… y ocurría con la GPU/Soc de Xbox 360:

Xbox 360 GPU ATI  X02056 Xenos (r500) 01

Pero la forma de utilizar la memoria embebida tiene que evolucionar. Tradicionalmente se utilizaba para almacenar el búfer de imagen y darle a los ROPS el suficiente ancho de banda pero esta función única tiene una contrapartida y es que hoy en día se necesita la misma velocidad de lectura que de escritura ya que el ancho de banda de la lectura es igual de importante y es precisamente ese el problema que tiene la ESRAM de Xbox One, esta pensada para almacenar el búfer de imagen trasero (backbuffer) pero no esta pensado para almacenar las texturas de la escena, es decir, su mecanismo es diferente al que utiliza Nintendo en sus consolas donde la memoria embebida no solamente sirve para el búfer de imagen sino también como cache de texturas.

¿Y que entendemos como cache de texturas? Es donde almacenamos las texturas que se operan en estos mismos momentos, en el caso de las GPUs actuales hay varios niveles de cache siendo la cache L1 la que se encuentra en los shaders y la cache L2 la cercana al controlador de memoria de la GPU pero en ciertos sistemas la cache de texturas tiene el suficiente tamaño como para poder almacenar todas las texturas en pantalla en ella… ¿Y cuantas texturas vamos a necesitar? Pues no más que el tamaño de la pantalla y es por ello que solamente hace falta volcar esas texturas en una memoria intermedia con el tamaño de un búfer de imagen de la que leera la GPU directamente sin tener que acceder a la memoria principal. ¿Las consecuencias de este diseño? El recorte de la cantidad de pines externos del chip al no necesitar un ancho de banda tan grande con la memoria.

A partir de aquí voy a desbarrar, hay una patente de AMD donde se describe el uso de memoria HBM como cache L3 compartida entre una CPU y una GPU en un SoC.

919423-14048427397300363-raghunathan78

Captura de pantalla 2015-10-28 a las 12.29.35

El diseño es con un solo chip de memoria HBM y por tanto con una sola interfaz HBM, por lo que no estamos hablando de un mastodonte como el AMD Fiji que utiliza cuatro chips HBM sino de un chip mucho más pequeño.

samsung_chysta_pameti_hbm2_na_zacatek_pristiho_roku_idf_2015_02

Supongamos que la configuración mínima es la elegida con 2GB de densidad y por tanto dos chips de memoria de altura. Esta marcada en el gráfico siguiente como GFX MS que significa Graphics Mainstream por lo que es memoria pensada para el mercado de masas y por tanto de consumo, el problema es que existe una errata en este caso ya que la memoria HBM de dos alturas al tener menos chips tiene un ancho de banda menor al utilizar menos pines, los datos del cuadro de abajo son con memoria HBM a 1Ghz:

normal_HBMmemory-Wccftech2611-1-1

El uso de memoria HBM de 512 bits marca que el número de pines será 1/8 de la HBM de 4 chips a 4096 bits que utiliza el AMD Fiji y es equivalente a la GDDR5 de 512 bits en cuanto al número de pines por lo que la configuración utilizada con un SoC conectado a memoria HBM2 2-Hi utilizaría una cantidad de pines relativamente pequeño para conseguir un ancho de banda que iría desde los 64GB/seg a los 128 GB/seg (1Ghz a 2Ghz de velocidad de la memoria).

Dado que la memoria HBM es variable en velocidad no sabemos que tipo de configuración se puede colocar en este sistema, pero lo que si que sabemos es que con 2GB de memoria en su configuración mínima es mas que suficiente como para poder almacenar el búfer de imagen y la cache de texturas sin problemas y es un salto importante desde los 32MB de la MEM1 de Wii U. ¿Pero que tal es su rendimiento como memoria? Hay que tener en cuenta que la MEM1 de Wii U funciona a 70.4 GB/seg (35.2 GB/seg de lectura y 35.2 GB/seg de escritura) y opera con 8 ROPS a 550 Mhz y no podemos olvidar que la memoria externa es muy importante de cara a la configuración de ROPS y la velocidad de reloj de la GPU, esto se ve fácilmente con la siguiente información de Xbox One:

HumuseDRAM

Los ROPS de la arquitectura GCN pueden escribir unos 8 bytes por ciclo de reloj, es por ello que la velocidad de escritura máxima de la ESRAM de Xbox One es de unos 109 GB/seg porque ese es el ancho de banda necesario para mantener la tasa de relleno lo más alta posible. Esto es importante porque dependiendo del ancho de banda de la memoria la velocidad de reloj y/o el número de ROPS será uno u otra y en consecuencia el número de Compute Units de la GPU será uno u otro.

Xbox One utiliza cuatro RB, cada RB integra unos cuatro ROPS en su interior hasta llegar al máximo de 16, pues bien, existe una correlación entre el número de CUs y el número de RB en las arquitecturas GCN donde hay un máximo de 4 CU por RB:

AMD-Tonga-XT-Block-Diagram

Esta diagrama es del AMD Tonga que tiene un bus GDDR5 de 256 bits y un total de 32 ROPS y 32 Compute Units. Si nos vamos hacía arriba, hacía el Fiji veremos que el número de RB sube y con ello el de Compute Units.

Fiji

Tenemos 16 RB para 64 Compute Units (CUs) y una interfaz de memoria externa de 4096 bits, dado que la interfaz externa de la que hablamos es de 512 bits (siendo conservadores) entonces por regla de tres tendremos 512 bits con la memoria externa (2-Hi HBM), 2 RBE y unas 8 Compute Units en total con esta configuración y en el caso de la configuración de 1024 bits entonces la configuración pasaría a ser de 1024 bits con la memoria externa HBM (4-Hi u 8-Hi), 4 RBE y unas 16 Compute Units. Claro esta que el tamaño de ambos procesadores no sería el mismo. La segunda configuración permitiría la configuración de 8GB y en ese caso no haría falta la memoria externa, eso si, el chip tendría el doble de área y Nintendo no suele trabajar con esas áreas en sus consolas.

Volviendo al tema del SoC como podéis ver en este caso la configuración de la GPU no cambia con el cambio de CPU en lo que al esquema general se refiere. Básicamente la idea de colocar un A57 es porque consumen menos, ocupan menos y porque no sabemos el nivel de integración del Zen en estos momentos y el K12 no llegara a tiempo, es decir, estamos ante un escenario mixto, el cual es casi igual al de la Opción A excepto en la CPU utilizada.

En todo caso tengo que dar las gracias a Xarman por plantear un escenario que no se me había ocurrido hasta ahora:

Veo a miyamoto diciendo que mostrará los mismos gráficos que ps4 a 720p…

Ademas a 720p la edram cunde mas del doble asi que no hace falta que “fuercen” tanto la ddr3 buscando casi 70 gbps como en one (es decir, mitad de ancho de banda y de chips que one, de mayor densidad)

No habria problema con los multis si simplemente buscan 720p en vez de full hd

Y viendo el pedazo de mierda que son los jaguars (y mas a frecuencia de mpvil de gama media) no me preocupa el tema de cpu, probablemente a 16 nm y mas de 2 ghz como algunos moviles rinda lo mismo o mas la cpu de NX

Lo de los 720P no lo había pensado, el caso es que PS4 esta pensada para 1080p30 principalmente como resolución estandar de los juegos (pueden ir a 60 pero los 30 se tienen como referencia cuando el nivel visual es preferible), pues bien, haciendo un simple cálculo nos sale la cantidad de FLOPS por pixel.

(800000000 * 18*64*2)/(1920*1080*30)= 29629,6296296

Redondeando son 30.000 operaciones por pixel. a 720p30 esto son:

1280*720*30*30000= 830 GFLOPS.

Lo cual es curioso porque es una cifra muy cercana a la del AMD Carrizo.

2015-06-03-image-2

Pero hay un detalle, Miyamoto dijo que la potencia de Wii U es suficiente… ¿cual es la potencia por pixel de Wii U?

(550000000 * 8*20*2)/(1280*720*30)= 6365.74074074

Es decir, unos 6366… ¿Que ocurre si queremos colocar los gráficos a 1080p60? Pues que necesitaríamos la siguiente potencia:

6365.74074074*(1920*1080*60)= 792 GFLOPS.

Es decir, Nintendo puede estar persiguiendo la misma calidad de imagen que Wii U pero a una mayor resolución viable en el mercado de masas (1080P60) pero al mismo tiempo querer versiones de los juegos de PS4 y Xbox One para NX y el punto de encuentro no es renderizar estos a 1080p ni tampoco a 900p sino a 720p. Obviamente esto significa que muchos se tiraran de los pelos porque el escenario de Wii U se repetiría en cuanto a los juegos de terceros, pero mejor esto que un cutre chip de móvil.

En fin, creo que he desbarrado demasiado ya.

 

Anuncios