Como bien sabreis los lectores, hace unos meses aparecieron referencias a un chip de AMD con el nombre en clave «Gonzalo», el cual fue descubierto por el «tuitero» TUM_APISAK.

El chip no tendría nada de especial si no fuese por la G como segunda carácter, lo que marca que es un chip dedicado al gaming y por tanto para una consola. Normalmente los chips diseñados para consolas no se suele filtrar el código interno de AMD, pero la G resulto significativa por lo que significaba.

En medio de la discusión original de hace unos meses alguien comento que el IGP (Internal Graphic Processor) tenía el nombre en clave «Ariel».

¿De que nos suena Ariel? Ah si, ya lo habíamos visto en la lista de IDs de periféricos PCI relacionados con AMD:

Y como se puede ver, la parte del código que dice 13e9 hace referencia a la GPU. Pues bien, el mismo TUM APISAK aviso hace unos días que el chip ha recibido una actualización que es cuanto menos destacable:

Para empezar el primer carácter ha pasado de ser un 2 a Z lo que marca una versión más avanzada del prototipo respecto al chip de hace unos meses, pero lo realmente importante es ver como el código de la GPU ha pasado de ser 13e9 a 13f8 por lo que esto significa que ha habido un cambio de GPU en estos meses. Se supone que lo de 18_13f8 hace referencia a que una GPU 13f8 ejecutandose a 1.8 Ghz, lo cual es una exageración para un SoC. El otro cambio del que TUM APISAK habla es en cuanto al TDP que marca el consumo energético del chip.

Un cambio tan repentino de la GPU en el SoC de una consola no es algo que sea lo normal, en la entrada «Comentando a Albert Penello» hice un comentario-respuesta en forma de entrada en el blog con el objetivo de aclarar (y aclararme a mi) los procesos de diseño de una consola y resulta que cosas como lo que son las especificaciones del chip objetivo se cierran bien temprano por el hecho que tiene relación con la estructura de costes. Por otro lado, AMD lo que tiene es una colección de piezas básicas con las que se pueden hacer los chips semi-custom para sus clientes, no son piezas hechas a medida sino que lo que esta hecho a medida es la forma en la que están colocadas.

Explicado de otra manera, Sony lo que ha hecho es volcar la mesa y le ha pedido a AMD que incluya una GPU más potente en la siguiente revisión del diseño, lo que ha llevado además a un cambio en el consumo del chip. Pero lo sorprendente son esos 1.8 Ghz para una GPU interna en un SoC, lo cual es es una exageración si tenemos en cuenta la eficiencia de la arquitectura GCN en general, pero no sabemos si AMD ha solventado una serie de problemas de la arquitectura en Navi en lo que a velocidad de reloj/consumo. Pero es que no solo eso, en los SoC existe un fenómeno llamado ahogamiento termal que hace que cuando una parte alcanza una calor generada determinada el resto se ve afectado negativamente en rendimiento y se ha de bajar la velocidad de reloj con tal de mantener al sistema termicamente estable.

¿Que es lo que ha ocurrido? Pienso que Sony ha podido ver como el diseño de Arden para Xbox Scarlett es un MCM, lo que permite velocidades de reloj más altas al no estar la CPU y la GPU en el mismo chip. Sony al ver las especificaciones y que estas podrían marcar una diferencia visual pues… ¡ha entrado en pánico!

Oficialmente no han anunciado nada por lo que están a tiempo de revisar las especificaciones finales del sistema y diria que teniendo en cuenta los timings clásicos de las consolas (puede que me equivoque) que ni tan siquiera han distribuido los SDK finales. Lo único que sabemos es que la GPU derivaría de Navi pero… ¿de cual de las Navi?

Tenemos el conocimiento de dos Navi 10 (al menos en PC) siendo una Navi completa y la otra la Navi Lite, las malas lenguas comentan que podría ser algo parecido al caso de la TU10x y las TU11x donde las primeras tienen la unidad RT Core/TTU mientras que las segundas no. Aparte de una serie de pequeños cambios. Pese a que es posible realizar via Compute Shaders el calculo de la intersección de los rayos con los objetos es mucho más eficiente hacerlo con hardware dedicado. ¿Pero realmente sabemos que Sony esta interesada en el Raytracing Híbrido? En general todo se esta moviendo en ese sentido y a una gran velocidad por lo que los editores independientes lo acabarán implementando en sus juegos y el hecho de que un hardware no lo implemente correctamente puede ser cuanto menos contraproducente no a corto plazo sino a medio e incluso largo plazo.

Pero lo realmente importante es que sabemos que Polyphony Digital esta desarrollando un Gran Turismo con Raytracing a tiempo real, es posible que el rendimiento bajo esas condiciones del hardware preliminar de hace unos meses no fuese el adecuado para una consola de la siguiente generación y Sony le haya pedido a AMD un simple cambio en la GPU.

Si la GPU hasta ahora era «Navi Lite» con el cambio es posible que haya pasado a ser una basada en la «Full Navi» y por tanto tener soporte por hardware para el Raytracing a tiempo real. En todo caso el tema de la velocidad de reloj de la GPU es algo que me chirría y mucho.

Si miramos las notas de prensa acerca de la evolución de los nodos de TSMC, tenemos que bajo el mismo consumo:

  • El salto de los 28nm a los 20nm fue de un 15% en cuanto a velocidad de reloj.
  • El salto de lo 20nm a los 16nm (FinFet) fue de un 50% en cuanto a velocidad de reloj
  • El salto de los 16nm a los 16nm+ es de un 15% en cuanto a velocidad de reloj.
  • El salto de los 16nm+ a los 10nm es de un 15%
  • El salto de los 10nm a los 7nm es de un 20%

¿Que es lo que ha ocurrido? Que la arquitectura GCN no ha escalado de manera correlativa y las velocidades de reloj obtenidas han sido mucho más bajas que las que se podrían conseguir con dichos nodos, con este problema AMD se encontro hace unos años por lo visto cuando las Artic Islands se conviertieron Polaris primero y luego en Vega. Se dieron cuenta que no podían escalar la arquitectura hasta cierta velocidad de reloj ya que el ratio velocidad de reloj/consumo bajaba, lo que suponía la necesidad de un re-diseño a nivel muy interno.

A la lista del twitter tenemos para añadir a Vega 10 cuyo nombre en clave es Greenland. ¿Y que tienen de especial Ellesmere, Baffin, Bermuda y Greenland? Pues que son islas del Atlantico Norte o que podríamos decir que son Artic Islands que es como se tenía que llamar la serie de GPUs de AMD a partir delo que fue Polaris pero AMD les cambio el nombre a Polaris, Vega y Navi a partir del famoso mapa de ruta de 2016.

Por aquel entonces la «Vega 20» o Vega a 7nm no existía dentro del mapa de ruta de AMD, fue planteada a posteriori, de ahí a que su nombre en clave que es Aruba haga referencia a una isla del caribe. El caso es que Bermuda se convirtio en Navi 10… ¿Y que referencias tenemos sobre Bermuda? Era la que tenía que ser la GPU de la nunca lanzada R9 390X pero lo que asustan son las especificaciones y el enorme tamaño del chip, el cual obviamente no salio jamás a la venta:

Unos 772mm2 a 20nm es una burrada, sobretodo si tenemos en cuenta que el tamaño del nodo de 16FF es el mismo por lo que este chip hubiese sido más grande en teoría que el AMD Vega en area, pero hemo de tener en cuenta que Vega consiste en 12500 MTransistores por lo que Vega tiene una densidad mayor.

Pero lo que llama la atención es la configuración del chip que es atípica.En primer lugar tenemos unos 4224 unidadades shader, y unos 96 ROPS que significan 24 RBE, esto significa que estamos ante una GPU no de 4 Shader Engines sino de 6 y se puede ver como se supera el limite de 4096 para 4 Shader Engines. Unos 4224 Shader Engines equivalen a 66 CUs lo que equivaldrían a a unos 11 CUs por Shader Engine, desde el momento en que en la época AMD agrupaba las CUs en configuracione de 4 CUs o 3 CUs por Compute Engine…

Estaríamos ante una configuración 4+4+3. Por otro lado tenemos la friolera de 512 bits GDDR5, en todo caso este chip no existe y fue derivado a lo que ha acabado siendo Navi que aún no ha sido lanzada. Pero Navi se convirtió en un proyecto paralelo a Vega con tal de solventar algunos de los problemas que ya se encontraron con Polaris e intentar hacer avanzar la arquitectura, simplemente «Bemuda/R9 390X» se acabo transformando en Navi y con el paso del tiempo dicha Navi ha acabado teniendo cambios profundos que hoy en día no la reconocería nadie, uno de ellos muy posiblemente el cambio del uso de memoria GDDR5 de 512 bits a GDDR6 de 256 bits pero lo cambios en el fondo serán más profundos.

El caso es que Navi tenía que aparecer el año pasado y AMD coloco en medio «Aruba/Vega 20» que es lo que ahora conocemos como «Radeon VII» y que para colmo ha salido varios meses con retraso. AMD tiene que haber tenido en algún momento una versión de Navi/Bermuda utilizando el nodo de 14nm o más bien dos versiones:

  • La versión 1 sería una simple adaptación al nodo de 14nm de GF (no confundir con TSMC) sin cambios arquitecturales, siendo más cercana a Polaris que Vega.
  • La versión 2 sería una versió adaptando todos los elementos integrados en Vega, esta es la versión que acabo por ser escogida por AMD para la creación de las GFX10.

Hemos de tener en cuenta que la GPU pueda obtener el ancho de banda necesario para funcionar de la memoria, cuya configuración podría ser 255 bits GDDR6 o 384 bits GDDR6. Este ejercicio lo hemos hecho muchas veces pero merece la pena adaptarlo al escenario del que estamos hablando, pero es para que veais además lo que supone la burrada de una hipotética GPU a 1.8 Ghz.

GhzROPSFillrateBW GPU
1,896172,8691,2

El caso es que si Navi es una evolució interna de la nunca lanzada Bermuda entonces estaríamos hablando de una GPU con 6 Shader Engines y 96 ROPS. Esto supone un cambio bastante importante en el esquema de memoria de la GPU y los anchos de banda que serían necesarios por parte de la memoria.

GDDR6Ghz GDDR6BW 256 bitsBW CPUBW GPU
12 Gbps1,538448336
14 Gbps1,7544856392
16 Gbps251264448
18 Gbps2,2557672504
20 Gbps2,564080560

Con un bus de 256 bits no se llega… ¿con uno de 384 bits? Veamos…

GDDR6Ghz GDDR6BW 384 bitsBW CPUBW GPU
12 Gbps1,557672504
14 Gbps1,7567284588
16 Gbps276896672
18 Gbps2,25864108756
20 Gbps2,5960120840

Es decir, podríamos conectar la GPU a unos 12 chips GDDR6 de 16Gbps para tener el ancho de banda necesario para alimentar dicha GPU en el MCM. Ahora bien… ¿Que configuración podríamos esperar? Sony con tal de mantener la compatibilidad sin problemas con PS4 y PS4 Pro creo y estoy en un 99.9% de que me equivoco, pues me parece que podríamos ver una configuración de 54 CUs, 9*6 Shader Engines. Pero siendo las CUs del tipo «Navi» con lo cambios que comente en la entrada de ayer.

Comparativamente esto nos llevaría a las siguientes especificaciones, las cuales son completamente especulativas:

SistemaPS4PS4 ProPS5*
CPUJaguarJaguarZen2
Núcleos CPU888
Ghz CPU1,62,13,2
GPUGFX7GFX8GFX10
Shader Engines246
CUs x SE999
CUs x GPU183654
Ghz GPU0,80,9111,8
FP32 (TFLOPS)1,84324,2012,44
FP16  (TFLOPS)8,4024,88
TMUs72144216
Texel Fillrate57,6131,18388,8
ROPS326496
Pixel Fillrate25,658,30172,8

Y creo que con esto es suficiente… Como siempre tenéis el Discord y los comentarios de la entrada para comentar.