Hace unas horas aparecio la siguiente noticia:

En una entrevista reciente con 4Gamers (Fuente en Japanés), Adam Kozak de AMD confirmó que su próxima tarjeta gráfica Radeon VII será compatible con DirectML, una extensión de Aprendizaje de Máquina (ML) a DirectX.

Pensad en DirectML como el equivalente en el Machine Learning al DXR (DirectX Raytracing), permitiendo que DirectX 12 admita funciones avanzadas y utilice Ia para mejorar futuros juegos.

Un ejemplo de cómo es se puede ver la IA en la tecnología DLSS (Deep Learning Super Sampling) de Nvidia, que utiliza un algoritmo de Deep Learning para mejorar el rendimiento del juego al tiempo que ofrece una imagen final que puede proporcionar una calidad de imagen superior a TAA (Temporal Anti Aliasing). En el pasado, Microsoft ha presentado DirectML logrando logros similares, lo que significa que pronto habrá una alternativa de múltiples proveedores a la tecnología DLSS de Nvidia.

DirectML es compatible con todo el hardware compatible con DirectX 12, al igual que DXR, y como DXR, también puede explotar las capacidades de aceleración de hardware de las arquitecturas gráficas modernas. En efecto, esto permitirá a los desarrolladores acceder a funciones de hardware como los núcleos Tensor de Nvidia, al igual que la forma en que DXR les permite a los desarrolladores utilizar los núcleos RT de Turing. En el caso de DirectML, el rendimiento de Radeon VII de AMD se podría utilizar para ofrecer un efecto «similar al DLSS», pero utilizando un enfoque que funcionará en el hardware de Radeon.

Adam Kozak de AMD declaró «Radeon VII muestra excelentes resultados» cuando la compañía experimentó con DirectML.

La cual se que a muchos si llegais a leerla o más bien los pocos que leeis el blog al lerla os habréis quedado…

Y con una pregunta en vuestras cabezas… ¿No son necesarios los Tensor Cores para esto? No, en realidad no son necesarios pero si que son mucho más eficientes. En realidad los Tensor Cores lo unico que hacen es hacer operar dos matrices…

El caso es que es posible desglosar estas operaciones matriciales en varias vectoriales más sencillas, las cuales pueden ser ejecutadas por la unidades SIMD que son tan comunes en una GPU convencional. Pero a cambio de ser mucho más ineficiente al necesitar mucho más ciclos para resolver la misma instrucción, es por ello que en la famosa diapositiva de Microsoft sobre Project Brainwave estaba por detrás de los ASIC y las unidades FPGA que son mucho más eficientes en esta tarea.

Arquitecturalmente, no en potencia ya que es superior, Radeon VII esta al nivel de la Big Pascal o GP100 al carecer de Tensor Cores que pese a formar parte de una GPU se consideran ASICs y el motivo por el cual los FPGA y los ASIC dedicados a este tipo son más eficiente es por el hecho que son unidades MIMD.

En computaciónMIMD (del inglésMultiple Instruction, Multiple Data, en español «múltiples instrucciones, múltiples datos») es una técnica empleada para lograr paralelismo. Las máquinas que usan MIMD tienen un número de procesadores que funcionan de manera asíncrona e independiente. En cualquier momento, cualquier procesador puede ejecutar diferentes instrucciones sobre distintos datos. La arquitectura MIMD pueden utilizarse en una amplia gama de aplicaciones como el diseño asistidosimulaciónmodelado y en interruptores. Las computadoras MIMD pueden categorizarse por tener memoria compartida o distribuida, clasificación que se basa en cómo el procesador MIMD accede a la memoria. La memoria compartida de las máquinas puede estar basada en buses, extensiones, o de tipo jerárquico. Las máquinas con memoria distribuida pueden tener esquemas de interconexión en hipercubo o malla.

Ahora bien, las actuales Compute Units/SM (según la marca) en el fondo son unidades MIMD, por ejemplo la Compute Unit de AMD esta compuesta por 4 SIMD funcionando cada una con su instrucción correspondiente pero en realidad no la podemos considerar MIMD pese a ello. Por el hecho que para ser MIMD cada una de las unidades SIMD deberían ser capaces de trabajar con multiples instrucciones al mismo tiempo. Pero para que los lectores podáis entender porque los FPGA son más eficientes que las GPUs en ciertas tareas.

En las unidades FPGA lo que tenemos son varias puertas logicas programables conectadas en matriz y cada una a una memoria, podemos configurar cada una como queramos para que funcionan como cualquier tipo de chip lógico. Pero su gran ventaja es que podemos utilizar las puertas lógicas que nos sobren para crear otro mecanismo que funcionaría en paralelo.

Supongamos que queremos construir un teclado musical…

Tenemos una unidad SIMD, pero necesitamos definir cada nota con una serie de parametros, debido a que hay varios operandos que definen un sonido nos encontramos que cada sonido ocupa varias ALUs de nuestra unidad SIMD y para colmo solo podemos enviar una instrucción (pulsación de tecla) a nuestro piano. Se nos queda cara de tonto al comprobar como nuestro teclado es monofonico y no podemos tocar con doble clave y olvidemos los acordes…

Por lo que necesitamos poder pulsar varias teclas distintas y que se procesen al mismo tiempo, para crear nuestro chip de sonido lo que haremos es tomar un FPGA que soporta multiples entradas simultaneas de datos al mismo tiempo y podemos diseñar un chip con él que sean varias piezas funcionando en paralelo cogiendo varias teclas al mismo tiempo. Ahora podemos operar con varias notas al mismo tiempo y podemos crear acordes ya que cada nota es operada en paralelo y poder tocar con doble clave.

Si aplicamos el caso a las operaciones por matrices, en realidad seguimos desglosando por vertices el calculo de una matriz pero dado que podemos hacer trabajar en paralelo las diferentes unidades reducimos por tanto la cantidad de ciclos en total. Luego si a esta configuración de puertas lógicas la convertimos en un ASIC tomando como configuración fija la configuración exacta para solventar ese problema pasamos a tener un ASIC y por tanto una versión más eficiente para solventar el mismo problema.

El caso más sonado va a ser el upscaling o mejor dicho, el hecho de generar una imagen a mayor resolución a partir de otra de menor resolución sin ser un vulgar escalado y completamente limpia a través del Machine/Deep Learning. Y es aquí donde me gustaria comentar el DirectML que no es otra cosa que una extension de DirectX 12 como lo es DXR, pero pensada para aprovechar las capacidades que están integrando las GPUs para soportar el
Machine/Deep Learning.

Hagamos memoria de lo que es una unidad de procesamiento tensorial.

Una unidad de procesamiento tensorial o TPU (del inglés tensor processing unit) es un circuito integrado desarrollado por Google específicamente para el aprendizaje automático.
En comparación con las unidades de procesamiento gráfico (que a partir de 2016 se usan con frecuencia para las mismas tareas), estas unidades están diseñadas implícitamente para un mayor volumen de cálculo de precisión reducida (por ejemplo, desde 8 bits de precisión) y carecen de hardware para la rasterización/cartografía de textura.1​ El término ha sido acuñado para un chip específico diseñado para el marco Tensor Flow de Google. Otros diseños de aceleradores de IA están apareciendo también en otros proveedores y están dirigidos a mercados de robótica e incrustados.

En el pipeline de computación las unidades fijas utilizada para diferentes partes del pipeline gráfico no se utilizan. Y la forma en la que varios diseñadores de GPU han incluido la capacidad de poder operar con varios operandos a menor precisión es uno de los cambios que por ejemplo AMD hizo a partir de Vega.

En las Compute Units previas a la NCU de Vega cada una de ellas podia hacer 64 operaciones en FP32, 64 operaciones en FP16 y 64 operaciones en FP8. Con la nueva configuración es posible desdoblar por completo las ALUs para ir consiguiendo ALUs en paralelo con la mitad de precisión pero pudiendo hacer el doble de operaciones por el desdoblamiento. Esta técnica la ha aplicado AMD en la Radeon VII reemplazando Las 4 SIMD16 en FP32 de cada Compute Unit por 4 SIMD8 en FP64 que se pueden desdoblar en 4 SIMD16 en FP32 y asi sucesivamente. De esta manera AMD se ha ahorrado el hecho de tener que colocar ALUs en FP64 y todo su mecanismo aparte de las de FP32 y le ha dado cierta capacidad para funcionar como una unidad de procesamiento tensorial para el Machine/Deep Learning a su sistema.

Pero seguimos sin tener una unidad MIMD realmente pero tenemos una unidad SIMD con varios operandos. Vamos a suponer que utilizamos DirectML para el reescalado de imagen…

¿Cual es el hardware que soporta nuestro sistema?

¿Radeon 7000 en adelante? Eso es GCN 1.1 en adelante, vamos a suponer que queremos que la GPU de Xbox One S se encargue de realizar el reescalado de resolución de un streaming desde la nube, cada ALU es FP32 pero no solo operamos con altura y anchura en los pixeles sino también con 3 componentes de color por pixel y cada componente lo tenemos que colocar en una ALU. Dado que a todos ellos les vamos a aplicar la misma serie de instrucciones podemos colocar varios componentes en una unidad SIMD.

12*64= 768 componentes R,G o B

768/3= 256 pixeles.

Ahora supongamos que utilizamos… Un Raven Ridge 2/Picasso a la misma velocidad con 11 CUs pero con soporte para trabajar en Int8, seguimos trabajando de la misma manera pero…

11*(64*4)= 2816 componentes R,G o B

2816/3= 938,6 pixeles.

Con un simple cambio el rendimiento se ha cuasi cuadriplicado. Ahora bien, supongamos ahora que vamo a utilizar una teórica GPU con una unidad del tipo Tensor Core como la de Nvidia, tenemos un ratio de 8 ALUs FP16 en el Tensor Core por cada ALU en FP32 en nuestra Compute Unit.

11*64*8= 5632 ALUs Tensor

Y no solo eso sino que nos encontramos que cada una de ellas se puede desglosar en dos operaciones Int8 con la misma instrucción.

5632*2= 11264 ALUs tensor

Como podéis ver el salto para este tipo de aplicaciones es espectacular. La contrapartida en las GPUs con unidades tensor es que los SM no se pueden utilizar para gráficos y esto al mismo tiempo por lo que realmente se acaba utilizando solo una porción de la potencia total al representar solo una porción pequeña del tiempo de renderizado, lo ideal sería tener una segunda GPU o un hardware en paralelo que realizará la operación de subida de resolución en paralelo a la GPU mientras esta va generando imagenes a una resolución más baja, ya sea una segunda GPU o una unidad especializada como un FPGA o mismamente un ASIC/NPU dentro del mismo SoC.

Pero hay una cosa que llama poderosamente la atención y es que DirectML es una API no pensada para FPGAs sino para GPUs, esto pone en un contexto completamente diferente la presentación del pasado CES donde vimos la siguiente diapositiva…

DirectML no esta pensado para utilizar los FPGAs, en realidad esta pensado para utilizar las GPUs e incluso las unidades especializadas dentro de las mismas GPUs como son los Tensor Cores, hay que tener en cuenta que una GPU lo que hace es ejecutar una lista de comandos generada por la CPU y estos comandos pueden ir tanto para la GPU como para los aceleradores en la misma. Por ejemplo la parte encargada de renderizar los gráficos en 3D no decodifica peliculas pero ambas están gobernadas por el mismo procesador de comandos, lo mismo ocurre con las unidades tipo Tensor o incluso los RT Cores, no hacen más que ejecutar sumisamente la lista de instrucciones que el procesador de comandos les va enviando y que ha sido previamente generada por la CPU de manera dinámica.

En la GDC del año pasado cuando todo el mundo miraba de cara al Raytracing, Microsoft con la colaboración de Nvidia hizo una demostración de la aplicación del DirectML utilizando la versión de PC del Forza Horizon 3 y una Nvidia Volta (lo cual es hacer bastante trampa, pero bueno) para demostrar una tecnología de re-escalado de los 1080P a los 4K a tiempo real.

Y los resultados realmente son impresionantes:

No podríamos escribir un blog de gráficos sin explicar cómo los DNN pueden ayudar a mejorar la calidad visual y el rendimiento de los juegos. Observe de cerca lo que sucede cuando NVIDIA usa ML para muestrear esta foto de un automóvil 4 veces. Al principio, las imágenes se verán bastante similares, pero cuando acercas el zoom, notarás que el auto a la derecha tiene algunos bordes irregulares o alias, y el que usa ML a la izquierda es más nítido. Los modelos pueden aprender a determinar el mejor color para cada píxel para beneficiar a las imágenes pequeñas que se amplían o a las imágenes que se amplían. Es posible que hayas tenido la experiencia de jugar un juego en el que los objetos se vean geniales desde lejos, pero cuando te acercas a una pared o te escondes detrás de una caja, las cosas comienzan a verse un poco bloqueadas o borrosas. Con ML podemos ver el final de esas Tipos de experiencias.

La trampa esta en que una Nvidia Volta es cuanto a potencia con los Tensor Cores la GPU más potente en el mercado incluida la TU102, no solo eso sino que no tendría problemas para renderizar a 4K nativo el juego. En el SIGGRAPH del año pasado hicieron una demostración y hablaron de los resultados comparativos, lo que no sabemos es si es utilizando los Tensor Cores para ello o no.

Es a esto a lo que se refiere AMD que puede realizar la Radeon VII… ¿Entonces como es que no se puede con Vega 64? Pues porque AMD pese a prometerlo en su día con Vega al final le quito esa capacidad y hemos tenido que esperar a la Vega de 7nm para tenerla.

Ahora bien… ¿tiene sentido enviar el proceso de re-escalado y de limpieza de la imagen directamente a la GPU en vez de renderizar de manera nativa? Tiene sentido si el coste de re-escalado+limpieza de imagen cuesta menos tiempo que ejecutando el renderizado convencional en el mismo hardware. En todo caso se ha de tener en cuenta que el camino que Microsoft quiere tomar con el Machine Learning es que cualquier tipo de hardware lo pueda utilizar y esta muy claro para que soluciones se van a utilizar cuando este sea trasladado a la siguiente Xbox.

Para una Nvidia Volta que es mucho más potente que una RTX 2080 Ti en renderizado convecional (no-raytracing) el hecho de renderizar la imagen a 1080p es una porción infima del tiempo y le da un tiempo increible para el reescalado a tiempo real. Un salto 4X en resolución es una cifra muy impresionante y más si tenemos en cuenta que con el DLSS y juego mucho más complejos el salto de resolución es de 2X. El hecho de colocar Forzar Horizon 3 como ejemplo funcionando en una Volta que encima tiene los Tensor Cores es sinceramente hacer trampas.

No sabemos si la aplicación con el TensorFlow via CuDNN utiliza los Tensor Cores o no, pero el salto a al funcionalidad total del DirectML coincide con el salto de potencia al utilizar los Tensor Cores, en todo caso repito que es bastante trampa el ejemplo si tenemos en cuenta el juego y el hardware en el que se ejecuta.

Pero claro, no hemos visto ese ejemplo siendo ejecutado en una Radeon VII y Microsoft tampoco lo ha mostrado funcionando en una Nvidia Pascal que es lo más parecido arquitecturalmente al carecer de los dichosos Tensor Cores, pero es que aquí tenemos que entrar al igual que con el Raytracing en el pragmatismo de AMD y es que el DirectML no se encuentra disponible de manera pública para el desarrollo todavía… ¿Que sentido tiene la inclusión de la función en el hardware cuando ningún juego la utilizará? Lo mismo ocurre con el Raytracing ya que actualmente hay un solo juego que lo soporta en el mercado que es el Battlefield V.

En cambio el upscaling via Deep/Machine Learning como es el DLSS se esta estandarizando en una mayor cantidad de juegos por el hecho que por ahora tiene un grado de utilidad mayor en los juegos a corto plazo.

Esto en principio puede parecer un sintoma de miopia por parte de AMD al mirar a corto plazo en PC en vez de mirar a largo plazo. En una era donde la vida útil de las GPUs aumenta cada vez más por la desaceleración de la Ley de Moore el hecho que tu tarjeta gráfica vaya excelente en lo juegos actuales pero no sea Future Proof es algo que cuanto menos asusta y bastante, pero es que AMD tiene otro problemas que solventar desde hace ya casi dos años en areas mucho más básicas.

El primero de estos problemas es la eficiencia de sus Compute Units, la gente no tiene en cuenta que una GeForce 1080 con un equivalente a 40 Compute Units de AMD le pasa la mano por la cara a una Vega64 con unas 64 Compute Units. Una GPU con un area de 314mm^2 bajo el mismo nodo casi es muy superior a otra con un tamaño de 486mm^2. El otro factor importante es la velocidad de reloj, AMD tiene su GPU funcionando a 1247 Mhz a velocidad normal mientras que la 1080 de Nvidia alcanza los 1557 Mhz de media sin problemas.

El paso a los 7nm no ha sido tan satisfactorio y aunque parezca que nos estamos saliendo de tema realmente no es así. Vega 7nm mide unos 331mm^2 y vale que supera en rendimiento con el overclock a la GeForce 1080 pero la ineficiencia de la arquitectura Vega es clara. El tema es que no paro de leer gente que dice que en AMD faltan Compute Units y blablabla… Al contrario, lo que hace falta son Compute Units más eficientes que haga que no sean necesarios chips tan caros y energeticamente ineficientes que acaban requiriendo la cara HBM2, eso es lo que AMD tiene que solventar antes de nada y esta muy bien que la Radeon VII soporte Machine Learning de boquilla pero dudo que su rendimiento sea comparable a una Turing en ese aspecto.

¿Como es que AMD no muestra nada en ese aspecto con la Radeon VII y hablande e ello? Pues porque tienen Navi a la vuelta de la esquina que será la que comparen con Turing en lo que es el escalado de resolución via Machine/Deep Learning utilizando su solución. Y para ello en teoría necesitan reducir la cantidad de Compute Units haciendo estas más eficientes con tal de que haya espacio para los núcleos del Tipo Tensor o cualquier otra solución que AMD quiera implementar para realizar dicha tarea en sus GPUs y colocarse así al nivel de Nvidia de una vez por todas. Por lo que la Radeon VII va a ser en potencia bruta la GPU más potente de AMD este año pero su ineficiencia y coste va a ser palpable y no va a ser la más popular.

Y es que el Diablo esta en los detalles, fijaos bien… Hace unos días ha aparecido el rumor de una GTX 1660 Ti… ¿Con un chip Pascal? Nooo… Por lo visto con un chip Turing pero sin el RT Core… ¿Por qué eso? Pues para competir de tu a tu con la AMD Navi Lite que vamos a ver en poco tiempo y que estoy seguro que va a implementar cambios importantes, de cara a la galería continuara siendo GCN pero creo y puede que me equivoque que veamos por primera vez CUs GCN con unidades Super-SIMD.

La forma en la que yo entiendo la patente es que convertimos una unidad SIMD16 en FP32 en dos unidades SIMD8 en FP32 compartiendo el mismo conjunto de registro y con una cache L0 asignada como punto en común entre ambas unidades SIMD. Las unidades SIMD8 en FP32 se pueden utilizar como unidades SIMD16 en FP16 y hacer operaciones con matrices de 4×4 entre ambas ALUs al compartir pozo de registro y una Cache L0.

Por lo que la Compute Unit podría funcionar como un «Tensor Core» sin tener que añadir hardware adicional aparte de la Compute Unit y alto que es muy posible que yo termine…

Por el simple hecho que es una teoría mia de lo que estoy hablando y es información no confirmada. En el abstracto de la misma patente de la Super-SIMD nos encontramos con algo que llama poderosamente la atención:

A super single instruction, multiple data (SIMD) computing structure and a method of executing instructions in the super-SIMD is disclosed. The super-SIMD structure is capable of executing more than one instruction from a single or multiple thread and includes a plurality of vector general purpose registers (VGPRs), a first arithmetic logic unit (ALU), the first ALU coupled to the plurality of VGPRs, a second ALU, the second ALU coupled to the plurality of VGPRs, and a destination cache (Do$) that is coupled via bypass and forwarding logic to the first ALU, the second ALU and receiving an output of the first ALU and the second ALU. The Do$ holds multiple instructions results to extend an operand by-pass network to save read and write transactions power. A compute unit (CU) and a small CU including a plurality of super-SIMDs are also disclosed.

La negrita es importante porque nos lleva a lo que os he comentado al principio de la entrada acerca a las unidades MIMD. Pensad que decir que una unidad SIMD soporta varias instrucciones va en contra de su propia definición (Single Instruction…) por lo que estamos ante la conversión de las unidades SIMD de las Compute Units en unidades MIMD lo que apoyaría un poco más mi teoria acerca de los posibles cambios en «Navi» y que veremos en las consolas de siguiente generación.

Y ya que hablamos de la unidad Super-SIMD, Ayer salio publica por fin la continuación de la patente de dicha unidad Super-SIMDí. La patente se ha hecho publica recientemente pero data de 2017, lo digo por los tontos que repiten que puede que esto puede que no veamos esto en Navi cuando es claramente una variación de la arquitectura GCN.

En la misma patente se puede ver un diagrama…

… que vendría a ser una actualización del diagrama de la patente original (citada más arriba) que es este:

No voy a entrar en detalles porque incluso la propia patente esta escritá en un «Legalés» que no se entiende ni a si misma. Seguramente producto de una traducción de la patente original china que ha convertido a la patente en un galimatias gramático ininteligible y que algunos lumbreras están intepretando en los medios llenos de una enorme pedanteria.

Lo que si que llama poderosamente la atención es la existencia como he dicho antes de la GeForce GTX 1660… ¿Que es lo que pretende Nvidia? Muy simple, si según los rumores la primera Navi va a reemplazar del mercado a la actual Polaris es muy posible que su precio se situe en el espacio entre los $200 y los $300 y por tanto algo por debajo de la RTX 2060 e incluso podría haber una diferencia, aunque no os hagáis ilusiones, de unos $100 entre Navi Lite y la RTX 2060 a favor de Navi en el precio. El hecho de que Nvidia no vaya a sacar una Pascal para competir contra eso sino una Turing sin el RT Core y conservando los Tensor Cores es una clara pista de hacía donde puede tirar AMD con Navi Lite.

Y con esto termino… Se que es mucha información y me he ido un poco por las ramas pero eran cosas que tenía acumuladas en varios borradores y quería comentar. Ah, cualquier duda a los comentarios o el Discord.