Llegamos a la parte más interesante para muchos, dadas las evoluciones continuas en PC de la gama GCN los cambios evolutivos no nos parecen tan impresionantes pero desde PS4 y PS4 Pro la evolucion hacía la GPU de PS5 resulta en un viaje completo donde todos y cada uno de los elementos de la misma han ido evolucionando y es que no podemos olvidarnos que la GPU de PS4 Pro es la misma que la de PS4 pero simplemente duplicando los Compute/Shader Engines, la cache L2 y haciendo que la unidad RBE soporten el Delta Color Compression y poco más que eso por lo que he creido importante dar un viaje por todas las partes de la GPU de manera breve.

En la entrada sobre la CPU no he descrito la evolución de Jaguar a Zen, personalmente porque no estoy muy puesto en cuento a CPUs realmente y mi afición ha sido siempre el hardware gráfico, es por ello que vais a ver una descripción más detallada de la GPU en esta entrada.

#1 Procesadores de Comandos

El cambio más importante es el salto de una configuración de 1 Procesador de Comandos y 8 ACEs a 1 Procesador de Comandos soportando Virtualización, 4 ACE y 2 HWS y en realidad esto se trata de un cambio radical al 100% en esta parte de la GPU. Cambio que por cierto en Xbox One X ya se ha dado al llevar en su interior una AMD Polaris.

Pero la GPU de PS5 llevará consigo un nuevo Procesador de Comandos Gráficos que hemos visto a partir de Vega en PC y que obviamente heredara la GPU de PS5 nos permite virtualizar la lista de comandos en varias sub-listas funcionando en paralelo. Esto es ideal de cara a la realidad virtual donde podemos hacer que la GPU funcione virtualmente como dos GPUs identicas utilizando cada una la mitad de los recursos gráficos de la GPU y permitir así que cada lista de comandos se encargue de una imagen distinta en el caso por ejemplo de la VR con el Split Frame Rendering sin necesidad de que exista fisicamente otra GPU y tampoco sin los problemas derivados de tener que coordinar dos GPUs con dos pozos de memoria distintos.

Hay que tener en cuenta que PS5 esta muy pensada para la Realidad Virtual y aunque el PSVR2 no vaya a ser lanzado de entrada, todos los juegos de PSVR van a recibir una mejora de rendimiento importante con el nuevo hardware y en algunos casos incluso vais a ver como las capacidades de la nueva GPU harán «VR» a juegos que no lo son, capacidades que iréis descubriendo en toda esta entrada y que vienen a demostrar que la consola se ha diseñado principalmente pensando en la Realidad Virtual.

En cuanto a los ACE son Procesadores de Comandos para las listas de computación, dichas listas son asincronas porque no dependen del tempo de lo que son los comandos gráficos para ejecutarse y se pueden ejecutar en paralelo. Es decir, una lista de un ACE se puede ejecutar en cualquier momento y en este caso se han de diferenciar los Compute Shaders sincronos con los gráficos (por ejemplo para efectos de post-procesado) y los que son asincronos con estos. Cada ACE esta maneja en total unas 8 colas que son unas 8 sublistas que están hechas en pequeño tamaño para su resolución.

Dado que la configuración de PS4 y PS4 Pro es de 8 ACEs entonces tenemos que puede manejar hasta unas 8 sublistas distintas, pero solo 1 cada vez ya que solo puede manejar una de ellas.

En PS4 y PS4 Pro es la CPU la encargada de gestionar estas listas pero en PS5 vamos a ver el HWS, algo que se vio por primera vez en las GCN 1.3 (Fiji y gama Polaris).

el HWS puede funcionar de dos maneras, por un lado puede gestionar las «colas» del resto de ACEs de tal manera que le evita al programa principal del juego o al controlador gráfico del SO tener que estar gestionando las listas, es decir, puede gestionar las colas asincronas y asígnarlos de manera automatizada a lar ranuras vacías de los ACE, Pero dado que puede manejar por si mismo hasta 2 colas/sublistas cada HWS puede funcionar como dos ACE si no se quiere que gestione las listas, no rompiendo la compatibilidad hacía atrás en ese aspecto.

Hay que recordar que solo las listas ejecutadas para la creación de los gráficos de la escena pertenecen al Procesador de Comandos Gráficos, el resto como es el Raytracing Audio, la ejecución de audio en modo PS4/PS4 Pro, la reproducción de video a tiempo real… Toda la gestión de estas listas forma parte del trabajo de los ACE y el HWS. Hay que tener en cuenta que aparte de la unidad GFX hay una serie de aceleradores en el SoC que dependen por completo y de modo pasivo de los procesadores de comandos para funcionar ya que simplemente ejecutan las instrucciones que reciben de estos.

#2.2 Workgroup Distributor y Core Fabric

El Core Fabric es el equivalente a una oficina de correos en la GPU ya que se encarga de enviar los mensajes de los procesadores de comandos al resto de los componentes de la GPU y lo aceleradores para que sepan que hacer en cada momento. Tanto los Procesadores de Comandos,el Workgroup Distributor, la GDS, los Geometry Engine y los DSBR se encuentran todos en el espacio central de la GPU rodeados por un anillo que les comunica con los Compute/Shader Engines a norte y sur, En todas, absolutamente todas las litografías de GPU independientemente del fabricante del que hablemos el Core Fabricse encuentra en la parte central de la GPU, aunque la configuración de los componentes puede variar, los Procesadores de Comandos están siempre ahí.

La comunicación con el resto de elementos de la GPU fuera del Core Fabric se hace a través del Workgroup Distributor que va enviando las diferentes olas. Si el Core Fabric es la oficina de correos, el Worgroup Distributor es su servició de logística y paqueteria que va enviando las olas/wavefronts siguiendo las instrucciones de los procesadores de comandos que le indican a que dirección (componente) han de enviar los datos.

Dentro del Core Fabric se encuentra una Scratchpad RAM de 64KB llamada Global Data Share o GDS. Es la parte que menos ha evolucionado desde la primera GCN hasta ahora y dudo mucho que veamos una evolución de la misma. Se ha de aclarar que no es una cache sino una memoria en el que su uso se tiene que declarar explicitamente en el código, pero no merece mucho la pena centrarnos en ella

#2.3 Geometry Engine/Primitive Assembler

Los Geometry Engine son los llamados teseladores, unidades de función fija encargadas de generar nueva geometría en la escena a partir de la existente haciendo uso de la sub-división de primitivas.

La teselación ya se encuentra en PS4 por lo que no es una novedad y forma parte de la etapa geométrica del pipeline gráfico. En algunos juego la teselación se ejecuta a través del Geometry Engine que es un sistema de función fija, en otros casos se hace a través de las Compute Units utilizando el Hull y el Domain Shader. El caso es que AMD a partir de Navi que es una GFX10 va a unificar todos los shaders relacionados con la geometria (Vertex, Domain, Hull y Geometry) en un solo tipo de shader llamado «Primitive Shader», algo que Nvidia ya ha implementado en Turing bajo el nombre de Mesh Shaders, pero estamos hablando del mismo concepto.

El Geometry Engine realmente esta dividido en dos elementos de función fija, el primero de ellos es el teselador mismo, el segundo es el Primitive Culling. Este se supone que se encuentra en las GPUs de AMD desde Polaris y su trabajo no es más que el de eliminar la geometría no visible en la escena por el jugador sin que las Compute Units tengan que actuar, lo que van a implementar en Navi va un paso más allá.

Se ha de aclarar que el Culling no es más que la eliminación de la lista de comandos gráficos de toda referencia a las primitivas gráficas que no son visibles en la escena por parte del jugador de tal manera que no se calculen en etapas posteriores toda su transformación por el hecho que no merece la pena al no ser visibles por el espectador. Evolutivamente Navi va a permitir el control automático del nivel de detalle según la distancia de tal manera que los desarrolladores no tengan que preocuparse de ir creando diferentes modelos de un mismo objeto para representarlo según la distancia.

Como veis esta función es como la teselación pero a la inversa, sirve además para la teselación adaptativa para que no se cree más geometria de la necesaria en distancias lejanas. Pero un ejemplo perfecto de la funcionalidad del nuevo pipeline geométrico se puede ver paradojicamente en el vídeo sobre los Mesh Shaders de Nvidia, no os preocupéis, se trata del mismo concepto.

Uno de los conceptos de los Primitive Shaders no es otro que el de tener la capacidad de descartar la geometría superflua y por tanto no visible durante la etapa geométrica del pipeline y por tanto antes del rasterizado. Esto es sumamente importante porque reduce la carga en etapas posteriores del pipeline pero no se debe confundir con la capacidad de eliminar fragmentos no visibles con el DSBR, ya que la etapa geométrica es anterior a la del rasterizado.

El caso es que los Primitive Shaders se descartaron por completo en Vega pero en una lista de correo uno de los ingenieros de AMD respondió que esto sería apoyado en la siguiente generación de sus GPUs (GFX10/Navi) y por ello va a ser una de las cosas que veamos en la GPU de PS5.

Pero no solamente la utilidad de reduce a la teselación y a la eliminación de geometría superflua. Otra de las cosas que los cambios en el Geometry Engine van a permitir hacer es convertir la geometría de la escena a 3D estereo, es decir, generar a partir de la geometría de una escena una versión para el otro ojo sin tener que recalcular la geometría y aplicando el culling desde la perspectiva de cada ojo.

Esto es otra de las funciones para la VR de PS5 y va a permitir que muchos juegos pasen a ser compatibles con las PSVR desde cero y por otro lado va a mejorar el rendimiento de los juegos ejecutados bajo el PS VR al ahorrarse el tiempo del calculo de la geometría del segundo ojo aligerando al trabajo a las Compute Units.

Pese a que todo esto se puede hacer a través de los shaders es mucho más eficiente hacerlo desde función fija, es más, el Geometry Engine como el DSBR (rasterizador) han sido movidos al Core Fabric a partir de Vega para a futuro aplicar dicha funcionalidad, su existencia en el Core Fabric les permite marcar a los procesadores de comandos que elementos han de eliminar de las listas de comandos y cuales han de añadir.

#2.4 DSBR

El DSBR es la nueva unidad de rasterizado que AMD añadio a partir de Vega, su funcionamiento al completo no se entiende sin el anillo Infinity Fabric alrededor de la GPU por lo que lo explicare parcialmente su funcionalidad en esta subsección. Las unidades de rasterizado transforman la geometria 3D en fragmentos 2D generando el búfer de profundidad por un lado y por el otro creandos los fragmentos de pixeles que luego la unidad de texturas tendra que colorear con los valores especificados.

La particularidad del DSBR es que rasteriza por tiles, es decir, lo que hace es que rasteriza la geometria de pantalla subdividiendo esta una porción de la pantalla lllamada Tile y a partir de ahí la ordena dentro de la posición y de ahí la posición de la geometria queda ordenada según su posición de la pantalla. Este cambio supone que los fragmentos de la escena no estén ordenados según su posición de pantalla a posteriori del texturizado (Last Sort)…

… sino antes del rasterizado (middle sort).

Esto permite tener un mapa ordenado de la geometría de la escena según su posición en la escena y dicho mapa es utilizado para crear la estructura de datos esencial para el Raytracing, el BVH.

Dicho BVH será utilizado durante la etapa de trazado de rayos para saber que objetos se encontraran cada uno de los rayos durante su trayecto.

El DSBR es el equivalente al Tile Caching de Nvidia que se encuentra desde las Maxwell, pero en AMD esto esta desde Vega y dado que el BVH no es posible realizarlo sin que la unidad de rasterizado sea un DSBR esto explica porque la demo Neon Noir de Crytek requiere una Vega 56 como minimo para funcionar.

La generación del BVH en cada fotograma no solo es esencial para el Raytracing gráfico sino también el de audio ya que ambos van a utilizar la misma estructura.

La otra novedad del DSBR es el hecho de poder aplicar el Hidden Surface Removal a nivel de Tile, es decir, todo fragmento opacado por otro más grande y más cercano a la cámara es descartado. AMD a partir de Vega movio la unidad de rasterizado fuera de los Shader Engines porque en este caso funciona como el Geometry Engine pero con lo fragmentos en las etapas posteriores del renderizado. Es por ello que el DSBR se encuentra en el Core Fabric ahora.

El hecho de descartar los fragmentos no visibles es importante porque evitar su posterior texturizado y hay que tener en cuenta que la etapa de texturizado es la que es más pesada de todo el pipeline gráfico y es una tontería calcular el color de una parte no visible del fotograma.

#2.5 Shader/Compute Engines

AMD a partir de Vega hizo un cambio en la organización de los Shader Engines al acercar el rasterizador y el Geometry Engine a los Procesadores de Comandos ya que estos antes se consideraban parte de los Shader Engines.

A partir de Vega dicha organización ha cambiado, los Shader Engines han pasado a ser Compute Engines compuestos únicamente por las Compute Units dejando a los RBE también aparte y renombrados como Pixel Engines.

¿Cual es el problema de la nueva nomenclatura? Con Compute Engine se hacia referencia a los grupos de CUs alrededor de la cache L1 de Instrucciones.

Hasta 4 CUs pueden la cache de instrucciones de primer nivel y dicha estructura recibía el nombre de Compute Engine antes de los tiempos de Vega, aunque al contrario de lo que ocurre con el DSBR y los Geometry Engines, los RBE están siempre directamente conectados a la Compute Unit por lo que es una tontería tratarlos como si fuesen piezas completamente independientes.

#2.6 RBE/Pixel Engines

El trabajo de los RBE es generar los búfers de imagen, es decir, mientras que la GPU es el pintor, los RBE son el pincel y la memoria de la GPU es el lienzo. Por lo que los RBE están directamente conectados a la interfaz de memoria de la GPU y reciben los datos a procesar tanto de las Compute Units.

En PS4 Pro lo que hizo Sony fue añadir el soporte para el Delta Color Compression de tal manera que hubiese suficiente ancho de banda para la tasa de relleno de la GPU.

Esto es debido a que en PS4 Pro el ancho de banda disponible no era suficiente. Curiosamente en PS4 ocurre que la GPU de los 176GB/s solo dispone de unos 102.4 GB/s disponibles, esto cuadra con los 25.6 Gpixeles/s de la consola. Es decir, Sony coloco el ancho de banda justo y necesario con la memoria para dicha consola pero en PS4 Pro no lo hizo.

Dado que el limite son 64 ROPS (16 RBE) y a no ser que AMD nos presente una GPU con más de 4 Shader Engines y sabiendo que la velocidad es de 1.8 Ghz en la GPU, entonces la conclusión utilizando la misma metrica que en PS4 y perdonad si me repito de la entrada anterior son los 115,2 Gpixeles y por tanto los 460,8 GB/s de ancho de banda para la GPU. Por otro lado hemos de tener en cuenta que en los SoC Ryzen la CPU y el resto de elementos toman del ancho de banda de la memoria un ancho de banda equivalente a la velocidad del controlador de memoria (1/8 de los Gbps)*32 bytes, dejando 7/8 a la GPU.

En la entrada anterior hice una serie de tablas y pudimos ver que los 460.8 GB/s para la GPU con el menor número de chips posibles y a la menor velocidad de reloj posible para la memoria, nos da que el punto exacto esta en un bus de 320 bits (10 chips GDDR6) con una GDDR6 a 12.8 Gbps. No solo eso sino que los últimos rumores de Navi es que esta utiliza memoria GDDR6 a 12.8 Gbps por lo que todo en el fondo es un auténtico…

¿Pero como han evolucionado los RBE respecto a PS4 Pro? Aquí entramos ante otra de las funcionalidades que se han implementado de cara a la VR.

Hice una entrada hace unos días acerca del Variable Rate Shading, en el que los RBE son un elemento crucial para implementarlos de manera general. Aunque el VRS es posible hacerlo via shaders, el hecho de hacerlo a través de función fija apoyandose en los RBE mejorados para ello va a permitir que casi el 100% de los juego para la VR se beneficien de ello. Aunque el VRS es una combinación de varios elementos de la GPU los RBE realizan una parte importante en el mismo.

#2.7 Compute Units

Las Compute Units de PS4 y PS4 Pro son del tipo Sea Islands (GFX7) y las que vamos a ver son GFX10 por lo que estamos hablando de un salto bastante importante pero la organización general de todas las GCN es siempre la misma en general.

¿Que cambios vamos a ver respecto a PS4 Pro? No los voy a relatar todos porque estaríamos hasta mañana con una entrada que ya es lo suficientemente larga por lo que ire a lo que realmente os interesa que es el Raytracing. Cuando se confirmo lo del soporte de Raytracing por hardware los Nvidiotas empezaron a soltar su bilis diciendo que eso era a través de las Compute Units como si Nvidia fuese la única en que tuviese el derecho en utilizar una Traversal Unit/RT Core en sus unidades con tal de recorrer el arbol BVH antes citado ahorrando tiempo y recursos a las Compute Units en esto aunque estas forman parte de una Compute Unit y si, el añadido de estas unidades esta confirmado.

En realidad hice una entrada de como estas unidades podrían estar implementadas en la Compute Unit clásica de la arquitectura GCN basandome en un paper de hace unos años donde se describían los cambios que se tenían que hacer en una GPU de la familia GCN para la implementación de un RT Core/Traversal Unit y casi todo consiste en modificar la Compute Unit para ello y también otras partes del hardware de la GPU con tal de conseguir ese proposito.

Las partes marcadas en verde son las que en teoría se añadirían de nuevo o se modificarían sobre la clásica CU de la arquitectura GCN. En este caso las únicas unidades nuevas que se añadirían serían las marcadas como Traversal Units (TU) que harían el trabajo equivalente a los RT Cores en Nvidia.

Dichas unidades estarían conectadas a la Cache L1 a través de las unidades Load-Store y aquí tenemos que tener en cuenta una cosa, la cache L1 de datos normalmente puede comunicarse con:

  • La Local Data Share dentro de la propia Compute Unit.
  • La Cache L2 fuera de la Compute Unit
  • Las 4 unidades de texturas dentro de la propia Compute Unit

Y ahora además se podrá comunicar con la:

  • La Traversal Unit en la misma CU.

La contrapartida en comparación con las unidades SM de Nvidia es que no vamos a ver un equivalente a los Tensor Cores por parte de AMD en la GPU de PS5 y se que algunos se estarán preguntando como es eso posible ahora cuando los Tensor Cores son esenciales para poder generar imagenes a mayor resolución y para el denoising, pero el motivo de ello es ni más ni menos que el espacioque tiene la GPU en todo el SoC y los sacrificios que han tenido que hacer para ello.

Pero hay que tener en cuenta que los Tensor Cores y/o similares no son una pieza esencial en el pipeline grafico para el raytracing híbrido y aunque el pipeline descrito en la diapositiva siguiente es el DXR, tened en cuenta que en las otras APIs será el mismo:

Tenemos dos shaders para lo rayos, uno dice como se comporta el objeto ante el impacto del rayo en la escena y el otro como se comporta como fuente de luz, pero no tenemo ningún tipo de shader para la intersección porque el algoritmo es siempre el mismo de manera recursiva por lo que la recomendación es mover el calculo de la intersección de los rayos con lo objetos a un elemento de función fija. El paper que mencione en la entrada de hace unos días explica muy bien la motivación:

Con esta plataforma de ejemplo tenemos un total de 176.000 millones de traversal steps por segundo. Teniendo en cuenta que todas las instrucciones vectoriales de la GPU consumen ranuras de emisión de la FPU, las traversal units proveen el equivalente a 4.4 TFLOPS de rendimiento adicional, pero ocupando solo el 4-8% del area ocupada por las actuales ALUs.

Teniendo en cuenta que posiblemene hablariamos de 4 Traversal Unit por Compute Unit (pensad que esto es un escenario posible a falta de que tengamos el escenario real) y extrapolando del paper tenemos que cada una de las TU equivalen a 25 FLOPS/ciclo y por tanto 100 FLOPS/ciclo por Compute Unit a través de los shaders. La GPU que toma el paper como referencia es la AMD Hawaii que es una GPU de arquitectura GCN con 44 CUs funcionando a 5.9 TFLOPS, para poder llegar a la potencia que le otorgan las TU por una porción muy minuscula del espacio haría falta una GPU de la misma arquitectura con una potencia de 10.3 TFLOPS y un tamaño colosal solo para poder ahorrarse las Traversal Units, lo que hace que todo el planteamiento deque no vamos a ver este tipo de unidades sea cuanto menos… ridiculo y un insulto a la inteligencia.

Si nos vamos a los rumores acerca de Navi que han aparecido los últimos días tenemos que por lo visto AMD ha duplicado la cache L1 de datos, que se encuentra en la Compute Unit, de 16KB a unos 32KB en total. Dado que la velocidad a la hora de recorrer la cache es esencial también podemos deducir que han ampliado las unidades Load/Store. Este cambio viene posiblemente porque al ser esta tanto para las Traversal Units como para las unidades de texturas con 16KB no es suficiente para almacenar todos los datos para ambas unidades, en todo caso hay que aclarar que estoy hablando de una implementación de este tipo de unidades y AMD puede aplicar otra que no va a diferir mucho.

¿Hemos terminado? No, nos faltan aún una parte importante para que tengais el puzzle de la GPU al completo.

#2.8 Infinity Fabric y Cache L2

(Esta parte era originalmente era una entrada aparte por lo que veréis algunos elementos repetidos).

Las GPUs de AMd a partir de Vega tienen en lo que es la parte GFX de la misma un anillo a su alrededor para comunicar los diferentes componentes entre si y que es inédito en la GPUs Pre-Vega. Este anillo rodea por completo lo que es la unidad GFX de la GPU que es esta menos las interfaces externas y los aceleradores.

Este esquema representa la organización y el espacio exactos que ocupan cada uno de los elementos de una GFX9 (Vega) de 64 CUs independientemente del nodo de fabricación. Fijaos como alrededor de todo el complejo hay un anillo perimetral que pone «Infinity Fabric» y este elemento es importante por dos motivos:

  1. El primero de ellos es que las interfaces Infinity Fabric son los conectores universales de los SoC de AMD actuales y a partir de Raven Ridge y desde el momento que sabemos que Ariel, Fenghuang y Raven Ridge comparten el mismo tipo de uncore el añadido del Infinity Fabric se entiende a la perfección, la contrapartida es que ocupan un tamaño mayor respecto al Crossbar anteriormente utilizado. Esto hace que las GPUs en espacio no escalen tanto si tomamos como referencia una GPU Pre-Vega.
  2. El nuevo anillo permite que los RBE estén conectados con la cache L2 de la GPU y escribir directamente sus datos en dicha cache en vez de dejarlos ir directamente a memoria. Dado como están organizada la GPU se puede ver como los RBE y la cache L2 no están uno al lado del otro por lo que es necesario el anillo para transmitir los datos.
  3. por si fuera poco las interfaces Infinity Fabric envian datos con un bus de 32 Bytes/ciclo y los RBE también lo hacen con ese ratio y lo que hace este anillo es permitir un tipo de comunicación que antes no era posible.
  4. No solo las unidades RBE y la cache L2 están cercanas al anillo exterior sino también la unidad DSBR. Que es la unidad encargada del llamado Tile Caching o Rasterizado por Tiles en las GPUs de AMD, otro concepto del que he hablado repetidas veces y que para su funcionamiento requiere poder almacenar los fragmento a rasterizar en la cache L2. Las diapositivas que pongo siempre son las de Nvidia porque lo relatan mejor pero el concepto es exactamente el mismo:

Es decir, es imposible que el DSBR haga todas las funciones mentadas en su subsección correspondiente si no fuese por la conectividad de la cache L2 con los DSBR realizada por este anillo, estas funcionalidades como he dicho muchas veces no aparecieron con Vega sino en las Nvidia Maxwell por primera vez.

El Tiled Caching es lo que permite todas las funciones adicionales descritas en el DSBR.

Por último hemos de tener en cuenta que el anillo IF también actua como interfaz entre la cache L2 y los RBE con los aceleradores y el controlador de memoria del sistema que en este caso es el HBCC. Los RBE se pueden comunicar directamente con el controlador de memoria o a la cache L2 como he descrito antes, la cache L2 esta comunicada en un extremo a las caches L1 de los grupos de CUs y en el otro extremo al controlador de memoria.

La comunicación es de 64 Bytes/ciclo y por tanto 32 Bytes/ciclo por dirección. Que las interfaces sean de 32 bytes/ciclo no es una coincidencia precisamente, es el ancho de la interfaz del Infinity Fabric. Cada grupo de hasta 4 Compute Units se puede comunicar co una partición de la cache L2 con un ancho de banda de 32 Bytes/seg por dirección. Normalmente lo que hacía AMD es colocar 4 particiones por Shader Engine de 64KB o de 128KB cada una por lo que la configuración máxima era de 2048KB pero con Vega la cache L2 al aumentar la cantidad de clientes de la cache L2, esto significa que a partir de Vega cada partición ha aumentado a los 256KB por partición.

Ahora bien, con la cache L2 tenemos que volver al rumor acerca de Navi que ha aparecido donde se comentan unos 3076KB de Cache L2, lo cual es una cifra que no cuadra mucho.

¿Y que dice el rumor respecto a la cache L2 de Navi?

No pueden ser 3076KB porque no es un multiple de 64KB, 128KB o 256KB, han de ser 3072KB. ¿Que es lo que pienso? Aquí voy a especular un poco.

Tradicionalmente AMD siempre, repito siempre ha dejado la configuración máxima de cache L2 de la GPU independientemente de la configuración interna de los Shader Engines en cuanto a la configuración de la CUs y esto es importante para comentar el rumor reciente que ha aparecido que para mi, personalmente creo que tiene mucho sentido y no es un rumor inventado, aunque bien podría ser que tuviese que comerme las palabras.

¿Cual es la lógica? Cada grupo de Compute Units esta conectada a una partición y si tenemos tres grupos por Shader Engine estos son 768KB y con cuatro hacen los 3072KB del rumor. Auque esto no significa que tengamos una configuración de 48 CUs si que es la configuración máxima posible siendo la minima la de 36 CUs por lo que tenemos en total las siguientes configuraciones:

  • 3-3-3 (36 CUs)
  • 3-4-3 o 4-3-3 o 3-3-4 (40 CUs), como curiosidad en realidad PS4 y PS4 son 3-3-4 pero con la última CU de cada Shader Engine desactivada.
  • 3-4-4 o 4-3-4 o 4-4-3 (44 CUs), si tenemos en cuenta que se suele anular el último CU la configuración 4-4-3 es la que tiene más números.
  • 4-4-4 (48 CUs)

Es decir, es posible y esto no es más que una especulación de que estemos ante una GPU con 44 CUs a 1.8 Ghz en el caso de Ariel con 48 CUs físicas, en todo caso la GPU del SoC tendría unas 48 CUs a nivel físico.

Los rumores que hemos oido de Navi 10 Lite en PC es que tiene unas 40 CUs, esto entraría dentro de las posibles configuraciones, sumadle que el SoC se supone que lleva una Navi Lite pero con una configuración propia… ¿Pero donde queda entonces lo de las Traversal Units? Pues las vamos a ver en la gama Navi 20 en PC donde también habrá una Navi 20 Lite, es decir, la GPU de PS5 más que una GPU de 2019 es una GPU de AMD de 2020 en ese sentido. Por otro lado los 44-48 CUs para la GPU coincide con el tema de Fireflight/Fenghuang x2 que ya he comentado en la entrada anterior.

¿Y porqué no una GPU con 64 CUs? Os voy a explicar el porque tomando a Vega 7nm como referencia. AMD el año pasado afirmaba que el salto de los 14 a los 7nm suponían el doble de densidad por lo que el area del chip de Vega 7nm respecto a Vega 14nm debía ser cercana a la mitad.

En el fondo Vega 7nm que no es más que una Vega 14nm pero con dos controladores HBM2 adicionales, pero el tamaño del chip a simple vista no se reduce a la mitad realmente:

Vega 7nm a la izquierda tiene un empaquetado que mide unos 331mm^2 y eso no son la mitad de los 484mm^2 de Vega 14nm. Pero por lo visto en realidad dentro del empaquetado hay una enorme cantidad de espacio entre lo que es la GPU en si misma conlas interfaces Infinity Link (novedad en Vega 7nm y que son el equivalente el NVLink pero de AMD y que no vamos a ver obviamente en la GPU de PS5), los aceleradores como el Multimedia Engine y el Display Engine y con el controlador de memoria y sus interfaces.

Por lo que realmente lo que tenemos es que la unidad GFX9 mide unos 220-230mm^2 en Vega 7nm realmente. El problema es que una unidad GFX de 230mm^2 es demasiado grande para colocarse en el SoC de una consola de videojuegos, de ahí a tirar de una configuración con menos núcleos pero a cambio de subir la velocidad de reloj de la GPU.

Con todo esto os dejo una tabla con la posibles especificaciones de la GPU:

Modo JuegoModo Bajo Consumo
Velocidad (Ghz)1,801,00
CUs44,0044,00
CU FP32 ops (TFLOPS)10,145,63
CU FP16 ops (TFLOPS)20,2811,26
CU Int8 ops (TFLOPS)40,5522,53
Traversal Units176,00176,00
TU TFLOPS7,924,40
Unidades de Texturas176,00176,00
Tasa de Texturizado (Gtexeles)316,80176,00
ROPS64,0064,00
Tasa de Relleno (Gpixeles)115,2064,00

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