Blog Personal.

Futuro, PlayStation 5, PS5, Radeon, Uncategorized, Xbox Series S, Xbox Series X, XSS, XSX

Sobre Sienna Sichild (II)

Perdón por el retraso, ha aparecido nueva informacion respecto a Sienna Cichild aka RDNA2.

Sienna Cichild es el nombre en clave de la GFX1030, aka RDNA 2 en forma de GPU para tarjetas gráficas dedicadas para PC, el nombre en clave podría ser el de la llamada Navi 21 aka «Big Navi» cuyas especificaciones se han rumoreado en los últimos días.

Pero dentro de lo interesante es que la GPU tiene un planificador nuevo en cada Compute Unit, el planificador de RDNA 1.x puede manejar hasta unos 80 Wavefronts de 64 elementos en cada Dual Compute Unit/WGP, en RDNA 1.x erán dos planificadores de GCN trabajando en paralelo y que es lo que hace todo planificador, lo que hace es escribir los hilos de ejecución o kernels (instrucción+dato) en los registros de la Compute Unit de manera ordenada.

Los registros de la Compute Unit son la memoria sobre la que operan exclusivamente las unidades SIMD, no funcionan como los registros de una CPU y se trata de una pila donde en cada n ciclos de reloj las unidades SIMD reciben una nueva instrucción.

Las instrucciones son recibidas por la ALU como una pila FIFO pero la que gestiona dicha pila como si fuese una lista es el planificador, cuando una ALU termina de ejecutar una instrucción escribe el resultado en la parte que le asigna la instrucción y dicha instrucción es borrada del planificador y se adelanta la siguiente. Pero las GPUs utilizan un planificador del tipo Round-Robin, tanto en AMD como en Nvidia, por lo que el planificador asigna n ciclos de reloj a cada instrucción para solventarse, si no lo hace en ese tiempo devuelve la instrucción a la cola. Hay principalmente dos métodos por los cuales una instrucción puede volver a la cola.

  • La instrucción hace referencia a un dato no incluido con la misma y el sistema de captación de datos ha sido demasiado lento, la petición del dato sigue funcionando pero la instrucción es puesta en la cola porque así la vez siguiente cuando se tenga el dato poder solventarla.
  • Necesita el resultado de una instrucción anterior para poder operar y no lo tiene disponible

Esto significa además que por muchos Tontoflops que hablen los «expertillos» de foro nunca se da ese rendimiento del 100% porque la mayoría de veces las ALUs no tienen los datos. ¿Pero entonces como es que se empuja hacía la cola? Pues porque si tienes que esperar una gran cantidad de ciclos a que las ALUs tengan la instrucción pues el resto de instrucciones que vienen a continuación se paran. Es una forma de reducir la latencia el hecho de adelantar otros kernels (instrucción+dato).

Por otro lado hemos de tener en cuenta que las GPUs no ejecutan programas realmente como lo hace una CPU, cada instrucción en una GPU realmente es un kernel que contiene de manera autocontenida una instrucción y su dato. Hay kernels que están relacionados entre si pero hay que tener en cuenta que la GPU aunque le pongas una lista ordenada de primitivas gráficas (triangulos) a transformar, rasterizar, texturizar y dibujar en un búfer de imagen. Estos jamás saldran en el orden que les has especificado de inicio por el hecho que habrá triangulos en la escena más rápidos de calcular que otros, si mantuvieramos el orden estricto y secuencial entonces una GPU no sería posible y todo…

La otra parte es el nivel de ocupación de las SIMD, uno de los problemas de GCN se puede ver en la siguiente diapositiva:

El diagrama pertenece a GCN, para entenderlo hemos de entender que cada Compute Unit tiene un planificador que gestiona 40 Wavefronts y le asigna 10 Wavefronts a cada unidad SIMD de la Compute Unit. Las unidades SIMD son de 16 ALUs por lo que pueden operar como máximo con 16 elementos por ciclo, dado que un Wavefront es de 64 elementos esto son 4 ciclos mínimo. En el caso de RDNA los Wavefronts pueden ser de 64 o de 32 elementos, si son de 64 elementos funcionan como en GCN pero si son de 32 elementos lo que hace el planificador no es enviar esos 32 elementos a una unidad SIMD y solventar en dos ciclos sino que lo envía a 2 unidades SIMD16 convertida en una unidad SIMD32 y solventarlo en 1 solo ciclo.

¿Suena fácil no? El problema es que el planificador es el que rellena los registros y crea una lista nueva y esto lo hace después de que el tiempo de los 10 Wavefronts haya pasado y no antes ni después. Hemos de tener en cuenta que el tamaño de las olas es variable y el tamaño de estas será como se utilizarán las ALUs. El problema con el planificador de GCN es que si las ola es de 64 elementos entonces las resolverá en el tiempo de 4 Wavefronts (si no se atrasan las instrucciones por los motivos que he comentado antes) y el planificador como esta pensado para funcionar con 10 Wavefronts de tiempo se pasará 6 Wavefronts sin rellenar los registros y pasando el tiempo en ese periodo y las ALUs no harán nada de nada.

¿Y si queremos aprovechar el tiempo? Pues tenemos que reducir el tamaño por ola, pero para poder aprovechar los 10 Wavefronts de tiempo tenemos que reducirla de 64 a 24, esto reduce la ocupación de 16 ALUs a 6 ALU por lo que tenemos todo el rato 10 ALUs sin hacer nada. Pues bien, AMD lo que ha hecho de cara a RDNA 2 es recortar el planificador conjunto de la Dual Compute Unit/WGP de 80 Wavefronts a 64 y muchos pensaréis que esto es un sinsentido… ¿Para que empeorarlo? Basicamente lo han hecho para maximizar la ocupación al 100% de las ALUs y para que tampoco hayan tiempos muertos, aumentando la eficiencia de las Compute Units, aparte que tener un planificador en el DCU/WGP más simple permite aprovechar el limitado espacio en el chip para otros elementos dentro de este. Debido a que esto es algo general para toda la arquitectura RDNA 2 esto tambien afecta positivamente tanto a PlayStation 5 como a Xbox Series X.

Esto es todo, tenéis los comentarios de esta misma entrada para comentar y no olvideis que tenemos Discord.

4.5 4 votes
Article Rating
2 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Nadie

Cichlid, no «cichild»/»sichild».
Escribir bien las palabras ayudaría a quienes buscan los términos por internet a encontrar este sitio, por ejemplo.

Ger

Esto puede provocar que series x debido a su mayor capacidad de cómputo en bruto renderice escenas a mayor resolución y ps5 gracias a su mayor frecuencia las haga a mayor framerate?