Perdonad a todos, he estado unos días en cama con una migraña de cuidado, de ahí a que el ritmo de las entradas haya bajado. No prometo nada porque he decidido invertir más tiempo en el libro, el cual se me iba acumulando en cuanto a trabajo hasta arriba del todo.Esta entrada es una continuación de la de ayer, ambas estaban preparadas para publicarse una después de la otra, realmente no estoy muy contento con el resultado y pienso que esta entrada es bastante…

Hace os deje la primera parte de como AMD va a integrar las llamadas Neural Networks, Procesadores de IA, Tensor Units y demás lio de nombres que sinceramente hacen que a uno y sobretodo a los lectores la cabeza nos vaya a…

Os comente como AMD piensa utilizar más bien los llamados «Motores de Inferencia» para que estos se encargarán de la codificación-descodificación de video cuando no tuviesen que hacer ninguna de las tareas relacionadas con la Inteligencia Artificial pero se me olvido aclarar una serie de cosas y para ello tenemos que ir a otras patentes, no os preocupéis que no vamos a irnos a un mundo desconocido y dificil de entender, el menos eso espero.

Vamos a ver en la segunda patente titulada MACHINE LEARNING INFERENCE ENGINE SCALABILITY.

En la FIG. 1 vemos los motores de aceleración de inferencia conectados a un Northbridge/Data Fabric, recordad que en AMD desde los SoC con Ryzen la GPU ha perdido por completo su Northbridge privado y sus aceleleradores han ido a parar todos al Northbridge/DataFabric Universal que fue implementado por primera vez en el Summit Ridge en adelante y se va a mantener muchos años en los SoC de AMD.

La patente plantea varias configuraciones en cuanto a motores de inferencia, no se refiere a uno solo por lo que nos da varios ejemplos para ello, el primero de ellos el de la FIG. 2

FIG. 2 es un diagrama de bloques de una implementación de un motor acelerador de inferencia multinúcleo.

Dejemos que la segunda patente nos explique la configuración.

Pasando ahora a la FIG. 2, se muestra un diagrama de bloques de una implementación de un motor acelerador de inferencia multinúcleo 200. En una implementación, el motor acelerador de inferencia multinúcleo 200 incluye 16 núcleos de inferencia separados 201-216. En otras implementaciones, el motor acelerador de inferencia multinúcleo 200 incluye otros números de núcleos de inferencia separados. En una implementación, cada conjunto de cuatro núcleos de inferencia constituye un grupo separado. En consecuencia, el grupo 221 incluye núcleos de inferencia 201-204, el grupo 222 incluye núcleos de inferencia 205-208, el grupo 223 incluye núcleos de inferencia 209-212 y el grupo 224 incluye núcleos de inferencia 213-216. En una implementación, un «clúster» se define como una colección de núcleos de inferencia. Los grupos 221-224 están acoplados a los hubs 231-234. Cada uno de los hubs 231-234 incluye una jerarquía de memoria y lógica de interconexión para conectar entre sí los núcleos de inferencia de los grupos correspondientes 221-224, respectivamente. La arquitectura de los hubs 231-234 proporciona una manera de administrar eficientemente el movimiento local y el almacenamiento de datos que se requiere para cada uno de los núcleos de inferencia 201-216 para los grupos 221-224, respectivamente.

Pero si nos vamos a la FIG. 3 nos describen otro tipo de implementación para los motores de inferencia donde los 16 motores de inferencia se encuentra agrupados en un mismo grupo.

Básicamente la patente nos menciona otro tipo de organización para los motores de inferencia aparte del previamente mencionado.

Con referencia ahora a la FIG. 3, se muestra un diagrama de bloques de una implementación de una disposición de núcleos de inferencia 301-316. En el escenario ilustrado en la FIG. 3, un motor acelerador de inferencia multinúcleo tiene 16 núcleos de inferencia. Debe entenderse que en otras implementaciones, un motor acelerador de inferencia multinúcleo puede tener otros números de núcleos de inferencia.

Luego también nos menciona el mismo tipo de configuración que vimos ayer como una tercera configuración.

Que es precisamente la que vimos en la entrada anterior. Y de nuevo tenemos la explicación a esta configuración y nos vuelven a dejar claro que esto es una posible implementación.

Pasando ahora a la FIG. 4, se muestra un diagrama de bloques de una implementación de un motor acelerador de inferencia multinúcleo 400. En una implementación, la lógica del motor acelerador de inferencia multinúcleo 400 se implementa como el motor acelerador de inferencia 105 (de la figura 1) dentro del sistema 100. En una implementación, el motor acelerador de inferencia multinúcleo 400 incluye la unidad de control 410, lógica 415, interfaz de memoria 420, tejido 425, redes de comunicación 430A-N y elementos de procesamiento 435A-N. En una implementación, cada conjunto de elementos de procesamiento 435A-N es un núcleo de inferencia separado. Por ejemplo, en esta implementación, los elementos de procesamiento 435A corresponden al primer núcleo de inferencia (por ejemplo, el núcleo de inferencia 301 (de la figura 3)), los elementos de procesamiento 435B corresponden a un segundo núcleo de inferencia (por ejemplo, el núcleo de inferencia 302), y así sucesivamente.

Debe entenderse que el ejemplo del motor acelerador de inferencia multinúcleo 400 mostrado en la FIG. 4 es meramente indicativo de una implementación particular.

¿Para que tantas configuraciones distintas? El motivo de ello es que según el tipo de de red neural utilizada la organización de los motores de inferencia sería una u otra.

¿Significa esto que AMD va a lanzar varios tipos de motores de inferencia? No exactamente, esto nos lo aclaran en el siguiente párrafo:

En esta implementación, la unidad de control 605 usa la indicación para buscar el campo 615 de la tabla 610 para una entrada coincidente. En una implementación, la unidad de control 605 también usa la capa que se está implementando para buscar el campo de capa 620. Por ejemplo, un modelo de aprendizaje automático dado puede usar diferentes esquemas de reducción de ancho de banda de memoria para diferentes capas del modelo.

Cuando se encuentra una entrada coincidente, la unidad de control 605 recupera la indicación del campo del esquema de reducción de ancho de banda de memoria 625 en la entrada coincidente. Luego, la unidad de control 605 programa un motor acelerador de inferencia multinúcleo (por ejemplo, el motor acelerador de inferencia multinúcleo 105 de la figura 1) para implementar este tipo particular de esquema de reducción de ancho de banda de memoria. Estas acciones se realizan de forma dinámica o estática según la implementación. En una implementación, para el primer esquema de reducción de ancho de banda de memoria, el núcleo de inferencia 1 transmite datos a los núcleos de inferencia 2-16. Para el segundo esquema de reducción de ancho de banda de memoria, el núcleo de inferencia 1 difunde datos a los núcleos de inferencia 2-8 y el núcleo de inferencia 9 difunde datos a los núcleos de inferencia 10-16. Para el tercer esquema de reducción de ancho de banda de memoria, el núcleo de inferencia 1 difunde datos a los núcleos de inferencia 2-8, el núcleo de inferencia 9 difunde datos a los núcleos de inferencia 10-12, y el núcleo de inferencia 13 difunde datos a los núcleos de inferencia 14-16. Debe entenderse que estos ejemplos de esquemas de reducción de ancho de banda de memoria son ilustrativos de una implementación particular. Otras implementaciones utilizarán otros tipos de esquemas de reducción de ancho de banda de memoria. Se observa que el campo de descripción 630 se muestra en la FIG. 6 simplemente para proporcionar una descripción del tipo de esquema de reducción de ancho de banda de memoria 625 para los propósitos de esta discusión. En consecuencia, la implementación real de la tabla 610 no incluye el campo 630. Además, debe entenderse que el ejemplo del campo del esquema de reducción de ancho de banda de memoria 625 correspondiente a 16 núcleos de inferencia es indicativo de una implementación. En otras implementaciones, el campo del esquema de reducción de ancho de banda de memoria 625 se asigna a motores de aceleración de inferencia con otros números de núcleos de inferencia.

Por lo que tenemos que lo importante es como están comunicados los motores de inferencia entre si. ¿Con que configuración podemos conseguir esto? Pues la solución es colocar los motores de inferencia en malla, formando un NoC donde cada motor de inferencia se pueda comunicar directamente con otros como si fuese una red local. Es decir, que cada uno de ellos tenga un router para ello.

Además, pero para ello la unidad de control 605 tendría que permitir que el conjunto de motores de inferencia soportasen ejecución MIMD para completar el puzzle.

Por cierto, un pequeño inciso… Durante el año pasado, durante el CES, AMD dejo ir una diapositiva donde comentaban que iban a integrar FPGAs en sus SoC/APU y no lo hemos visto todavía.

Los FPGA por el hecho de como están distribuidos permite crear configuraciones en malla del tipo MIMD que las hace ideales para el Deep/Machine Learning

Pero son menos eficientes que los ASICs dedicados, en realidad en el ASIC dedicado la configuración es la misma solo que sin las limitaciones del FPGA por la capacidad de configurar sus puertas lógicas y por otro lado la configuración MIMD con las ALUs puestas en malla ha sido la que ha sido escogida por la mayoría de fabricantes para montar sus unidades de IA, que realmente no son otra cosa que unidades del tipo Tensor.

Pe… pero… Urian… ¿Que es un Tensor?

Un tensor realmente no es un tipo de núcleo sino que es un contenedor de datos realmente. Para almacenar datos solemos utilizar datos organizados en diferentes unidades.

  • Si el dato es unitario lo llamamos escalar.
  • Si los datos estan organizado en una columna o una linea de datos lo llamamos vectorial
  • Si los datos están organizados en columna y en linea lo llamamos matriz.

¿Pero es posible organizar los datos en tres dimensiones? Por supuesto.

Imaginad que tenéis una lista de contactos, todos ellos tienen las misma tablas, pues podéis organizarlos en forma de matriz en 3D donde el eje de profundidad de la matriz ordene las fichas según el número de cliente. Con ello habéis obtenido lo que es un Tensor en 3D, el tipo de Tensor más simple de todos ellos, porque los hay en 3D, en 4D, 5D…

Pe, pero Urian, nuestra mente no da para ver más de tres dimensiones.

El truco esta en convertir conceptualmente el Tensor en 3D en un cubo… El Tensor en 4D en un vector de cubos, el 5D en una matriz de cubos, el 6D en un cubo de cubos… ¿Se va cogiendo el concepto de Tensor? No deja de ser una forma de organizar los datos. El caso es que a partir de una estructura de datos en tres dimensiones lo llamamos tensor.

En los artículos de inteligencia artificial habréis visto mucho el concepto de «se ha alimentado la IA con n cantidad de muestras» a lo que se refieren es que alimentan la IA con una colección de datos del mismo tipo. Si habéis programado en algún lenguaje con sintaxis tipo C sabréis que cada función puede tener o no una serie de parámetros de entrada. Pues de la misma manera que podemos colocar como parametro de entrada un valor escalar, vectorial o matricial, también podemos colocar un tensor.

AMD afirma que quiere utilizar las motores para la inferencia para la descodificación de un video. Supongamos que queremos organizar las imágenes de un vídeo y como es obvió un vídeo no deja de ser una sucesión continua de imagenes (fotogramas), pero para acelerar la decodificación lo que se hace es decodificarlas por bloques más pequeños de nxn pixeles, es decir, son divididas en tiles.

¿En que tamaño de bloque trabaja el codec HEVC y el H.264/AVC?

Donde el H.264 / AVC define macrobloques de hasta 16 × 16. píxeles, el HEVC puede describir un rango mucho mayor de tamaños de bloque, hasta 64 x 64 píxeles.

Supongamos que cada uno de estos bloques enteros es una matriz y que podemos apilar estos bloques en una sucesión de matrices, almacenando el fotograma en un tensor que es una sucesión de esos bloques de 64×64 pixeles si estamos en HEVC o una sucesión de bloques de 16×16 si hablamos de H.264/AVC.

En cada pixel de cara al color tenemos unos 3 datos (en realidad 6 si separamos matiz y luminancia) pero los dejaremos en los clásicos 3 canales de color (R, G, B) y soy consciente de que tenemos ahora mismo formatos de imagen que superan el clasico RGB888 gracías a la aparición del HDR en el video desde hace unos años. Esto significa que podemos dividir cada bloque en 3 sub-bloques. Cada uno representando un canal de color distinto.

¿Para que esto? Esto se hace porque los núcleos para la IA no suelen trabajar más allá de los 16 bits de precisión y una imagen RGB es minimo de 24 bits, con esto podemos asignar cada canal de color de un pixel a un núcleo Int8 y procesarlo. Con ello hacemos la longitud del eje Z del Tensor más grande pero no aumentamos la cantidad de datos y hacemos posible el tratamiento de imágenes utilizando las ALUs de baja precisión.

En la patente que comente el otro día, nos hablan de que el motor de inferencia esta formado por unidades MAC que ejecutan la formula:

(a*b)+c

Que es la misma formula que utiliza Nvidia como ejemplo para sus Tensor Cores, fijaos como a, b y c tienen cada uno una dimensión distinta dentro del Tensor…

En realidad los Tensor son una configuración NoC, el resultado de (a+b) es enviado directamente a las ALUs esperando el resultado y ejecutan el «+c» y esto lo pueden hacer por estar directamente enrutadas entre si.

Volviendo al tema de AMD, si lo quieren utilizar para la codificación/descodificación de video en HEVC entonces tiene sentido una matriz de 64×64 ALUs, esta matriz sería enorme, pero podemos subdividirla en 4 matrices de 16×16 ALUs y esta en 16 matrices de 4×4 ALUs. Si os parece una burrada colocar unas 4096 ALUs Mac, tened en cuenta que en el caso de Nvidia por cada unidad SM tanto Volta como Turing tienen por cada SM un total de…

¡512 ALUs por unidad SM! Sumadle a esto que se puede asignar una ola a dos unidades Tensor, habiendo dos de ellas en cada uno de los cuatro sub-bloques de un SM (uno por ola)… ¡Pues la cifra de 4096 ALUs para la decodificación no parece tan enormemente grande! Y si, se que las patentes no mencionan ese tamaño paro es para poner en perspectiva las cosas.

¡8 Tensor Cores con 64 ALUs en FP64 cada una! Dado Nvidia trabaja con olas de 32 elementos agrupados y tenemos unos 8 Tensor Cores (32*8=256) podemos procesador en todo el SM una matriz de 16×16, que realmente sea una de 8x4x8.

Podemos procesar cada grupo en dos matrices de 4×4 ALUs. En el caso de AMD en cambio con la llegada de RDNA, hay una versatilidad a la hora de escoger el tamaño de la ola, pero AMD parece haber adoptado también olas de 32 con RDNA también es compatible con las de 64.

Pero en AMD al contrario de lo que ocurre con Nvidia nos encontramos que los motores de inferencia no se encuentran dentro de las Compute Units sino en unidades aparte, esto nos lleva a la tercera patente.

En la patente titulada METHOD AND SYSTEM FOR HARDWARE MAPPING INFERENCE PIPELINES lo primero que llama la atención es el diagrama de la FIG. 3.

No vemos en ella ninguna mención a las unidades de aceleración por ningún lado. El diagrama no es algo fijo, en la misma patente nos lo dejan bien claro que no es más que un diagrama orientativo y de ejemplo.

La FIG. 3 ilustra una plataforma 300 de arquitectura de sistema heterogéneo (HSA) basada en parte en los dispositivos de las figs. 1 y 2. La plataforma HSA 300 incluye una Unidad de Procesamiento Acelerado (APU) HSA 310 conectada o en comunicación (colectivamente «conectada») a una memoria del sistema 350. La APU 310 de HSA contiene una CPU 320 de múltiples núcleos, una GPU 330 con múltiples unidades de cómputo HSA (H-CU) 332, 334, 336 y una unidad de administración de memoria HSA (HMMU o HSA MMU) 340. La CPU 320 incluye cualquier número de núcleos, con núcleos 322, 324, 326, 328 mostrados en la Fig. 3. La GPU 330 incluye cualquier número de H-CU aunque tres se muestran en la FIG. 3. Si bien una HSA se discute y presenta específicamente en las implementaciones descritas, el presente sistema y método pueden utilizarse en un sistema homogéneo o heterogéneo. La memoria del sistema 350 incluye una o ambas de la memoria del sistema coherente 352 y la memoria del sistema no coherente 357.

H-CU hace referencia a una unidad Compute Unit con soporte HSA, si somos estrictos fue a partir de Carrizo en SoCs y Polaris en GPUs dedicadas cuando las GPUs pasaron a tener soporte completo HSA por lo que esto descarta de entrada cualquier SoC/APU previo a Carrizo y cualquier GPU dedicada anterior a Polaris. Las H-CU, no son nada extraño ni nuevo, son Compute Units que independientemente de la arquitectura de las mismas tienen acceso HSA a la memoria, esto significa que tienen los mecanismos de coherencia en forma de la Access Traslation Cache.

Ahora bien, no todas las operaciones de una GPU necesitan operar con una visión coherente con la CPU, hay secciones de la misma que no lo necesitan como es el codec de vídeo o el adaptador de pantalla. Ambas unidades controladas por la propia GPU de manera directa… ¿Pero como? La patente nos explica como se realiza dicha comunicación.

Los dispositivos en el HSA 300 se comunican entre sí utilizando colas como se explica adicionalmente con referencia a las Figs. 4-6. Las colas son una parte integral de la arquitectura HSA. Una cola es un área de memoria física donde un productor realiza una solicitud para un consumidor. Dependiendo de la complejidad del hardware HSA, las colas pueden ser administradas por cualquier combinación de software o hardware. Las colas gestionadas por hardware tienen una ventaja de rendimiento significativa en el sentido de que una aplicación que se ejecuta en procesadores de latencia (como la CPU 320) trabaja directamente en procesadores de rendimiento (como la GPU 330), sin la necesidad de realizar ninguna llamada al sistema operativo. Esto permite una comunicación de muy baja latencia entre los dispositivos en el HSA 300.

Una cola no es más que una lista circular que en el caso de las GPUs son gestionadas por el Procesador de Comandos o por varios Procesadores de Comandos. Cuando el contador de programa llega a la última dirección de memoria de la cola inmediatamente vuelve a la primera y por eso es circular y un búfer en anillo. Son ampliamente utilizados por los Procesadores de Comandos de las GPUs, los cuales leen la cola o una serie de colas de una parte de la memoria y las mapean en su memoria interna.

Dichas colas llevan consigo el microcódigo que luego el procesador de comandos utilizará para dirigir el resto de la GPU y no solo el renderizador sino todos los elementos de la misma, incluidos las unidades aceleradoras como los codecs de video, el adaptador de pantalla. Si nos vamos a las FIG. 4 a 6 de la patente se puede ver.

En cambio la FIG. 6 nos hace mención a la relación de los Command Processors con los nuevos motores de inferencia.

Y su explicación dice así:

La FIG. 6 es un diagrama de bloques de un sistema 600 que ilustra el mapeo de un pipeline de inferencia 605 a la arquitectura de tipo habilitada para HSA 610. El pipeline de inferencia 605 tiene múltiples capas de red DNN que incluyen la capa de red i, la capa de red i + 1, la capa de red i + 2 , capa de red i + 3, y así sucesivamente. Cada una de la capa de red i, capa de red i + 1, capa de red i + 2, capa de red i + 3, etc., puede representar diferentes tipos de capa de red DNN, que incluyen, entre otros, una capa de red convolucional, una red de activación capa y una capa de red totalmente conectada.

De acuerdo con las descripciones en este documento, la arquitectura de tipo habilitada para HSA 610 tiene múltiples colas que incluyen cola i, cola i + 1, cola i + 2, y así sucesivamente que están conectadas a una unidad de cálculo asociada i, unidad de cálculo i + 1, calcule la unidad i + 2, y así sucesivamente. Cada cola i, cola i + 1, cola i + 2, etc. incluye múltiples elementos 615, donde cada elemento 615 representa la tarea a ejecutar para una entrada particular, p. Entrada1, Entrada2 y Entrada3, o un mini lote para el procesamiento de inferencia.

Lo primero que podéis llegar a pensar es que las unidades de inferencia están dentro de las Compute Units o que incluso las Compute Units donde se ejecutan los shaders también ejecutan programas de inferencia, lo cual es la forma en la que actualmente GPUs como Vega ejecutan y lo mismo ocurre con una variante de Navi que sabemos que existe.

Pero la realidad es que a las Compute Units que hace referencia son las Compute Units para la inferencia que es muy probable que sean Compute Units pero con las unidades de ejecución cambiadas, es decir, Compute Units que no tienen las clásicas unidades SIMD ni las unidades de texturas, sería como si Nvidia sacase una unidad SM que solo tuviese Tensor Cores en las unidades de ejecución.

Con esto tenemos el puzzle ya casi montado, por otro lado hace unas semanas os puse una entrada donde hable de Arcturus donde no sabía que pintaba la unidad VCN 2.5, con todo esto el puzzle esta completo y tenemos una explicación que hace el codec de video en una GPU sin salida de video y pensada para computación e ia… El VCN 2.5 no son más que los motores de inferencia, las llamadas Tensor Units.

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