¿Para que es esta entrada? He visto muchas especulaciones comentando como AMD va a aumentar la cantidad de Compute Units respecto a Xbox One X y PS4 Pro y me parece un planteamiento estúpido por dos razones que considero que nadie esta teniendo en cuenta. La primera de ellas son los rendimientos decrecientes, más allá de una configuración de 46 CUs enel caso de la arquitectura GCN el aumento de rendimiento por CU adicional deja de ser lineal para pasar a sufrir rendimientos decrecientes, es decir, a partir de ese punto cada Compute Unit adicional hace que la media de rendimiento por cada una de ellas acabe disminuyendo. El segundo motivo tiene que ver con la competencia, con un equivalente a solo 40 CUs en cuanto a configuración, algo como la GeForce 1080 que carece de Tensor Cores y RT Cores se coloca por delante de Vega con 64 CUs por lo que aumentar la cantidad de CUs no es lo más eficiente del todo viendo cual es el panorama sino que para AMD lo mejor es aumentar la eficiencia por CU y ponerse al día, especialmente si tenemos en cuenta el limitado espacio con el que se dispone dentro de la retícula de un SoC.

En realidad no quería hacer esta entrada y la he tenido siempre en reserva por considerarla aburrida y sin valor, pero al final he decidido no dejarla a medias ya que es un contrapunto a muchas de las cosas que se leen en la especulación técnica de las consolas de la siguiente generación. Obviamente tenéis que prestar atención a los diagramas. Pero el origen de esta entrada es una pregunta que se me paso por la cabeza que tiene que ver con…

¿Como es que un chip que no es más que un Raven Ridge con memoria 256 bits de memoria GDDR5 y un Shader Engine adicional crece hasta duplicar el tamaño? Esto era algo que me tenía

La respuesta es clara y es el uncore… Y poco a poco al ir lueyendo documentación he llegado a poder hacer un mapa de la organización del uncore, mapa que tenía hecho hace unas semanas pero con lo rumores acerca de «Ariel» que es supuestamente el SoC de PlayStation 5 y la información que tenemos pues al final he decidido rescatar dicha entrada. ¿Motivo? Yo siempre he visto más efectiva una configuración MCM. El otro motivo fue que mi diagrama del post borrado lo puse en Beyond3D y lo que aprendí es que estaba mal, por eso esta borrado.

En fin, vayamos a lo que toca, llevo tiempo diciendo que el uncore del Raven Ridge es la base para los uncore de la siguiente generación pero nunca he explicado como y en esta entrada por fin vais a tener el puzzle completo respecto a este tema y para ello vamos a utilizar la siguiente diapositiva:

Esta es la organización del uncore de Raven Ridge. Lo primero que seguramente os llamará la atención es que hayan dos Graphics Container cuando tenemos una sola GPU. Ahora bien, cada Graphics Container tienen su camino de datos y pueden funcionar paralelo el uno del otro.

Si lo miramos desde el punto de vista de la GPU el camino de datos hacía la memoria es el siguiente:

¿Pero y para la GPU? Hay un cuello de botella enorme cuando se pasa del Coherent Master al Transport Layer Switch al unificarse ambos caminos, en realidad Raven Ridge tiene deficiencia de ancho de banda para la GPU debido a ello, por lo que un Raven Ridge ideal sería uno con 4 controladores de memoria DDR4.

Con una CPU no hay problemas en estrechar el ancho de banda, pero las GPU están pensadas para ser altamente dependientes del ancho de banda. Los 64 Bytes/ciclo vienen de una configuración de 16 ROPS a 4 bytes por ROP realmente… lo ideal en rendimiento gráfico para Raven Ridge seria por tanto una configuración DDR4 de 256 bits pero tened en cuenta que esto es solo como ejemplo ilustrativo.

Lo siguiente que vamos a comentar es como trasladar todo esto a Fireflight (y posteriormente a Ariel) que utilizan un uncore del mismo tipo pero una configuración de memoria distinta, en el caso de Ariel la desconocemos de manera oficial (y por eso luego haremos trampas), en el caso de Fireflight sabemos cual es.

  • GPU con 2 Shader Engines con 12 CUs cada uno en vez de 1 Shader Engine con 11 CUs.
  • Controlador de memoria GDDR5 de 256 bits.

Hemos de tener en cuenta que la memoria GDDR5 es un poco distinta de la DDR4, cada controlador GDDR5 es de 32 bits, su MEMCLK es 1/4 de lo que es su ancho de banda…

Pues bien, cada Coherent Slave en el diagrama es lo que en este otro diagrama que os he puesto varias veces es el Unified Memory Controller…

El caso es que el UMC va siempre a la velocidad de reloj de la memoria que en el caso del Fireflight es de 2Ghz, con esto podemos deducir que podemos alimentar un controlador de memoria GDDR5 con un solo UMC/Coherent Slave de los 8 en total en el caso del Fireflight.

Por otro lado, sabemos por el PCI id y la lista de componentes que Fireflight es una evolución de Raven Ridge…

Fireflight tiene unos 32 ROPS, esto significa que partirá de unos 128B/ciclo (32 ROPS*4 bytes)… Por lo que sabiendo los puntos en común podemos hacer un diagrama de la organización del camino de datos de la GPU con la memoria.

Como veis es mucho, pero que mucho más complejo que el del Raven Ridge y esto explicaría el enorme aumento del area. Pero esto que acabáis de ver no es el diagrama del uncore sino el camino de dato desde el punto de vista de la GPU. El diagrama completo del SoC sería el siguiente:

Esto explica el motivo por el cual el uncore de Fireflight haya aumentado tanto de tamaño.

Ahora bien, sabiendo esto lo podemos aplicar a Ariel… Porque sabemos por la lista del PCI ID que tiene elementos en común con Raven Ridge y Fireflight.

Supongamos que Ariel tiene los siguientes cambios respecto a Fireflight:

  • 256 bis GDDR6 como tipo de memoria utilizada.
  • 2 CCX
  • Una GPU con 4 Shader Engines en vez de 2 Shader Engines como Fireflight.
  • 64 ROPS

En primer lugar hemos de tener en cuenta que la memoria GDDR6 funciona de manera diferente a la GDDR5

  • En el caso de la GDDR5 la MEMCLK es 1/4 del ancho de banda, en el caso de de la GDDR6 es 1/8.
  • 2 canales de memoria de 16 bits de memoria en vez de 1 de 32 bits.

Esto hace que necesitemos 2 Coherent Slaves/Unified Memory Controller por controlador de memoria. Pero no necesitamos más para conocer la naturaleza del uncore, empezando por el Datapath de la GPU que tendría el siguiente diagrama:

Y de ahí podemos sacar la organización completa del SoC.

Por lo que el uncore de Ariel tiene que ocupar un espacio considerable viendo como se ha ido haciendo más complejo respecto a Raven Ridge y si Fireflight que tiene un aumento en la complejidad del uncore considerable entonces imaginaos Ariel. Que vale que tiene la ventaja del salto a los 7nm pero es que esto del uncore nadie o casi nadie lo tiene en cuenta en sus especulaciones cuando es una parte extremadamente importante de todo el esquema porque es lo que comunica todos los diferentes procesadores del sistema entre si y con la memoria.

¿Se puede conseguir una organización más adecuada? Poder se tiene que poder, pero Sony no diseña chips sino que se los diseñan a ella y la lista de dispositivos PCI ID no es fake ni un montaje. AMD ha tomado el camino que ha tomado y aunque no es oficial nada de lo que estoy diciendo tenemos una serie de puntos sobre la mesa que son innegables en cuanto al uncore que ya no tendrían que tener discusión posible.

El segundo tema son los Compute Units de la GPU. Mucha gente cae en el error de pensar… «Perdona, es que no puede ser que PS5 tenga la misma configuración que la Xbox one X» cuando no tienen en cuenta que lo que es realmente de echarse las manos sobre la cabeza es lo mal en comparación que funcionan las 40 CUs de las arquitecturas GCN frente a las 40 SM/CUs de una arquitectura como es Pascal (GTX 1080) que además esta ya superada por Nvidia a través de Volta y Turing. Por eso AMD no esta filtrando oficialmente datos de Navi porque no le conviene que haya una mala imagen de cara a los que van interpretando las cifras fuera de todo contexto como sería el caso.

El problema es que Vega es el equivalente a Pascal con menor eficiencia y el salto que tiene que hacer AMD con Navi es considerable. Como he comentado antes el hecho de añadir Compute Units porque si no aporta absolutamente nada y AMD debería plantearse tener Compute Units que rindieran mucho mejor en todos los aspectos. Es decir, AMD tiene que poder igualar a Volta/Pascal en rendimiento y en funcionalidad en Navi como mínimo o si no…

Lo que define la gama GFX10 (Navi) respecto a la game GFX9 (Vega) va a ser el Next Generation Geometry Pipeline y el nuevo tipo de shader global para la geometria como son los Primitiva Shaders. ¿Y si os digo que los Primitive Shaders ya se encuentran disponibles en Volta/Turing? Solo que Nvidia les ha dado el nombre de Mesh Shaders…

La arquitectura de Turing introduce un nuevo pipeline geométrico programable mediante el uso de Geometry Shaders. Los nuevos shaders traen el modelo de programación de los compute shaders al pipeline gráfico, ya que los subprocesos se usan cooperativamente para generar mallas compactas (meshlets) directamente en el chip para su consumo por el rasterizador. Las aplicaciones y los juegos que utilizan una complejidad geométrica alta se benefician de la flexibilidad del enfoque de dos etapas, que permite técnicas eficientes de culling, nivel de detalle y generación de procedimientos.

Esta definición es exactamente lo que AMD prometio con los Primitive Shaders, exactamente lo mismo. El concepto no es nuevo y fue una de las peticiones encima de la mesa que Sony le puso a AMD y que aún en PC no han cumplido. El caso es que Nvidia hasta Volta/Turing no ha podido y es por ello que creo que AMD ha evolucionada las Compute Units hacía lo que es Volta/Turing o mejor dicho para que se pongan más o menos a la altura en capacidades, esto suponen transistores extras y unas CUs más complejas.

¿Nos podemos hacer una idea aproximada? Tomemos Volta como ejemplo ya que es Turing sin los RT Cores… ¿Pero como podemos sacar dicha información? Del Tegra Xavier…

La GPU dentro de Volta mide unos 89mm^2 en total incluyendo todo el sistema de la GPU al completo… Pero lo que nos interesan son las unidades SM que por suerte la gente de Wikichips nos las han delimitado.

La imagen original esta compuesta por una resolución de 900×933, que son 839700 pixeles en total, teniendo en cuenta que esto representa un área de 89mm^2 entonces estamos en una superficie de 9434,83 pixeles por mm^2… Sabiendo esto y teniendo en cuenta una escala del 100%, recortamos el área correspondiente a una unidad SM.

La imagen hace 232×257 pixeles, esto son unos 59624 pixeles que en mm^2 nos dan unos 6.34 mm^2 por unidad SM. Lo cual es una cifra considerable y marca lo enormemente compleja que es la unidad SM de Volta/Turing frente a la su equivalente que es la CU de AMD en GCN bajo un nodo de fabricación de la misma generación que suele estar sobre los 3mm^2. ¿Y que ocurre con Turing? Pues Turing es Volta con los RT Cores, por suerte tenemos dos chips idénticos en todo excepto en la cantidad de unidades SM que son TU104 (RTX 2080) y el TU106 (RTX 2070).

La única diferencia es que la TU104 mide 545mm^2 con un total de 3072 unidades CUDA y la TU106 mide 445mm^2 con 2304 unidades CUDA, esto nos deja con unas 768 unidades CUDA (12 SM) en 100mm^2, lo que nos da uno 8.33mm^2 por unidad CUDA y de esta manera podemos extraer el tamaño de los RT Cores, unos 2.09mm^2 para cada uno de ellos.

Ahora bien, supongamos que la densidad con el paso a los 7nm pasa a ser de 2X, esto significa que cada núcleo al estilo Volta a 7nm tendría un tamaño similar al de las CUs que hay en Xbox One X y PS4 Pro en el nodo de 14/16nm pero con una funcionalidad mucho más avanzada y obviamente con mucho mayor rendimiento por cada una de ellas. Pensad que la consola más avanzada que es la Xbox One X en el fondo lleva una RX 480/RX 580 con 4 CUs activas más y a menor velocidad y estamos hablando de un salto cualitativo como mínimo hacía una 1080 en cuanto a potencia de la GPU.

La gente se pone a comparar FLOPS pese a la evidencia de que la comparación solo se ha de hacer desde la misma arquitectura. En todo caso hablar de arquitectura «GCN» a esta alturas con los cambios que han habido con Vega e incluso con Polaris es atrevido pero lo será aún más con Navi. Es por ello que cuando la gente vea las especificaciones va a tener unas reacciones fuera de contexto porque como siempre incluso se van a filtrar sin estar la consola presentada al mercado de manera oficial y esto provocara situaciones muy divertidas en la comunidad.

Esto es todo, como siempre, tenéis el Discord para comentar y los comentarios de esta misma entrada.