Por fin AMD ha publicado el White Paper de la arquitectura RDNA y en ella hay una serie de cosas que me llaman poderosamente la atención y que al mismo tiempo me llevan a corregir ciertas afirmaciones hechas previamente.

#1 El Funcionamiento de la Cache L1

Los diagramas de AMD son confusos ya que dan a entender que la cache L1 es tanto de lectura como de escritura.

En el documento de AMD se puede leer lo siguiente:

La memoria caché L1 de gráficos es una memoria caché de solo lectura respaldada por la cache L2 compartidos globalmente; escribir en cualquier línea en los gráficos L1 invalidará esa línea (y el dato) ira a la Cache L2 o la memoria. Ahí un modo explicito que permite hacer bypass explicito y evitar que los shaders pongan datos en la Cache L1.

Esto es curioso, resulta que todo lo que se escribe en la cache L1 se escribe realmente a la Cache L2, pero en el mecanismo de captación de datos para la lectura entonces la Cache L2 si que puede alimentar a la Cache L1 con una serie de datos. AMD no da en el Whitepaper un motivo para la existencia de la nueva cache.

Al pasar a una nueva tecnología como es el proceso de 7 nm, se reduce el área y el consumo energético de los transistores,
Uno de los mayores desafíos es que el rendimiento y la eficiencia del cableado tiende a mantenerse igual o empeora. En consecuencia, el envío de datos a largas distancias se vuelve cada vez más costoso.

Esto es fácil de entender, cuanto más lejos esta una memoria de la ALU más largo es el camino y más tiempo hay por instrucción, si se reducen las ALUs pero no la distancia del cableado por otros motivos entonces lo que acaba ocurriendo es que el salto no es tan eficiente… ¿Y que ha hecho AMD? Colocar una cache intermedia nueva como parche a la hora de la captación de datos. La captación de datos no es otra que la búsqueda de manera jerarquica de un dato concreto en la jerarquía de cache y después en la memoria.

El hecho que la cache L1 de cada cluster sea de solo lectura impide que la primera generación de los RDNA funcione como un Tile Renderer, todos los elementos cuando escriben sobre la Cache L1 realmente lo hacen sobre la cache L2 pero si pudieran escribir sobre la cache L1 directamente entonces si que podría funcionar como un Tile Renderer dado que la cache L1 serviría como memoria interna para el backbuffer de cada uno de los tiles, es posible que AMD en RDNA2, especialmente el chip que esta haciendo para Samsung permita eso, pero en RDNA por el momento no se puede por el hecho de que la Cache L1 es de solo lectura.

#2 La Cache L0

Esto es sumamente interesante, AMD ha pasado de que el ancho de banda de las caches sea de 64B/ciclo a 128B/ciclo en todos los niveles de la cache, duplicando el ancho de banda por ciclo de reloj, esto incluye la cache L0 que es utilizada como cache de texturas.

En GCN los 64B/ciclo permitían alimentar a las 4 unidades de texturas con 16B/ciclo de texturas y dado que para el filtro bilineal necesitaban la información de 4 pixeles esto permitía que este fuese gratis, pero cosa como el trilineal y anisotrópico requerían varios ciclos de reloj adicional por texel. A primera vista podemos pensar que ahora va a ser posible hacer filtro trilineal ya que el sistema ahora transmite información de 8 direcciones de memoria.

Las texturas se almacenan en la cache L0 y se acceden de manera similar a los datos.

Sin embargo, los resultados se pasan primero a la unidad de mapeo de texturas, que puede realizar el filtrado de las mismas con hasta ocho direcciones de textura por ciclo de reloj,

Si tenemos en cuenta que necesitamos 8 muestras para el filtro trilineal entonces…

… podemos suponer que las TMUs pueden realizar filtro trilineal en un solo ciclo, no obstante…

Por cada dirección, la TMU sampleara los cuatro vecinos más cercanos, descomprimira los datos y realizará la interpolación (filtraje). El valor final de texel se devuelve al SIMD a través del bus de respuesta.

Las TMUs siguen operando para el bilineal, la explicación de AMD es que esto permite tener la misma tasa de texturizado en RGBA8 como en RGBA16F, dado que en GCN la tasa de relleno era la mitad.

La unidad de mapeo de texturas ha duplicado elr endimiento para el filtraje bilineal de 64 bits (utilizado como flotante de 16 por cada canal RGBA).

Es decir, podemos hacer bilineal RGBA16F en un ciclo pero no trilineal RGBA8 no por limitaciones de la cache sino de las unidades de texturas. ¿Y si solo puede trabajar con 4 muestras entonces que ocurre con el resto de lo datos? La primera respuesta es que sirven para los dstos que no son de textura y por tanto no están relacionados con los Pixel/Fragment Shaders.

Una nueva característica de la arquitectura RDNA es que las cargas de imágenes funcionan más rápido. Aquellas cargas que no realizan muestreo (de texturas) omitirán el hardware de interpolación de texturas y funcionarán a la misma velocidad que las cargas de búfer, mejorando el rendimiento en 8X y reduciendo la latencia en un 35% en
el caso de que haya un cache miss sobre la caché L0, incluso cuando se realiza la conversión de formato. Esto permite calcular efectos de shaders, que a menudo dependen de accesos a imágenes, para ofrecer un mayor rendimiento y mayor eficiencia.

Hoy en día se utilizan lo Compute Shaders para efectos de post-procesado visual, los Compute Shaders no requieren el filtraje y al contrario de los Pixel/Fragment Shaders no requieren el tiltraje de texturas sobre los datos. En GCN todo lo que se leía de la cache de texturas de la Compute Unit era filtrado y solo se enviaba un texel de información a la Compute Unit que era el resultado del filtraje, en el caso de RDNA se pueden enviar hasta 8 datos directamente al shader en vez de 1.

Esto es importante de cara al futuro porque sabemos que no solo las ALUs dentro del Workgroup/Compute Unit Dual por un lado y la unidad de texturas por el otro van a ser clientes de la cache L0/Texturas sino que tenemos la información de cierta patente donde se nos habla de la unidad de interseccíón de rayos dentro de la unidad de texturas, cosa que veremos en las RDNA para consolas y en PC en unos meses o el año que viene.

Es decir, con el aumento de clientes de la cache de texturas/datos dentro de cada Compute Unit es normal que se haya aumentado el ancho de banda de la misma, y si os parece extraño os diré que en el caso de Nvidia Turing su equivalente es cliente del RT Core.

El cambio de los 64B/ciclo a los 128B/ciclo para todas las lineas de cache aumenta enormemente el ancho de banda respecto a cualquier chip de la familia GCN incluyendo Vega.

Por otro lado, esta información adicional nos permite completar el puzzle al completo, teniendo en cuenta que la unidad de texturas trabaja con 4 muestras y sumando el hecho que para el salto de los 1080P a los 4K donde es necesario aumentar las tasas de relleno, texturizado y sus anchos de banda correspondientes en 4X si se quiere realizar lo que es el escalado a lo bruto.

#3 Completando el puzzle de PlayStation 5

Si queremos dar el salto a lo bruto de PS4 a PS5 sin tener que modificar el software entonces necesitamos una tasa de texturizado que sea 4 veces superior, existiendo unas 72 unidades de mapeo de texturas (TMU) en PS4 entonces a 800 Mhz entonces:

72*(800*10^6)= 57.6 Gtexeles/s

Para 4K a lo bruto: 230.4 GTexeles/s

La última noticia que tenemos es que la GPU podría ir a 2 Ghz, supongamos por un momento que la tasa de texturizado en PS5 es de 230.4 GTexeles/s precisamente, esto nos debería permitir saber cuantas Unidades de Texturas y por tanto Compute Unit serían necesarias y sinceramente, con la velocidad de 2 Ghz que se filtro hace poco, los números que salen pues no son muy redondos.

GtexelsGhz GPUTMUsCompute UnitsGFLOPS
230,42115,228,87372,80
230,41,8128327372,80

Curiosamente la tasa de FLOPS corresponde exactamente con la de 4X la tasa de FLOPS de PS4, lo cual cuadra al 100% con un salto en 4X. Esto no significa que la GPU solo tenga 32 CUs, pero solo necesita una 32 CUs (16 WGP) para reproducir los juegos de PS4 a 4K. Hay que tener en cuenta que una de las habilidades que tienen las GPUs de AMD de Polaris en adelante es la capacidad de aislar varias CUs del pipeline gráfico para otras tareas, esto es utilizado especialmente en el True Audio Next para hacer que parte de la GPU se encargue de renderizar el audio de la escena, función que no se ha perdido en RDNA.

La capacidad de reservar Compute Units debería estar. Claro esta que existe una segunda posibilidad y puede que me equivoque al 100%, pero es la que le veo más posibilidades de ser así. Creo que vamos a ver como la velocidad de reloj de la GPU irá fluctuando según cada necesidad (modo) y que en modo GCN para la compatibilidad hacía atrás va a ser necesario tener la misma cantidad de Compute Units. ¿Entonces? Pues para el modo PS4 4K sin mejoras y a lo bruto tiene más sentido una velocidad de reloj de 1.6 Ghz porque esto implica unas 36 CUs…

GtexelsGhz GPUTMUsCompute UnitsGFLOPS
230,41,6144367372,80

Tener unas 36 CUs permite colocar la GPU en modo PS4 Pro, reducir la velocidad a 911 Mhz y de paso hacer que la ejecución de las instrucciones pase a modo GCN en vez de RDNA.

Tened en cuenta que por FLOP RDNA es mucho más rápida por necesitar menos ciclos de reloj para las instrucciones.

En modo PS4 puro solo haría falta desactivar la mitad de las Compute Units y ponerlas a 800Mhz, de esta manera los juegos de PS4 se ejecutan en PS5 tal cual sin cambios pero al mismo tiempo es posible crear un modo PS4 4K… ¿Nos indica esto que la GPU de PS5 esta compuesta solo por unas 36 CUs y por tanto unos 18 WGP? Bueno, en consolas es típico eliminar alguna que otra unidad por Shader Engine, en el caso de Navi 10 (RX 5700 y RX 5700 XT) tenemos 2 Shader Engines con 10 WGPs cada uno, el RX 5700 funciona teniendo fisicamente todos ellos pero desactivando un WGP por Shader Engine, quedandose con 18 WGP/36 CUs.

Tened en cuenta que en los codigos del PCI ID se ha ido reservando las posiciones empezando por el 13E9 a principios de año..

Sabemos que el 13e9 corresponde a una Navi 10 Lite.

Por lo que podemos concluir que los huecos entre el 13f0 y el 13ff estarían reservados para diferentes iteraciones de la GPU con pequeños cambios, dando a cada iteración una ID distinta para identificarla de las anteriores pero sin cambiar la configuración general ya que obligaría a re-diseñar todo el chip.

Lo de Navi 10 es significativo porque nos marca la misma GPU que la gama RX 5700 por lo que la configuración de 40 CUS/20 WGP con 36 CUS/18 WGP activas tiene sentido. ¿Pero que significa Lite? Sabemos que cada chip de la arquitectura RDNA/Navi tiene su versión Lite.

Por lo poco que se, Lite hace referencia a cuando la GPU esta integrada dentro de un SoC/APU, es decir, cuando es una iGPU y no una dGPU (tarjeta gráfica aparte).

Pòr motivos de espacio en el chip final de PS5 tiene sentido que con solo 36 CUs hayan decidido colocar el pico de velocidad de la GPU primero en 1.8 Ghz y luego en 2 Ghz para la reproducción de juegos de PS5. Esto es algo que ya comente hace unos días en una de las entradas, que no vais a ver tantas Compute Units como la gente se espera en el hardware de PS5. Por lo que con esto ya tendríamos el puzzle cuasi completo de la consola, por no decir completo a no ser que aparezca alguna pieza secreta por el medio que por el momento desconocemos.

#4 Posibles Especificaciones de PlayStation 5

  • CPU Zen 2.
  • 8 Núcleos, 2 Hilos de Ejecución por Núcleo, 16 hilos en total.
  • 8MB de Cache L3, 4MB de Cache L3 por CCX (4 núcleos por CCX).
  • 32 GB GDDR6 con un bus de 256 bits a 18 Gbps (576 GB/s).
  • GPU RDNA++ (Soporte Raytracing)
  • 36 Compute Units/18 Workgroups
  • 144 Unidades de Texturas
  • 64 ROPS/16 RBE
  • Modo PS5: 2 Ghz
  • Modo PS4 4K: 1.6 Ghz
  • Modo PS4 Pro: 0.911 Ghz
  • Modo PS4: 0.8 Ghz (mitad de las CUs inactivas).
  • TFLOPS en FP32 (modo PS5 y por tanto RDNA): 9.2 TFLOPS
  • Tasa de texturizado (modo PS5): 288 Gtexeles/s
  • Tasa de relleno: 128 Gpixels/s

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