Este post es de especulación, son una serie de ideas ordenadas y si he ser sincero no se si las veremos también en Xbox Series X pero creo que las tenemos seguras en PlayStation 5 por una serie de pistas que veréis en la entrada.

Super-Resolución/DLSS y Tensor/Redes Neurales

En Beyond3D, precisamente en el hilo del DLSS he encontrado algo bastante interesante, un pantallazo del NSight de Nvidia que es una aplicación que marca el porcentaje de uso de la GPU con el tiempo y es ideal para ir optimizando los juegos.

El pantallazo es el siguiente:

Lo que llama poderosamente la atencion es el uso de los Tensor Cores, cuya linea esta subrayada en azul… Fijaos como los Tensor Cores no aparecen hasta la parte final del fotograma, esto es debido a que necesitan tener el fotograma base para poder trabajar, es decir, necesitan que el resto de la GPU pueda renderizar la escena… ¿Pero acaso no pueden trabajar en paralelo? En realidad si y no, es dificil de entender pero digamos de que los Tensor Cores comparten los registros y caches internas del SM.

El Warp Scheduler+Dispatch es la unidad de planificación y distribución de las olas, estas olas son siempre de 32 elementos, pero no son homogéneas en el sentido que no trabajan con un tipo de datos por ola. Esto significa que estos 32 elementos pueden utilizar cualquier cantidad de INT32+FP32+Tensor pero siempre ha de sumar 32 elemento por ola.

Debido a que durante el renderizado del fotograma las unidades INT32 y FP32 tienen preferencia, la unidad Tensor se queda esperando a su turno sin hacer nada, no recibe instrucciones ni datos porque el planificador y los registros se encuentran ocupados por las otras ALUs y por tanto como ya he dicho los Tensor…

Esto además significa que durante el tiempo en que los Tensor anden realizando el DLSS los núcleos CUDA bajan su nivel de utilización… ¿Pero cuando tiempo están? Obviamente dependen de la GPU pero este parece ser el timing con una RTX 2080.

Parece ser que el tiempo de procesamiento del DLSS 2.0 es completamente dependiente de la resolución. Los Tensor Cores estabán activos al menos durante 1.1 ms en los modos 720p a 1440p y 960p a 1440p. 0.7ms para 720p a 1080p.

El búfer de imagen no es procesado de golpe sino por bloques, el tiempo por bloque de pasar de una resolución más baja a una más alta debería ser más alto cuanto más alta sea la resolución de salida. En cuanto a tiempo total cuanto más alta sea la resolución de entrada y por tanto entren más bloques más tiempo necesitarán los Tensor y menos tiempo tendrá el resto del sistema en consecuencia para generar la imagen principal.

¿Como hacemos que el DLSS ejecutado en los Tensor no sea un problema? Pues le asignamos un tiempo fijo, el controlador sabe el tiempo requerido para pasar de A a B. Si el tiempo sobrante es suficiente para aplicar el DLSS entonces se aplica, si el tiempo sobrante no es suficiente entonces no se aplica por el hecho de no existir tiempo suficiente y cuando no es aplicado entonces los Tensor simplemente duermen sin hacer nada a no ser que se les invoque para otra cosa.

Ahora bien, la potencia de los Tensor en una RTX 2080 si lo miramos en TFLOPS (FP16) es una cifra que asusta, unos 81 TFLOPS… Pero esta potencia no es a de los núcleos CUDA y es sumamente alta por el hecho que la ventana de oportunidad en cada fotograma es realmente baja, pensad que el timing que tiene disponible es muy pero que muy bajo. No ocurre lo mismo cuando reescalamos una película, el tiempo de descodificación de una película con los codecs por hardware que hay ahora es de unos pocos milisegundos, esto da tiempo suficiente para hacer un escalado y no se necesita tanta potencia para ello. La ventana de tiempo que tiene la red neural encargada del escalado es mucho más alta en consecuencia.

De la misma manera si la resolución de entrada es más baja entonces el sistema tardará mucho menos en renderizar el fotograma base, si lo pensamos bien esto es ideal para el Cloud Gaming donde la latencia es importante y el tiempo de renderizado tiene que ser más bajo. Podemos renderizar una escena a 720P en menos tiempo y reescalarla a 1080P via DLSS y el tiempo sería mucho menor que renderizar a 1080P. Obviamente el codificador lo haria a 1080P y enviaría los paquetes de datos a dicha resolución para descomprimir. ¿La otra opción? Renderizar a 720P, enviar a 720P y hacer que el sistema del cliente sea el encargado de reescalar pero el problema de ello es que necesitamos que el sistema del cliente tenga una capacidad y configuración suficientes para el reescalado y la decodificación, lo cual no es el caso.

Las mismas reglas aplicadas para el Cloud Gaming se pueden aplicar a la Realidad Virtual, la idea en ambos es renderizar lo más rapidamente posible para paliar la latencia añadida y el poco tiempo que tenemos. Pero en la Realidad Virtual podemos colocar una red neural en el SoC del HMD y cumplir perfectamente con el segundo escenario sin problemas por el hecho que en el HMD tenemos el hardware necesario para ello.

Llevando esto a la siguiente generación.

Y aqui pues vamos a salir de lo que es Nvidia y centrarnos en unas declaraciones de Kazunori Yamauchi, el productor de los Gran Turismo donde hablo de 240 fotogramas por segundo.

En lugar de la resolución espacial, estoy más interesado en los avances que podemos hacer en términos de resolución temporal. Cuando hablamos de frames por segundo, en vez de quedarme en los 60fps, me interesa más subirlos a 120fps o incluso 240fps. Creo que eso es lo que va a cambiar la experiencia de ahora en adelante.

¿Como se explican los 240 fotogramas por segundo? Pues 120 fotogramas para el ojo izquierdo y 120 fotogramas para el ojo derecho cuando renderizamos en estéreo para una unidad HMD de unos 120hz de refresco y no creo que el PlayStation VR 2.0 tenga una tasa de refresco inferior a la del PS VR.

Claro esta que todos sabemos que PS5 va a llevar hardware de AMD y no de Nvidia, lo que sabemos del hardware de AMD es:

  • Las redes neurales no se encuentran dentro de cada Compute Unit sino que se encuentran fuera de estas, junto a los aceleradores.
  • AMD va a integrar la red neural junto al codec de video.

AMD tanto en sus GPUs como en sus SoC tiene el llamado Multimedia Engine, solo que en los SoC añade una serie de DSP de Audio de Tensilica que seguramente veremos en las consolas de siguiente generación, estos DSP AMD los saco de las GPUs dedicadas a partir de Polaris para apostar por el TrueAudio Next, pero en los SoC siguen estando.

El planteamiento de AMD es algo distinto al de Nvidia, su red neural no tiene que compartir recursos con el resto de elementos de la Compute Unit para hacer su trabajo. Pero no nos podemos olvidar que el problema de la ventaja de oportunidad sigue existiendo y para tener algo similar al DLSS ha de tener la suficiente velocidad para ello en dicha red neural. Si miramos la potencia bruta de las redes neurales en forma de NPUs es mucho más baja que la de Nvidia pero al contrario de la de Nvidia al trabajar en paralelo se pueden utilizar todo el rato y no solo en contadas ocasiones. Digamos que la solución de Nvidia esta más pensada para el escalado de videojuegos mientras que el resto de soluciones del mercado es mucho más genérica.

Sony Interactive tiene una patente titulada «Neural Network Powered Codec» que recuerda enormemente a una de AMD titulada «INTEGRATED VIDEO CODEC AND INFERENCE ENGINE«. En ambos casos se habla del uso de una red neural para la codificación/decodificación de video, lo cual también debería incluir la capacidad de aumentar la resolución e incluso si es necesario realizar la interpolación de fotogramas. ¿Y que hay de Microsoft? En las especificaciones no han hablado nada del uso de redes neurales, pero esperamos a que den la información de ello para saber si han optado por incluir este tipo de unidades en el SoC de Xbox Series X o por el contrario han visto preferible ocupar el espacio con una cantidad de WGP/CUs mayor.

Por otro lado la Red Neural puede ser utilizada de cara al tracking con la nueva cámara, para acelerar el tiempo de interpretación y procesamiento d imagenes de la cámara utilizada para el tracking. Sony tiene otra patente de 2017 y por tanto posterior a PS4 Pro y el PS VR donde hablan de utilizar una red neural para la interpretación de las imágenes capturadas desde una cámara del tipo Kinect. La patente se llama 3D Depth Map y su resumen inicial es suficientemente explicito.

El Machine Learning se aplica tanto a las imágenes 2D de un reflector láser de imágenes infrarrojas de un objeto como al mapa de profundidad 3D del objeto que se genera utilizando las imágenes 2D y la información de tiempo de vuelo (TOF). De esta manera, la precisión del mapa de profundidad 3D se puede mejorar sin aumentar la potencia del láser o sin utilizar imágenes de alta resolución.

Es decir, es la combinación de una cámara al estilo Kinect junto al Machine Learning. Tened en cuenta que la PlayStation Camera no es:

  • Una cámara que capte infrarrojos.
  • Una cámara que funcione por tiempo de vuelo.

Por lo cual tenemos otra cámara, la cual no solamente tiene su utilidad de cara a aumentar la resolución sino que puede utilizarse en la VR para acelerar el tiempo de procesamiento del tracking via cámara y también esta pensado de cara al streaming de los jugadores y es que… Es muy posible que me coma cuervo con esto y me tenga que comer lo que digo pero pienso que Sony podría estar creando una nueva red social al estilo Twitch o Youtube pero para plataformas PlayStation.

La cámara además funcionaría con un bus USB 3.1 que es como minimo unas 10 veces más rápida en ancho de banda que las cámaras USB 2.0 como las del Kinect por lo que permiten una tasa de fotogramas más amplia y a mayor resolución. Es decir, Sony en PS5 se va a cargar el puerto auxiliar de PS4 para la cámara y enviar al ostracismo la actual PS Camera.

Y si, se lo que muchos estaréis pensando ahora mismo..

La idea de integrar una pequeña cámara de serie no tiene sentido después de lo del Kinect, pero si que tiene sentido si le das las herramientas a la gente para hacer streaming y potenciar una red social basada en ello. De paso su vieja red social de los foros de PlayStation la van a cerrar para abrir lo que yo creo que va a ser su propia red social, como he dicho al estilo Twitch y la incorporación de la cámara es algo muy importante.

Y aunque os parezcan continuos los cambios de tema, la cámara esta relacionada con la Realidad Virtual y con la Red Neural, la cual al mismo tiempo esta relacionada con lo que es la super-resolución via IA que Nvidia llama comercialmente DLSS pero que cualquier hardware con una red neural puede realizar.

Ahora bien, los algoritmos de IA no solamente son posibles en una red neural, donde funcionan mejor y más rápido es en ellos pero nos hemos de asegurar que la red neural sea más rápida que el resto del sistema en operar con ciertos algoritmos, si no es así entonces mal vamos porque se vuelve inutil.

AMD que no utiliza las unidades Tensor tiene algunas GPUs donde utiliza los núcleos convencionales, no son tan efectivos y para hacerlo utiliza el SIMD sobre registro de tal manera que una ALU de n bits se convierte en 2 ALUs de n/2 bits, 4 ALUs de n/4 bits. Si la cantidad de ALUs disponibles para Int8 e Int4 es más baja en el acelerador de la red neural entonces…

Si miramos el whitepaper de AMD sobre RDNA nos encontramos lo siguiente:

Algunas variantes de la Dual Compute Unit (WGP) exponen modos adicionales de productos de punto de precisión mixta en las ALU, principalmente para acelerar la inferencia de aprendizaje automático. Un Dot2 FMA de precisión mixta calculará dos multiplicaciones de media precisión y luego agregará los resultados a una precisión única acumulador. Para un rendimiento aún mayor, algunas ALU admitirán puntos enteros de 8 bits dot4 operaciones y operaciones dot8 de 4 bits, todas las cuales utilizan acumuladores de 32 bits para evitar desbordamientos

Nvidia utiliza ALUs de 16 bits para sus Tensor Cores/Red Neural/Arrays Sistolicos, la cantidad de ALUs en FP16 via Tensor es más alta que la que tendríamos de aplicar el SIMD sobre registro en las ALUs FP32 que son los núcleos CUDA. Debido a que los Tensor ya pueden hacer FP16 NVidia lo que ha hecho es traspasar el calculo en FP16 hacía los Tensor en Turing y aplicar en estos el SIMD sobre registro para el Int8 y el Int4.

Por lo que vamos a necesitar que la red neural al menos en Int8 e Int4 tenga un rendimiento superior a los Stream Processors en el caso de AMD. Imaginemos ahora que tenemos una GPU con 36 CUs/SM, de 64 ALUS en FP32 con SIMD sobre registro, esto son unas 128 ALUs en FP16, unas 256 en Int8.

Nvidia utiliza ALUs en FP16 para cada Tensor, siendo cada Tensor un array sistólico de 64 ALUs en una configuración de 4x4x4.

Esto es ideal para las olas de 32 componentes, en realidad tenemos dos unidades Tensor por Sub-Core de 4x4x4 y recordad que tenemos unos 4 Subcores por SM.

Por lo que tenemos en total unas 512 ALUs por SM en FP16 en los tensor, una cifra mucho más alta que los 128 que obtendríamos por el SIMD sobre registro en los núcleos CUDA.

¿Y que hay de la solución de AMD? Ya hemos visto que la red neural sería completamente externa aunque dentro de la propia GPU. En AMD tenemos unas 64 ALUs por Compute Unit, no sabemos si van a utilizar ALUs en FP16 o en Int8 para la red neural, pero creo más bien que vamos a ver la red neural de AMD funcionando en Int8. El caso es que si una CU en SIMD sobr registro puede convertirse en unas 256 ALUs en Int8 entonces vamos a necesitar unas 512 ALUs en Int8 en la red neural para justificar la red neural, unas 1024 por WGP en total.

¿Y de donde va a sacar AMD dicha red neural? Pues os vais a reir, pero creo que…

AMD ya utiliza los DSP de Tensilica para el Audio en sus SoC, no me extrañaría que AMD haya licenciado también el procesador de IA escalable de Cadence/Tensilica, que es el DNA 100 para integrarlo en las consolas de siguiente generacion y/o en la segunda generación de RDNA para paliar la falta de núcleos Tensor. La utilidad es la misma y también nos encontramos con arrays sistolicos.

Cadence además tiene una seria de DSPs/Aceleradores que tienen mucho sentido en el caso de la cámara. AMD se ahorra de tener que desarrollarlos para Sony (¿y Microsoft?) con ello.

Cada DNA100 tiene un Sparse Compute Engine (otro nombre para los arrays sistolicos), el cual puede ser de 256, 512 o 1024 ALUs y podemos tener un total de hasta 4 Sparse Compute Engine por DNA100 para un total de 4096 ALUs.

Aparte de que podemos tener un array de DNA100 conectados al uncore del sistema…

Para unas 36 Compute Units necesitariamos un total de 9 DNA 100 con la configuración máxima, los cuales irían conectados al Data Fabric/Uncore del sistema como el resto de aceleradores en el SoC. El DNA100 no puede operar en FP16 por lo que ese tipo de cálculos seguiría dependiendo de las Compute Units todavía en el caso que nos ocupa.

La idea no es otra que el array de DNA 100 (o la red neural que utilicen) haga el trabajo de los Tensor Cores de cara a la super-resolución. Esto significa que tomen lo que es el fotograma renderizado por la GPU y se encarguen de aumentar la resolución de salida. Esto lo tienen que hacer durante la ventana de oportunidad y hacerlo lo suficientemente rápido, es por ello que necesitamos una enorme cantidad de ALUs para ello y con ello volvemos al principio de la explicación.

En lo que es el uso convencional no vamos a necesitar dichas unidades y van a estar paradas la mayor parte del tiempo, pero en la Realidad Virtual las vamos a utilizar para:

  1. Intepretar la imagen capturada por la cámara.
  2. Aumentar la resolución de salida (renderizamos a menos resolución para ganar ms)
  3. Para codificar la imagen para vídeo lo más rapidamente posible.

En el caso de que estemos jugando y haciendo streaming esto ayudara al tiempo de codificación y captura enormemente. Su utilidad no sería solo para los usuarios de la Realidad Virtual sino también de cara a hacer streaming en la nueva red social que Sony tendría preparada basada en ello lo que le daría todo el sentido a la incorporación de la cámara y no sería para algo al estilo Kinect como muchos afirman.

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