Lo que os voy a comentar a continuación es una patente de la propia AMD que hace referencia a la Compute Unit de las GPUs post-GCN, es decir… Después de años y años utilizando la misma Compute Unit de base que es esta:

kaveri-14b

van a cambiar dicha configuración. ¿Para cuando? Pues para después de Navi que es la última vuelta de tuerca a la arquitectura GCN.

gpuroadmap

Recordemos que antes de la arquitectura GCN AMD estuvo varias generaciones haciendo uso de un tipo de Compute Unit distinta. Por lo que podemos considerar el cambio real en cuanto a arquitectura cuando la organización de la Compute Unit cambia por completo. Pues bien, una de las patentes recientes de AMD nos explica con todo detalle como va a ser la Compute Unit de la arquitectura que va a sustituir a las GCN y que AMD lanzará en PC después de Navi por lo que aquí vamos a comentar la Compute Unit de la GPU que AMD lanzará en PC a partir de 2020. He decidido subirla por un motivo, por si acaba siendo reemplazada como referencia.

Dicho esto, empecemos.

FIG. 1A.PNG

La FIG. 1A ilustra una estructura SIMD de ejemplo.

FIG1B.PNG

La FIG. 1B ilustra una estructura super-SIMD de ejemplo.

Veamos los elementos diferenciales…

El Operand delivery network 240 propaga las señales a un par de ALUs configuradas en paralo. El par de ALUS incluyen una primera ALU 220 y una segunda ALU 230. La primera ALU 220 es una Full ALU y la segunda ALU 230 es una Core ALU

Ok, para explicar esto tenemos que entender como funcionan las unidades SIMD de las Compute Units y como ejecután estas las instrucciones. Para eso tenemos que hacer un zoom y entender que la FIG 1A no se refiere a la Compute Unit entera sino solo a una sola de las unidades SIMD de componen una Compute Unit, la cual tiene 4 bancos de registros vectoriales de proposito general que almacenan un wavefront entero cada uno. Cada Wavefront esta compuesto por 64 hilos donde cada hilo es un dato+instrucción a hacer con ese dato. Existen principalmente dos tipos de instrucción por Wavefront

  • Simples: Se ejecutan en 1 solo ciclo de reloj, recordad que se asigna 1 hilo por ALU y por ciclo si no esta ocupado.
  • Complejas: Se ejecutan en 4 ciclos de reloj cada una de ellas.
  • Saltos (Dentro del Contador de Programa de la ola) y Peticiones de datos: Tardan unos 16 ciclos en ejecutarse.

Por ejemplo en la arquitectura GCN tenemos que cada unidad SIMD es de 16 ALUs, esto significa que de los 64 hilos que tiene un Wavefront se asignan unos 16 por ciclo de reloj en cada unidad SIMD y por tanto se tarda unos 4 ciclos en solventar una ola. En la FIG 1A de la patente tenemos que la ALU Array 120 esta conectado a 4 sub-bancos VGRP y accede a cada uno de los bancos en un ciclo distinto a no ser que la unidad SIMD este ocupada con una instrucción a medio de la resolución.

GCNScheduling

En la FIG 1B el cambio es que asignamos dos ALUs distintas a los 4 sub-bancos de tal manera que si ambas unidades son SIMD16 podemos resolver un Wavefront en solo 2 ciclos. Pero se nos dice que podemos asignar la segunda ALU también a un Wavefront distinto. En la patente se nos comenta que cada uno de los sub-bancos puede ser de 32KB de memoria, haciendo un total de 128KB, esto es interesante porque permite almacenar dos wavefronts distintos, por lo que en vez de trabajar con un Wavefront puede trabajar con dos, pero no es la unica fuente de datos con la que puede trabajar.

Lo más interesante tiene que ver con el Destination Operation Cache.

El Super-SIMD 200 incluye una Destination Operation Cache. 250 donde se almacenan los resultados 8 o más ALUs para darle al super-SIMD operandos adicionales como fuente para operar o hacer un bypass a la pluralidad de los VGPR 110 para reducir el consumo. El resultado de las ALU 220 y 230 se propagan a la cache de operando de destino. La cual esta interconectada a la entrada de datos de las ALUs 220 y 230 a través de la Operand Delivery network 240.

¿Sabéis lo que comente en la entrada anterior sobre la combinación de étapas? Pues leedlo porque esto tiene que ver con ello y es un cambio importante respecto a la arquitectura GCN porque permite la combinación de étapas. Actualmente cuando una Compute Unit ha terminado de realizar una operación lo que hace es expulsar el resultado a una memoria externa, ya sea la Local Data Share de la propia Compute Unit o enviarla a destino en la jerarquía de caches de la Compute Unit por lo que la concatenación de wavefronts es cuanto menos complicada y el resultado tiene que ser invocado de nuevo y hacer todo el camino de datos para llegar a la Compute Unit a través de una instrucción de petición de datos, la cual es realizada por la unidad escalar en el caso de la arquitectura GCN. Aunque con tal de paliar eso lo que se hacía era enviar el resultado a la Local Data Share para que luego el planificador de la Compute Unit enviara de nuevo los datos resultado para ser enviados.

El hecho de que las Compute Units escriban el resultado sobre la Cache de Destino de Operandos es importante porque permite concatenar tipos de Shader y con ello etapas de manera consecutiva permitiendo enlazar los Shaders para gráficos (Vertex, Hull, Domain, Geometry y Fragment/Pixel) con los Shaders para computación (Compute Shaders). En todo caso miraos la entrada que hice ayer porque ahí lo explico perfectamente bien.

En otra implementación, la primera ALU 220 y la segunda ALU 230 representan el mismo tipo de ALU que incluyen full ALUs o Core ALUs. La ALU adicional (teniendo dos ALUs en la FIG. 1B en oposición a una sola ALU en la FIG. 1A en la super-SIMD provee la capacidad de realizar ciertos opcodes y permiten al Super-SIMD realizar dos instrucciones instrucciones Vector ALU (realizadas en paralelo) de la misma o de una ola distinta.

Ahora vamos a complicar un poco las cosas…

FIG2Navi.PNG

La FIG. 2 ilustra la estructrura interna en bloque del Super-SIMD

El bloque Super-SIMD 300 incluiye un selector de escritura VGPR 310 que recibe datos de al mensos de una de las unidades de texturas (no mostrada en la FIG. 2), la unidad de inicialización de ola/wavefront (no mostrada en la FIG. 2) y una unidad de memoria Local Data Share (no mostrada en la FIG. 2). El Selector 310 provee los datos de entada para la RAM 320 (mostrada como 110 en la FIG. 1B) y este a su vez envía los datos de salida al Crossbar de lectura 330, el cual son enviados al row source operand flops y de ahí al Crossbar 350 con los datos progresando a las unidades de ejecución 360 y de ahí a las Destinacion Cache Units 370. El Crossbar 350 puede enviar un bloque de entrada o uno de salida a las unidades de textura ( (no mostrada en la FIG. 2), a la LDS (no mostrada en la FIG. 2) y la unidad de exportación del Color Buffer (no mostrada en la FIG. 2).

La Destinacion Cache 370 concuerda con la Destinacion Cache 240 de a FIG. 1B. El Crossbar 330, Source Operand FLOPS 340, los multiplexores 346347348349 y el Crossbar 350 son componentes del operand delivery network 240 (mostrado en la  FIG. 1B).

Bueno, nada nuevo por el momento, solo es lo anterior con más detalle.

El bloque Super-SIMD 300 incluyen RAM de almacenamiento VGPR 320, estas pueden ser configuradas como grupos de RAM en cuatro bancos 320a320b320c320d. Donde cada uno de ellos incluyen MxNxW b its de datos donde M es es el número de lineas de palabra de la RAM, los cuatro bancos tienen 4xM VGPR y la configuración clasica (por banco del VGPR) es de 64x4x32 bits, el cual puede mantener 4 hilos VGPR en contexto de 64 entradas con 32 bits por hilo. Los VGPR contiene unos 4×32 bits de datos en esta implementación.

El motivo de estas cifras y el funcionamiento e influencia de los VGPR en la ejecución de las instrucciones algo en lo que en esta entrada para no sobrecomplicar las cosas no entrare. En esta solo hare una definición general de lo que será la Compute Unit de la arquitectura Post-GCN.

El bloque Super-SIMD 300 incluyen unidades de ejecución vectorial 360. Cada una de ellas incluyen dos colecciones de ALUS 362a362b y una colección de ALUs de acompañamiento 365,  cada una teniendo un número de ALUs que equivale a la anchura de la unidad SIMD. Ambas combinadas forman una ALU completa 367. La ALU Completa 367 es la segunda ALU 230 en la FIG 1B, la Core ALU 362b es la primera ALU 220 de la FIG. 1B

En una implementación las Core ALU 362a, 362b tienen N multiplicadores para ayudar a realizar ciertas operaciones como el fused multiply-add (FMA). Es una  implementación las ALU de acompañamiento 365 no tienen multiplicadores pero pueden ayudar a implementar las operaciones no esenciales como la conversión de instrucciones. Las unidades de acompañamiento pueden trabajar con cualquiera de la Core ALUs 362a362para ayudar a finalizar operaciones complejas como instrucciones trascendentales.

¿Significa esto que tenemos 3 ALUs? ¿Donde he oido hablar yo de esas instrucciones trascendentales?

thinking-guy-meme

Ah si… Ahora me acuerdo, es lo que llamamos instrucciones complejas y es uno de los elementos en los que Nvidia tiene una ventaja enorme sobre AMD. Si me permitís voy a salirme de la patente y de AMD… En las unidades de Nvidia existen las SFU (Special Function Units) las cuales se encargan de la ejecución de las intrucciones trascendentales como son:

  • Operaciones Trigonométricas.
  • Raices Cuadradas

Son las llamadas instrucciones complejas, volviendo a la patente esto significa que de las dos intrucciones que podemos enviar por ciclo, podemos enviar 2 instrucciones simples o 1 instrucción simple y 1 compleja. La Side ALU debería acelerar la ejecución de las instrucciones complejas, permitiendo su ejecución en 1 o 2 ciclos solamente en vez de los clásicos 4 ciclos y acelerar el código.

Aunque fijaos que por el momento N no lo tenemos definido.

La Destinacion Cache  370 esta desplegada para proveer dos instrucciones SIMD4 durante cada ciclo a toda velocidad.

¿Recordáis que comentamos que el tamaño de los VGPR era de MxNxW? W esta claro que es el ancho estandar del registro pero N se nos ha definido como 4 y es el mismo valor N que las N ALUs si os fijáis. Esto significa que hemos sustituido 1 unidad SIMD16 no por 2 unidades SIMD16 sino por 2 unidades SIMD4. Bajo este nuevo paradigma cada Compute unit a la hora de ejecutar un Wavefront tardaría por tener una configuración de ALUs más estrecha unos 16 ciclos de reloj en vez de 4 por Wavefront, pero sobre el tema de la ejecución ya hablare en otra entrada para no sobrecomplicar esta.

FIG3Navi

La FIG. 3 ilustra una copmpute unit de ejemplo con cuatro bloques super-SIMD, dos unidades de texturas, un planificador de instrucciones y un almacenamiento local

En conjunción con los super-SIMD  200 a,b,c,d la Compute Unit basada en Super-SIMD puede incluir un SQ 410, una ILDS 420, dos unidades de texturas 430 a, b conectadas a dos caches L1 440 a, b también referidas como TCP. LDS puede utilizar 32 bancos en 64KB o 128 dependiendo de la aplicación que se le quiera dar. La Cache L1 440 puede ser de 16KB o del tamaño adecuado de la cache.

La Compute Unit basada en Super SIMD peude proveer el mismo ratio de ALU: textura encontrada en una clasica Compute Unit.

El ratio es siempre de 16 a 1, por lo que en vez de la clásica configuración de 4 unidades de texturas por Compute Unit tenemos una con 2 unidades de texturas. Pero es que además la patente tiene la explicación de una Compute Unit más simple aún, no voy a entrar a ella porque los componentes son exactamente los mismos que en la FIG 3. Solo que reducidos a la mitad y en casos como el planificador/SQ obviamente más simples al no tener que alimentar una mayor cantidad de Super-SIMDs

FIG4NAVI

La patente no describe una GPU completa, solo la nueva Compute Unit por lo que no sabemos en absoluto como se organiza el resto de la GPU realmente simple y llanamente porque la patente no nos la describe. En todo caso teniendo en cuenta el ratio de 16 ALUs por Texture Unit entonces si por ejemplo quisieramos tener el equivalente a la GPU de Xbox One X en la nueva arquitectura tendríamos unos 160 CUs Post-GCN en vez de las 40 CUs GCN. Y se que para muchos esta entrada es muy, pero que muy técnica y en realidad tengo que aclarar que he dejado muchas cosas en el tintero como es la planificación en la ejecución de las diferentes instrucciones que difiere enormemente de la arquitectura GCN dada la organización de la nueva Compute Unit, lo cual lo dejare para la segunda parte de esta entrada.