Source: http://disruptiveludens.com/el-codec-de-videomotor-de-inferencia-de-amd
Timestamp: 2020-08-05 04:32:51+00:00

Document:
El Codec de Video+Motor de Inferencia de AMD. – Disruptive Ludens
AMD, Conceptos Básicos, Deep Learning, Feedback, Futuro, Inteligencia Artificial, Uncategorized
El Codec de Video+Motor de Inferencia de AMD.
Publicado por Urian en junio 4, 2020
Gracias x la entrada Urian. Si así fuera el VCN 3.0, serviría para algo similar al dlss 2.0 de nvidia, no conozco del tema, pero el frame aumentado en resolución y mejorado x este último se procesa en base a una fuente de video o de render para procesar la imagen final y representarla en el monitor?
En teoría se deberiía poder, pero primero de todo necesitamos entender que es concretamente el DLSS 2.0.
Se trata de un algoritmo de Deep Learning donde la Inferencia del mismo es ejecutada en lo que falsamente Nvidia llama «Tensor Cores» desde su marketing, el motivo por el cual dicha afirmación es falsa es porque no son «Cores» al carecer de una unidad de control e incluso registros propios ya que los tiene compartidos con los también erronamente llamados núcleos CUDA por lo que tienen que funcionar de manera conmutada, es decir, que unos solo funcionan cuando lo hacen los otros.
Esto provoca que los Tensor Cores de cara a utilizarlos como asistencia al renderizado 3D solo se puedan utilizar cuando los núcleos CUDA no están activos y en un periodo de tiempo muy corto, lo que lleva a que la tasa de velocidad por unidad de tiempo (Los llamados TOPS, TFLOPS y el resto) tenga que ser muy rápida debido a que necesitamos que la máquina haga esa cantidad de trabajo en un tiempo muy limitado.
El DLSS se puede resumir de la siguiente manera:
Coste en tiempo de Resolución Nativa Objetivo > Coste en tiempo de Resolución Base+Tiempo de Aplicar el algoritmo DLSS.
Es decir, si una GPU me tarda unos 15ms en renderizar una imagen a una resolución determinada A, 10ms en hacerlo en hacerlo en otra más baja B entonces la clave del DLSS para convertir de la resolución más baja B a la más alta A es que el DLSS cueste una porción del tiempo inferior de lo que cuesta hacerlo en la resolución más alta de manera nativa, pongamos que 2ms. Entonces via DLSS el juego tendría una salida de imagen equivalente a A pero sería solo una predicción utilizando el algoritmo de inferencia y los datos de B como base, pero nos encontramos con que de 15ms hemos pasado a 12ms y por tanto la tasa de fotogramas habrá aumentado por el hecho de que el tiempo por fotograma habrá disminuido.
La tecnología parece mágica en principio pero para tener un algoritmo de inferencia primero hemos de entrenar la Inteligencia Artificial para que tenga la capacidad de «sacar conclusiones» a partir de una premisas que son los datos que se de a procesar al algoritmo de inferencia.
La GPU cuando renderiza una imagen no dibuja como nosotros de manera ordenada sino que va colocando los pixeles en el búfer de imagen de manera desordenada hasta tener el búfer final por lo que como dices el DLSS 2.0 tiene que funcionar con el búfer final y a partir de esa información alucinar los pixeles en una resolución más alta pero…¿Podemos esperar la misma potencia en el caso del supuesto motor de Inferencia de AMD incluido en el VCN 3.0? Y lo que viene a continuación es una explicación de que no se puede y que la idea del Codec de Video con Motor de Inferencia integrado no es para algo como el DLSS 2.0.
Hay que tener en cuenta que la unidad VCN es es una unidad no-programable y no solamente fuera de las Compute Units, también esta fuera de los Shader Engines e incluso esta más allá del área de la Cache L2 siendo el único punto de comunicación la memoria de la GPU provocando una enorme latencia en la comunicación cosa que no ocurre con los Tensor Cores de Nvidia, es más, tu no podrías ejecutar ningún programa que Shader que los utilizará por estar fuera la unidad de Inferencia de las Compute Units.
Pero si miramos la mayoría de SoCs con alguna unidad dedicada a la IA en el mercado de los smarthphones por ejemplo veremos que muchos de ellos tienen núcleos aparte de la GPU para la IA como un cliente adicional del Northbridge. Son las llamadas Neural Processor Units y las podemos encontrar en los SoCs de Apple, Qualcomm… Y muchas otras. AMD tiene precisamente una patente titulada MACHINE LEARNING INFERENCE ENGINE SCALABILITY que esta relacionada con la patente de las unidades de codificación y decodificación de video con motores de inferencia y que toma el mismo modelo que los SoC para dispositivos Post-PC con este tipo de unidades separada de la GPU, en realidad son dos caras de la misma moneda.
En realidad ya desde el primer diagrama de la patente queda claro que los múltiples motores de inferencia quedan conectados al Northbridge.
Por lo que no estamos en una unidad dentro de la GPU sino que se trata de un procesador aparte.
La siguiente parte de la organización requiere un poco de descripción más detallada.
En cuanto 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 juntos 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.
En realidad la FIG 2. de la patente y la FIG. 4 son lo mismo pero con dibujos diferenciados.
Para entenderlo mejor os lo resumo:
Tenemos 4 concentradores a los que a cada uno se le conecta unos 4 Núcleos de Inferencia/Elementos de Procesamiento.
A cada Núcleos de Inferencia/Elemento de Procesamiento se le coloca al lado otro igual.
Los Núcleos de Inferencia/Elemento de Procesamiento no tienen sistemas de caches ni de memoria. sino que el dato a procesar que reciben lo reciben de los Núcleos de Inferencia/Elementos de Procesamiento que tienen colindantes tanto horizontalmente en la malla como verticalmente.
¿Pero como de ancho es cada array de Núcleos de Inferencia/Elementos de Procesamiento? Pues por lo que parece ser de 16 elementos, es decir… 4 Hubs tienen 4 arrays que a su mismo vez tienen cada uno 16 elementos, pero tened en cuenta que la patente deja bien claro que la cantidad de motores de inferencia puede ser cualquiera, en todo caso el ejemplo quedaria de la siguiente manera:
¿Pero cuantos puede llegar a tener realmente? Bueno, lo que esta claro es que cada uno de los 4 concentradores estaria conectado a una interfaz Infinity Fabric, la cual funciona 32 bytes/ciclo por lo que son 16 bytes/ciclo en cada una de las dos direcciones y debido a que el estándar para la IA es el BF16 vamos a suponer que cada ALU es de 16 bits y por tanto exporta e importa datos de 16 bits, esto significa que más bien nos encontrariamos con esto por Hub.
Una matriz de 16×16 elementos y con 4 hubs tenemos unas 4 matrices de 16×16 elementos en total. ¿Os parece mucho? Pues echadle un vistazo a los Tensor Cores de Volta y Turing…
Cada Tensor Core es un array/matriz sistólica de 4×16 y tenemos un total de 8 por lo que la cantidad de ALUs en total es de 512 y esto solo en una SM… ¿Y cuanto ocupa esto? Menos de 1mm2 en total en el caso de Turing y Volta que no utilizan el nodo de 7nm, es decir, es algo cuyo coste de implementación es ínfimo realmente pero la unidad de inferencia que obtendríamos de manos de AMD sería mucho menos potente que los Tensor Cores de Nvidia al ser una pequeña unidad, la ventaja es que se podría utilizar en paralelo pero no tenemos la velocidad, es decir, la tasa para poder aplicar el DLSS 2.0 lo suficientemente rápido.
Con un total de 512 núcleos la potencia que tendríamos en FP16 sería <1.8 TFLOPS en FP16/BF16, con ello os podéis imaginar directamente que aplicar algo como el DLSS 2.0 es imposible por el hecho de que la tasa sería demasiado baja en comparación con los chips de Nvidia para dicha tarea. Y si, todo este viaje la mar de complicado en el que alguno se habrá mareado viene para explicar que el DLSS 2.0 no sería viable en esta solución de AMD.
La otra cara de la moneda es la patente INTEGRATED VIDEO CODEC AND INFERENCE ENGINE que esta relacionada con la anterior, en su descripción inicial podemos leer lo siguiente:
Se describen sistemas, aparatos y métodos para integrar un códec de video con un motor de inferencia. Un sistema está configurado para implementar un motor de inferencia y un códec de video mientras comparte al menos una parte de sus elementos de procesamiento entre el motor de inferencia y el códec de video. Al compartir elementos de procesamiento al combinar el motor de inferencia y el códec de video, se reduce el área de silicio de la combinación. En una realización, la porción de elementos de procesamiento que se comparten incluyen un motor de predicción de movimiento / estimación de movimiento / MAC con una pluralidad de unidades de multiplicador-acumulador (MAC), una memoria interna y periféricos. Los periféricos incluyen una interfaz de memoria, un motor de acceso directo a memoria (DMA) y un microprocesador. El sistema está configurado para realizar un cambio de contexto para reprogramar los elementos de procesamiento para cambiar entre los modos de operación. El cambio de contexto puede ocurrir en un límite de trama o en un límite de subtrama.
Todas las figuras de la patente son comunes con la anterior pero hay una que es diferente que es la FIG. 3. Con la cual entendemos como se implementa el codec de video
Pasando ahora a la FIG. 3, se muestra un diagrama de bloques de una implementación del funcionamiento de un motor de inferencia 306 dentro de un sistema. En diversas implementaciones, el motor de inferencia 306 se implementa como parte del códec de video combinado y el motor de inferencia 105 (como se muestra en la figura 1).
En una implementación, el motor de inferencia 306 está configurado para recibir datos de imagen de entrada, que pueden ser un cuadro de un flujo de video. En una implementación, los datos de imagen de entrada son generados por una fuente que es diferente del códec de video. En otra implementación, los datos de imagen de entrada proporcionados al motor de inferencia 306 son generados por el códec de video. Dependiendo de la implementación, se pueden realizar una o más operaciones en los datos de imagen de entrada antes de que el motor de inferencia 306 reciba los datos. Por ejemplo, la imagen de entrada se puede redimensionar opcionalmente en la unidad 302. Además, el archivo de imagen media se puede restar de la imagen de entrada en la unidad de resta media 304. En una implementación, la salida de la unidad 304 incluye tres canales de color. En otras realizaciones, la salida de la unidad 304 puede ser la imagen en otros formatos (por ejemplo, YCbCr, YUV, ARGB) y / o con otros números de canales de componentes de color. La salida de la unidad 304 está acoplada al motor de inferencia 306.
En una implementación, el motor de inferencia 306 se implementa como una red neuronal convolucional entrenada. Por ejemplo, el motor de inferencia 306 se expande en la red neuronal convolucional 310 para indicar una posible implementación del motor de inferencia 306. En otras realizaciones, el motor de inferencia 306 puede implementarse como otros tipos de aprendizaje automático y modelos de sistemas expertos. Como se muestra en la FIG. 3, la red neuronal convolucional 310 incluye nueve capas. Las capas 1-5 son capas de convolución y las capas 6-9 son capas de clasificación. Sin embargo, debe entenderse que esta es simplemente una posible implementación de una red neuronal convolucional. En otras realizaciones, la red neuronal convolucional 310 puede incluir otros números y / u otros tipos de capas.
En una implementación, el motor de inferencia 306 genera vectores de probabilidad pronosticados que se proporcionan a la unidad de generación de etiquetas 308. La unidad de generación de etiquetas 308 también recibe un archivo de etiquetas como entrada, y la unidad de generación de etiquetas 308 produce etiquetas generadas 312 en base a los vectores de probabilidad pronosticados y archivo de etiquetas. Por ejemplo, en una implementación, el motor de inferencia 308 está configurado para detectar ciertos objetos en la imagen de entrada. Cada etiqueta de etiquetas generadas 312 puede incluir una probabilidad de que se haya detectado un objeto correspondiente en la imagen de entrada.
¿Como es que he subrayado esto? Bueno, para ello hemos de ir a una tercera patente de la propia AMD titulada Exploiting Camera Depth Information for Video Encoding. Para aplicar sobre ella después un poco de pensamiento lateral. Cuando lees el título de la patente en principio puedes pensar que hace referencia al uso de cámaras RGB+IR o RGB+Tiempo de Vuelo pero no, la patente nos describe en principio otra utilidad.
La presente descripción esta directamente asociada con explotar la información de cámara y profundidad relacionada con fotogramas de video renderizados, como aquellos que son renderizados por un servidor en un servició de juegos en la nube a través de una red. El método y sistema de la presente descripción se puede utilizar en el servidor de un servició de juegos en la nube para mejorar por ejemplo, la cantidad de latencia, el ancho de banda de bajada y el poder computacional asociado a jugar con un videojuego y su servició. El método y sistema de la presente descripción puede ser utlizado en otras aplicaciones donde la información de cámara y profundidad de un fotograma de video capturado este disponible.
La idea de la tercera patente es muy simple, imaginemos que a cada objeto de la escena le damos una etiqueta… ¿Pero como podemos diferenciar los objetos? Bueno, la realidad es que en una escena 3D cada objeto tendrá un valor Z común en teoría respecto a la cámara.
Esto nos ayuda a identificar los objetos, con ello podemos marcarlos con una etiqueta y saber donde se encuentran en cada posición del fotograma de cara a una posterior identificación de los mismos, con ello se pueden hacer cosas como la interpolación de fotogramas. Es decir, una vez sabemos donde están en cada fotograma podemos saber cual el vector de movimiento de cada elemento en escena y podemos generar un fotograma entre A y B adicional pero para poder hacerlo necesitamos de antemano a que corresponde cada pixel de la imagen.
Esto de cara al cine donde los codificadores son extremadamente rápidos y generan la imagen en menos tiempo que el tiempo de fotograma necesario es algo que se aplica al 100% sin problemas. Pero en juegos donde tenemos pocos milisegundos entre fotograma y fotograma esto no parece tener mucha aplicación. ¿Cierto? El problema es que lo enfocamos mal y pese a que una de las utilidades es esta hay otra que se basa en el uso no de fotogramas renderizados artificialmente sino de imágenes capturadas por una cámara+IR o una cámara+tiempo de vuelo , por ese motivo he subrayado el párrafo final y ahí viene lo de la aplicación de cara al pensamiento lateral. ¿Que ocurre si tenemos una imagen con profundidad pero en vez de obtener la imagen de la GPU lo que obtenemos es una imagen con búfer de color y profundidad de una cámara.
Es decir, utilizamos la información de entrada junto a una red neural para identificar objetos en la misma imagen, lo cual es ideal por ejemplo de cara a entrenar inteligencias artificiales para la conducción.
La idea es inicialmente entrenar con un simulador a la IA, dicho simulador esta renderizado completamente en 3D a tiempo real. La información de profundidad y color en cada fotograma nos permite generar el llamado ID Buffer de cada fotograma, en el ID Buffer lo que se hace es asignarle a cada objeto en la escena un ID (Identificador) y en cada fotograma durante la fase de rasterizado se utiliza como información el Z-Buffer para actualizar el ID Buffer correspondiente a cada fotograma. La combinación de ambos búfers de imagen la permiten a la GPU identificar y separar los objetos para aprender cuales son e identificarlos, pero esto solo es una aplicación.
¿Pero tiene alguna relación con las consolas de siguiente generación? Supongamos que tienes un sistema donde quieres realizar tracking de una habitación en un experiencia de realidad virtual totalmente inalámbrica donde nos queremos mover en cada momento con un tracking basado en cámaras, es igual si el tracking es Inside-Out o Outside-In, lo que queremos es acelerar el reconocimiento de los movimientos del jugador en el espacio… ¿Cual es la mejor manera? Entrenamos la IA para que pueda reconocer los objetos de una habitación y aplicamos el algoritmo en los motores de inferencia que tiene el Codec de Video, inmediatamente este descarta todos los objetos de la imagen obtenida excepto los que son esenciales para el tracking, pero esto solo es una aplicación de este tipo de unidades y no es la única.
El hecho de que no sea como los Tensor Cores le permite a AMD licenciarla como uno de sus bloques o venderla a un tercero. Pero la otra aplicación es el uso de los motores de inferencia para implementar la codificación y descodificación de nuevos codecs de video, en vez de tener una unidad de función fija codificando y descodificando video podemos entrenar a la IA para que esta aprenda a codificar nuevos formatos de video o incluso formas más eficientes en los ya existentes que permitan codificar en menos tiempos, ayudando a cosas dependientes de la latencia del streaming como es el Cloud Gaming o la Realidad Virtual.
¡Uy creo que me he pasado para explicar que esto no para algo como el DLSS 2.0 sino para otras cosas!
Pero de cara al reconocimiento de objetos para el tracking en una estancia con una cámara, Sony tiene alguna que otra patente en ese sentido. No las voy a explicar porque son recursivas con las de AMD en su explicación general y por tanto repetitivas.
¿Y para que AMD haría esto si no esta metida en el mundo de los coches inteligentes? A veces se os olvida cierto pacto entre AMD y Samsung para la creación de una GPU (lo que incluye los codecs de video) para un smartphone.
Gracias x la detallada explicación Urian! Entonces veo q en renderizado utilizando la asistencia x IA Nvidia tiene la ventaja, espero q AMD y su gama alta tenga mucha fuerza bruta para quedar a la par de su rival
O simplemente es para hacer DLSS al vídeo recibido por streaming… Le das demasiadas vueltas.
Lo ideal es recibir video a la mitad o un cuarto de resolución y multiplicar el bitrate por píxel. Para eso es esa unidad en el códec de video.

References: resolución 
 Resolución 
 Resolución 
 resolución 
 resolución 
 resolución 
 resolución 
 resolución