Blog Personal.

Uncategorized

Xbox Series X (V): Compute Unit

RDNA 2 pese a lo que indica el nombre se trata de la tercera iteración de la arquitectura Navi/RDNA que va a aparecer en el mercado.

Cuando AMD lanzo Navi 10/RDNA en PC no lo hizo aplicando todo el conjunto de instrucciones completo por limitaciones de tiempo en el lanzamiento, entre el tipo de instrucciones que dejaron fue el soporte de instrucciones de 8 y 4 bits en enteros para Inferencia (Inteligencia Artificial) pero cuando lanzaron el Paper revelaron que futuras arquitecturas iban a tener el soporte para dichas instrucciones.

Para ello lo que usa AMD es el SIMD sobre registro, que consiste en subdividir las ALUs y los registros para duplicar el rendimiento con cada reduccion, de tal manera que los 12 TFLOPS en FP32 se convierten en 24 TFLOPS en FP16, 48 TOPS en Int8 y 96 TOPS en Int4. Pero al mismo tiempo esto indica que la unidad de codificación/decodificación de vídeo que aparecía en cierta patente de AMD y que llevaba una red neural en su interior no ha sido implementada al menos en Xbox Series X por lo que podemos deducir de entrada que AMD ha construido RDNA 2 partiendo de los componentes de Navi 14.

Y así fue, AMD lanzo en unos meses «Navi 14» en las RX 5500 y durante el tiempo re-hizo los componentes de las Compute Units.

La funcionalidad es la misma, la diferencia es que Navi 10/RX 5700 se construyo tomando elementos básicos de la arquitectura GCN ordenados de otra manera, elementos de construcción básicos como las ALUs, registros, unidades de texturas… Elementos básicos que tienen todas las arquitecturas y que por lo visto AMD decidió retocar y no solo de cara a una mejora en RDNA. Sin ir más lejos la reforma ha afectado también a Vega (GCN) y es el motivo por el aumento de eficiencia de las GPU en los SoC llamados Renoir aparte del salto a los 7nm y hemos visto como ha sido aplicado en Xbox Series X y es muy probable que en PlayStation 5.

La GPU de Xbox Series X tiene 56 CUs fisicamente hablando, pero Microsoft ha decidido desactivar 4 de ellos, es decir, 2 WGP, uno por Shader Engine. Esto lo digo porque mucha gente anda confundida sobre el tema pero hay 56 CUs físicamente hablando si hacemos caso a DF cuya fuente es Microsoft.

En el documento del Github las 56 CUs estabán activas a una velocidad de 1675 Mhz, esto era una GPU preliminar antes de la final, la cual han conseguido que vaya a 1825 Mhz. Precisamente producto del cambio en las Compute Units que vimos en Navi 14 y cuyos cambios han sido heredados en Xbox Series X permitiendo mayores velocidades de reloj respecto a las de hace unos meses.

En el caso de Xbox Series X hay unas 56 CUs físicas por el hecho que ese es el limite en las arquitecturas basadas en RDNA, es por ello que Microsoft no ha podido ir a más CUs.

¿El motivo por el cual es el limite? Dejad que me cite a mi mismo del otro blog.

En RDNA cada Compute Unit se comunica con su Cache L0 (que recordemos que es privada de cada CU) con un ancho de banda de 128 bytes/ciclo, esto le permite a las GPUS basadas en RDNA en adelante poder hacer filtro bilineal de texturas en FP16 sin recortar lo que es la tasa de texturizado, esto se ve marcado en las especificaciones de Navi 10 para PC, en la tasa de texturizado exactamente.

Pero no podemos en cambio hacer trilineal (8 muestras) porque seguimos teniendo solo cuatro unidades de texturas y por tanto una muestra por unidad de texturas.

Dado que tenemos unas 56 Compute Units en la GPU de Xbox Series X con su correspondiente cache L0 hay que tener en cuenta que no tenemos 128B/ciclo en total sino más bien (56*128B/ciclo) de ancho de banda total de todas las Caches L0 pero dicha cache no es compartida entre las diferentes Compute Units, es completamente privada y carece de coherencia con el resto.

El siguiente punto es la Cache L1, tiene una comunicación de 128B/ciclo con las Compute Units, cada Shader Engine tiene unas 2 Caches L1, la cual es solo de lectura y no de escritura, toda operación más allá de la Cache L0 que sea de escritura le hará un bypass a la Cache L1, no obstante la Cache L1 puede pedirle datos a la Cache L2 y almacenarlos para entregarlos a las Compute Units.

La Cache L1 existe para simplificar la matriz de cableado y por tanto de comunicación interna con la Cache L2, al pasar todo por la Cache L1 lo que es el anillo que comunica entre la cache L1 y la Cache L2 se simplifica y se evitan las sobresaturaciones.

Cada Compute Unit tiene un bus de lectura de 128 Bytes con cada Compute Unit, pero dado que es una memoria en la jeraquia de cache que esta a un nivel inferior esta almacena más información que la Cache L0 y tiene un grado de coherencia con todos sus clientes… ¿Pero quienes son sus clientes?

  • Obviamente las Compute Units
  • Las Unidades Render Backend (ROPS)
  • La unidad de Rasterizado.

Las Compute Units no pueden utilizar la Cache L1 para escritura pero los RBE y la unidad de Rasterizado si, pero son unidades de función fija y por tanto funcionan de forma automatizada, los anchos de banda de la unidad de Rasterizado y los RBEs en RDNA no han sido revelados por AMD en ninguna información.

Ahora bien, si miramos lo que es Navi 10 en PC veremos que la Cache L1 tiene un ancho de banda de 3.9 TB/s en una GPU que funciona a 1905 Mhz según la tabla, si hacemos al calculo rápido esto nos da unos 2048 bytes de ancho de banda.

Tenemos unas 10 Compute Units asignadas por Cache L1, a 128B/ciclo por Compute Unit esto son un total de 1280 bytes/ciclo por lo que nos quedan unos 768 bytes/ciclo de la Cache L1 para los RBE y la unidad de Rasterizado. En el caso de los RBE no hemos visto a AMD decir nada de ellos en cuanto a cambios por lo que podemos deducir que son los mismos que en AMD Vega sin cambios en el caso de las Navi 1x de PC. En este caso cada RBE puede transmitir unos 8 bytes/ciclo por ROP teniendo 4 ROPS por RBE esto son unos 32 bytes por RBE y dado que tenemos 4 los RBE tienen un ancho de 128 bytes/ciclo en total.

Podemos deducir, no tenemos la información que la unidad de rasterizado también va a unos 128 bytes/ciclo, esto nos deja unos 512 bytes/ciclo libres para conecta otras 4 Compute Units en total, haciendo un total de 14 Compute Units y si tenemos 2 Shader Engines con 2 Particiones de Cache L1 entonces tenemos un total de 56 Compute Units como configuración máxima.

No podemos olvidarnos que todas las operaciones de escritura que pasan por la Cache L1 independientemente de donde vengan hacen bypass sobre esta y escriben de manera directa a la Cache L2 que es la que trataremos a continuación.

OrigenDestinoB/clk
L1L21024
L2L11024

La Cache L2 esta compuesta por 4 particiones conectadas de manera directa a la Cache L1 con un bus de 1024 bytes entre las cuatro (128B/ciclo) y por tanto su ancho de banda total es la mitad de la cache L1 que como hemos visto antes es de 2048 bytes, lo cual es normal con una cache de nivel inferior en la jerarquia donde a medida que se va bajando disminuye el ancho de banda pero aumenta la cantidad de memoria de almacenamiento disponible.

Debido a que no hemos tenido que aumentar el tamaño y ancho de banda de la Cache L1 para poder colocar las 56 CUs en total no necesitamos hacerlo tampoco con la Cache L2, la cual esta directamente comunicada con los controladores de memoria, a razón de dos controladores de memoria de 32 bits por cada bloque de Cache L2. Por ejemplo. en la RX 5500 tenemos un bus de 128 bits, que son dos bloques de 64 bits y con ello dos bloques de cache L2.

En cambio en la RX 5700 tenemos el doble de ancho de banda con la memoria y con ello la cantidad de particiones se duplica.

¿Que significa esto? En primer lugar que la cantidad de cache en la GPU de Xbox Series X es casi con total seguridad de unos 4MB de tamaño… ¿Y que hay de la comunicación entre la Cache L2 y el controlador de memoria? Aquí nos encontramos con una sorpresa que rompe lo visto en las RDNA de PC y es que la interfaz de memoria es de 320 bits.

¿Significa esto que la Cache L2 ha de aumentar? No tiene porque y tenemos un precedente de esto en forma de Xbox One X donde el bus es de 384 bits GDDR5 pero la Cache L2 de la GPU es la misma que las AMD Polaris con bus de 256 bits. Es más, ya comente el motivo por el cual Microsoft ha optado por esta configuración y tiene que ver con la contención de memoria.

0 0 vote
Article Rating
1 Comment
Oldest
Newest Most Voted
Inline Feedbacks
View all comments

[…] resulta que es una estupidez, pero no quería perder esta entrada… Eso si, para entender el contexto mejor mirar la entrada de las Compute Units en Xbox Series X ya que en PS5…. Pensad esta entrada en un fork de la misma de manera especulativa para unas horas antes de la […]