Por fin Nvidia, en el pasado Hot Chips de hace unas semanas ha aclarado las cifras del Tegra Xavier y de su GPU acompañante en el Drive PX Pegasus.

XavierTeraOPS

El problema eran los TOPS que marcaban en teoría que la cantidad de Tensor Cores en cada SM eran el doble que en Volta, pues bien, Nvidia ha aclarado por completo las cifras.

1534809840582726692661_575px.jpg

Los Tensor Cores en Volta de escritorio calculan con precisión en FP16, lo que ha hecho Nvidia es el clásico truco de sub-dividir una ALU de 2n bits y sus registros para poder realizar dos operaciones de una instrucción con precisión de n bits. Esto significa que en este caso los Tensor Cores realmente no están duplicados realmente y la unidad SM es la estándar de los Volta pero con los Tensor Core modificados para darles la capacidad de hacer 2 Int8 donde puede hacer 1 FP16, por lo que si transformamos los 22.6 DL-TOPS en TFLOPS en FP16 la cidra sería realmente de 11.3 TFLOPS en FP16 y a través de los Tensor Cores que funcionan de manera conmutada con los CUDA Cores por lo que la cifra en FP16 de los nucleos CUDA en la GPU del Tegra Xavier no se puede sumar a los del Tensor Core. El hecho de operar en Int8 no le da mayor potencia, al contrario, puede trabajar con menor precisión en ese modo y ciertas tareas pueden ser nada recomendables hacerlas en dicha precisión.

Obviamente la versión final de Xavier va un poco más rápida al poder alcanzar los 22.6 DL-TOPS en vez de los 20 DL-TOPS prometidos el año pasado, pero esto nos permite evaluar un poco cierta GPU misteriosa que se dice qu funciona en conjunto al Tegra Xavier aunque en chips separados dentro del Drive PX Pegasus.

NvidiaPegasus

Dado que los «TOPS» están relacionados con los Tensor Cores modificados tal y como hemos visto y al mismo tiempo estos están relacionados con el número de SM en placa… ¿Podemos saber cual es esa GPU misteriosa de la que hablaba Nvidia de una vez por todas?

Pe… pero Urian… ¿No lo ves? Es una GV100, si se ve de lejos.

n45l1p93oba01.png

Exacto, es una GV100 pero este producto no es más que vaporware porque no se puede pedir y las cifras no concuerdad. Pensad que la cantiadad de TOPS es 2X la cantidad de TFLOPS en los Tensor Cores, si quitamos los dos Tegra Xavier entonces entonces tenemos unos 280 TOPS, como ambas GPUs son simétricas la cosa se convierte en 140 TOPS que a su vez son 70 TFLOPS via Tensor Cores… ¿Cual es el rendimiento de la GV100? ¡Unos 120 TFLOPS via Tensor Cores!

Quadro-GV100.jpg

Pe… pero Urian… ¿Seguro que le han bajado la velocidad de reloj?

Es absurdo… ¿Para que te pones a fabricar un chip de 815mm^2 para sacarle solo una porción de su rendimiento cuando el rendimiento de las obleas es tan bajo que puedes incluso perder dinero? Lo mejor es un chip mucho más ligero. En el mundo de la automoción para empezar no hace falta la precisión en FP64 por lo que estos pueden ser recortados, en realidad lo que acabaríamos teniendo son núcleos Turing sin el RT Core en el fondo, pero imaginaos que tenéis Turing muy desarrollado y decidís descartar esta GPU. ¿Y cual era el rendimiento de esta GPU? Pues por una simple norma matemática deberia tener unos 3584 núcleos CUDA y ser por tanto una versión recortada de la GV100, es decir, con menos GPC.

NVIDIA-Volta-GV100-GPU-Block-Diagram

Tenemos unos 14 SM por GPC y unos 6 GPC en total, haciendo unos 5376 nucleos CUDA en total, unos 896 núcleos CUDA por GPC.. ¿Que ocurre si reducimos la cantidad de GPCs de manera progresiva?

GPCs CUDA Cores
1 896
2 1792
3 2688
4 3584
5 4480
6 5376

Es decir, una versión de Volta con 4 GPC (La habitual en los chips n104 y por tanto en lo que sería una seria x80 de Nvidia) concuerda con nuestra GPU misteriosa… ¿Pero donde esta dicha GPU? Pues completamente descartada y reemplazada por la GeForce 2080 que tiene «solo» unos 3072 núcleos, de los cuales activos hay unos 2944. ¿Como es que Nvidia ha descatartado lo que vendría a ser el GV104? Pues por el hecho que su rendimiento en juegos que no utilizarán el Raytracing seria muy superior a lo que es la 2080 por motivos obvios…

moar-cores-all-the-cores.jpg

Los RT Cores no tienen utilidad alguna a no ser que sean utilizados y Nvidia a ultima hora ha decidido integrar los RT Cores en su gama «doméstica» de manera directa, aunque sinceramente su rendimiento en la gama doméstica es cuanto menos… Es muy decepcionante por el momento y digo por el momento porque el ver el Shadow of the Tomb Raider corriendo en una RTX 2080 Ti… Sinceramente…

thumbs-downnotvjimmy-fallon

Pero lo mejor es que lo veáis vosotros mismos por favor… Y si, el video no es mio pero lo copie en mi canal por si el original era borrado, atencion al minuto 1:52 como bien dice Nolgan.

¿A que se deben esos malos gráficos? Pues al hecho que aunque hagas la iluminación indirecta dinámica por Raytracing esta depende de base de la información conseguida por la iluminación directa dinámica que viene previamente y si esta no es lo suficientemente precisa entonces el resultado no es el esperado. Y si, se que el ejemplo no es bueno porque es un juego no-lanzado todavía que puede ser pulido pero como ya comente el Raytracing que estamos viendo es de juguete.

En una entrada de hace un par de meses os comente el tema del transporte de la luz por el escenario y como el Raytracing tenía diversas versiones del algoritmo con mayor o menor precisión y con mayor o menor velocidad. En los juegos actuales por rasterización se simula aunque no con precisión matemática y por tanto con comportamiento erroneo respecto a la realidad, los tres tipos de luces indirectas. Es decir, se hace de manera pre-computerizada.

iluminación2

Lo que hace el Raytracing es calcular dicha iluminación de manera dinámica, es decir, no hay nada pre-computerizado realmente pero los recursos son finitos. Si me permitís voy a citar mi propia entrada para re-explicarlo de nuevo.

Voy a ignorar la la luz ambiente porque es la menos compleja y se basa en la simple combinación de un color con el color final de la textura sin tener en cuenta cual es la posición, ni la trayectoria de la luz. La luz ambiente suelen ser los puntos de partida de las fuentes de luz.

Sin entrar en consideraciones del algoritmo de renderizado, en una escena en 3D sumamente simple tenemos:

492002-doom-playstation-screenshot-the-psx-release-adds-colored-lights

  • Fuente de Luz → Cámara (Ojo)

Este era el tipo de iluminación más simple y es el que se utilizo en los primeros juegos en 3D.  La cosa evoluciono con el tiempo a un modelo de iluminación más compleja que es lo que hoy llamamos iluminación directa.

unreal

  • Fuente de Luz → Superficie Difusa → Cámara (Ojo)
  • Fuente de Luz → Superficie Especular (mapa de entorno) → Cámara (Ojo)

Pero si queremos ir más allá necesitamos calcular la iluminación que es generada indirectamente por una superficie al impactar una fuente de luz sobre ella. A la hora de transmitir la luz de una superficie a otra tenemos cuatro escenarios distintos posibles:

LightTransport.PNG

Por lo que añadiendo un solo nivel adicional de indireccion tenemos.

  • Fuente de Luz → Superficie Difusa → Superficie Difusa → Cámara (Ojo)
  • Fuente de Luz → Superficie Especular → Superficie Difusa → Cámara (Ojo)
  • Fuente de Luz → Superficie Difusa → Superficie Especular → Cámara (Ojo)
  • Fuente de Luz → Superficie Especular → Superficie Especular → Cámara (Ojo)

Tenemos 4 metodos de transporte de la luz diferenciados entre superficies que son:

  • (a) Difusa a Difusa: Es posible calcularla utilizando Radiosidad.
  • (b) Especular a Difusa: Se necesita una combinación entre el Raytracing y la Radiosidad.
  • (c) Difusa a Especular: Mismo caso que (b)
  • (d) Especular a Especular: Es posible calcularla con Raytracing.

¿A que viene la cita? Bien, pues por el hecho que la iluminación indirecta difusa en los juegos que se están mostrando no se esta calculando via Raytracing, solo la especular y en algunos casos como el Shadow of the Tomb Raider hay una falta de potencia aparente incluso en la 2080 Ti por el hecho que la mala calidad de imagen es porque la iluminación es pobre. El Raytracing tiene la ventaja de ser muy matemáticamente preciso pero lo es tanto que necesita potencia y si esa potencia no esta entonces no existe dicha precisión y la calidad de imagen queda deteriorada. ¿La mejor solución? Pues… Han decidido tirar de lo más simple, iluminación especular para representar mejor el comportamiento de superficies altamente reflectantes dejando al resto tal y como estaba antes, lo que no resulta en un salto muy espectacular pero si el el comienzo de un salto progresivo que va a durar varios años de manera progresiva y varias generaciones de GPUs, de la misma manera que ha ocurrido antes.

Uno podria pensar de entrada que la evolución de la iluminación indirecta pre-computerizada a la dinámica es el siguiente paso a nivel visual y así és por el hecho que hay problemas visuales no resueltos pero existe una extraña correlación en nuestras mentes entre el advenimiento del DXR como API y la aparición de las GeForce RTX que como ya comente en la entrada de ayer. En la visión de Microsoft sobre el Raytracing la capacidad de hacerlo viene por la versatilidad del pipeline de computación y por el hecho que este no sigue un orden concreto. Si me permitís me voy a autocitar o más bien, voy a volver a citar las palabras de Microsoft acerca del DXR.

“Os habréis dado cuenta que DXR no introduce ningún tipo de motor GPU que vaya junto a los motores de gráficos y computación ya existentes en DX12. Esto es intencional, las cargas de trabajo DXR pueden ser ejecutados en los ambos tipos demotores existentes. El motivo primario de de esto, fundamentalmenteque DXR es una carga de trabajo del tipo computación. Nonecesita estados complejos como output merger blend modes o input assembler vertex layouts. La razón secundaria, es sin embargo, que representando el DXR como una carga de trabajo tipo computación es como vemos el futuro de los gráficos, digamos que el hardware se irá volviendo más de proposito general y eventualmente muchas unidades de función fija serán reemplazadas por código HLSL.

En realidad podemos emular cuaquier elemento de función fija, es decir, cualquier máquina de estado que siempre aplica una serie de instrucciones a unos datos de manera consecutiva desde los Compute Shaders, pero esta funcionalidad es llevada a cabo de manera invisible por el controlador y el procesador de comandos, especialmente si hablamos en bajo nivel por este último. ¿Y en que consiste la trampa? En continuar utilizando máquinas de estado no-documentadas y fuera de la API para realizar operaciones comunes en los juegos. Los algoritmos más utilizados en los juegos son analizados por los fabricantes de GPUs e integrados como máquinas de función fija realizando esa misma operación. ¿Que son los RT Cores? Pues la implementación en función fija y por tanto en forma de sucesión de máquinas de estado del acceso a la cache de segundo nivel que es donde se almacena el BVH del Tile que tenemos que recorrer. ¿La comunicación entre Tensor Cores, RT Cores y CUDA Cores? Se realiza en la nueva cache de nivel 0.

Ahora bien, el siguiente paso para Nvidia en el mundo de la automoción es el Tegra Orin cuya potencia es la misma que un Tegra Xavier+su GPU correspondiente en el Drive PX Pegasus.

DrivePegasus

Orin_Roadmap_Car_678x452

Fijaos que Orin no tiene fecha de lanzamiento pero por motivos evolutivos si hemos visto Maxwell (X1), Pascal (X2) y Volta (Xavier), por lógica Orin tiene que ser un SoC conteniendo una GPU con arquitectura Nvidia Turing y con una configuración en teoría y repito, en teoría de 4096 núcleos CUDA, una configuración que personalmente no creo que veamos, sino más bien Nvidia integrara el TU104, es más, pienso que el TU104 va a ser el chip que reemplace al GV100 en la versión final de Pegasus que aparecerá el año que viene y que Orin es una fusión de ambos chips.

El TU104 mide unos 529mm^2 en una versión optimizada del 16FF de TSMC llamado falsamente 12FF, por lo que hablamos de 23x23mm solo para la GPU en dicho proceso, viendo como es la primera generación de productos a 7nm de diversas marcas de momento parece que van a optar por una densidad 2X. Esto nos da un tamaño de 16.1 x 16.1 solo para la GPU, unos 260mm^2 en total. La otra parte que sería la parte heredada del Tegra Xavier como mucho mediría unos 175mm^2 por lo que el chip resultante pequeño no sería, aunque se tiene que tener en cuenta que la union de los dos chips traeria consigo la eliminación de elementos en común y superfluos de dicha unión. Pero lo que nadie comenta es que la configuración de Orin es ideal para una potencial siguiente generación de consolas por su configuración. ¿Cual es el problema? De entrada que Orin va a heredar buena parte de las unidades del Tegra Xavier con utilidad dentro del mundo de la automoción inteligente que en una consola de siguiente generación tienen utilidad cero y es espacio utilizado inutilmente en el SoC de una consola.

1534809853692978377711_575px15348099356561901208208_575px

El problema es que Nvidia al contrario que AMD no utliza el modelo semi-custom que se basa en realizar variaciones a medida de sus chips para diferentes clientes cobrandoles una simple regalía por chip vendido y dandoles el control completo de la fabricación de dicha variación. Bueno, miento… Esto ha sido hasta hace recientemente donde el éxito de Nintendo Switch ha hecho que Nintendo re-negocie el trato con Nintendo y el T210 se ha convertido en su versión semi-custom T214, creada para luchar contra la piratería en los nuevos modelo de Switch que vayan apareciendo, pero los cambios son mínimos y son dados por una eventualidad doble, el alto precio del SoC para Nintendo y el problema de la piratería. Esto no significa que Nvidia vaya a seguir el mismo paso que AMD pero cualquier persona con dos dedos de frente verá al Tegra Orin como un perfecto candidato para el SoC de una consola de siguiente generación por el hecho de ir muy por encima de las capacidades de la Xbox One X que es la consola más potente de la actual generación.

¿Significa esto que Nvidia tenga algún contrato con algun fabricante de consolas para el uso del Tegra Orin como chip principal de la consola? No, pero se que la pregunta ha ido apareciendo en varios comentarios en este blog y me interesaba comentarla. Otra pregunta clave es… ¿Si el Raytracing esta tan verde merece la pena incluir los RT Cores? Y repito, los RT Cores no sirven para el procesamiento del Raytracing sino que están especializados en atravesar estructuras de datos del tipo BVH a gran velocidad. Esto como dije es sumamente útil para cosas como la detección de colisiones y para representar el traslado del sonido en un area tridimensional… Esos son los dos ejemplos que di, pero hay otro ejemplo del que he hablado continuamente en este blog y precisamente es algo con lo que se me ha encendido la bombilla. ¿Que tipo de estructura de datos del tipo BVH ha sido muy comentada en los últimos años? Pues los Octree que son altamente utilizados en otras técnicas de iluminación global.

Octree-subdivision

¿Cual era el problema que teníamos con algunas técnicas relacionas con el Cone Tracing hace unos años? Las GPUs por si mismas son altamente ineficientes recorriendo la estructura de datos del tipo BVH y de ahí a descartarlo pero… ¿Que ocurre con los RT Cores? Pues que son ideales para recorrer dichas estructuras de datos y van a permitir que los algoritmos gráficos pensados para la iluminacion global basados en el Sparse Voxel Octree puedan volver y esto nos responde la pregunta por la cual los RT Cores han sido creados y porque Microsoft no los ve indispensables, no se crearon para el Raytracing sino porque el próximo paso lógico en la rasterizacion era el llamado SVOGI o Sparse Voxel Octree Global Illumination, pero ese paso para ser viable requería el desarrollo de los RT Cores para integrarlos en las GPUs.

Si lo miramos desde cierto punto de vista las piezas cuadran, la GPU del Tegra Orin tiene que ser una 8 veces más potente que la de Xavier que tiene una potencia de 1.3 TFLOPS, esto darían unos 10.4 TFLOPS aproximadamente. ¿Poco? Tened en cuenta de la ventaja que supone tener los RT Cores y el aceleramiento que suponen. Si Orin sigue la tradicion de ir avanzando a una arquitectura más potente será un chip ideal para una consola de siguiente generación. ¿Cual?

tenor (18)

Pero lo que tengo muy claro es que Orin es un SoC Next Gen encubierto.

Esto es todo.