Por lo visto lo medios están hablando de una supuesta demo de Gran Turismo a 8K y 120fps. La demo sabemos que existe pero es una enorme mentira decir que va a 8K y 120fps.

La realidad es que los 8K son las especificaciones de la pantalla gigante, hemos de tener en cuenta además que los 120hz son también especificaciones de esa pantalla y Sony no va a mostrar imagenes de un juego corriendo en un supuesto hardware superior para ocultar dicho hardware de cara al público. ¿Que es lo que pienso? Que esto no es más que un vulgar video renderizado originalmente por una PS4 Pro y siendo reescalado por el chip de reescalado del televisor que bien podría ser un X1 Ultimate de Sony, presentado en el pasado CES.

Hoy en dia existe la suficiente potencia en los televisores mas avanzados para descodificar un video en una porción del tiempo necesario para la reproducción y luego escalar el fotograma. Por otro lado no no olvidemos que en las pelicula ha sido hace recientemente poco que se han empezado a filmar a 48fps y 60fps y por tanto no toda lo están, esto es un minimo de 16.67ms entre fotograma y fotograma para el reescalado.

¿Pero que ocurre con el 3D a tiempo real? Pues que el fotograma se ha de generar dinámicamente y muchas veces no hay espacio en eso 16.7m para el reescalado porque la imagen que generan la CPU y la GPU en conjunto a lo mejor tarda ese tiempo exacto… Cuando el escalador recibiera la imagen entonces este añadiria unos 16.67ms de tiempo para escalar desde el escalador y ya estaríamos hablando a 33m/30fps realmente, por lo que en realidad los escaladores que están mostrando en televisión van muy bien para video. 

¿Pero acaso no se puede a tiempo real? Para empezar pasar de los 60fps a 120fps nativos es un 2X, en segundo lugar…

Estamos viendo 16X más veces la cantidad de pixeles que 1080P, esto son 16 veces la tasa de relleno, 16 veces la tasa de texturizado, 16 veces la potencia en Shaders respecto a PS4, esa GPU no existe en el mercado porque incluso no creo que cupiese en la litografía del chip y fuese rentable. Es cierto por otro lado que vamo a ver tecnologías de reescalado pero no tan bestia como subir la cantidad de pixeles a 4 veces más, ni 8 veces y aún menos 16 veces más.

Si quieres reescalado a tiempo real necesitas poder hacerlo en un 1ms de tiempo e incluso menos, ha de ser una nota a pie de página. Esto significa que si por ejemplo un reescalador normal tiene un fotograma de tiempo el incluido en la GPU para los juego va a necesitar un tiempo una orden de magnitud mayor. ¿Como lo piensan solventar? Pues mirad, esto ya lo comente en un video reciente en mi abandonado canal.

No creo que veamos un chip al estilo X1 pero lo que si que creo es que vamos a ver un equivalente a los Tensor Cores de Nvidia que tienen una orden de magnitud de potencia adicional para ciertas tareas respecto a los Shaders, especialmente para el tratamiento de imagen, por el momento son excelentes para tres cosas:

  • Reescalar dinámicamente las imagenes a tiempo real.
  • Reconocimiento e interpretación de imagen a tiempo real.
  • Para limpieza de ruido en escenas con Raytracing con pocas muestras por pixel.

Un Tensor Core no es más que una unidad de calculo matricial que nos permite operar con do matrices.

De momento esta en las GPU de Nvidia pero es lo que permite gracias al Deep Learning Super Sampling que una imagen a 1440P sea escalada al vuelo y a mucha rapidez a 2160p/4K. Pues bien, dicha técnica utiliza los Tensor Cores en la serie Turing para conseguirlo con la suficiente velocidad.

El juego se renderiza a una resolución menor y, al igual que en esas técnicas de mejora de imagen que funcionan tan bien gracias al deep learning, DLSS produce una imagen de mayor resolución. Pero estamos seguros de que aquí hay más cosas de las que dice Nvidia. Para empezar, DLSS depende de juegos que utilicen anti-aliasing temporal (lo cual, siendo justos, cubre prácticamente todos los motores actuales). Esto sugiere que DLSS extrae información de los anteriores frames para ayudar en su reconstrucción y en las mejoras que introduce con su algoritmo.

Sabemos que este es el caso porque, al igual que con la técnica de inyección temporal que hemos visto en títulos como Spider-Man para PlayStation 4, en cada corte de escena no hay datos del frame anterior para que trabaje el algoritmo. Esto nos deja con un frame con la imagen sin tratar y, por lo tanto, que DLSS también permite contear los pixeles. Solo tenemos las demos a 4K para trabajar, pero Nvidia ha confirmado que la resolución base es 1440p. Esto reduce de forma masiva la potencia necesaria para generar el frame base, y a partir de ahí entra en juego DLSS para reconstruir la imagen. La verdad es que hace un trabajo destacable teniendo en cuenta que tiene para trabajar el 44% de una imagen 4K completa. 

¿Pero como vamos a ver esto en la siguiente generación de consolas si supuestamente el proveedor es AMD que no tiene la misma tecnología. Bueno, yo tengo una hipotesis que ya comente recientemente basado en el concepto de la Super-SIMD, tecnicamente para hacer las operaciones con las matrices es que necesitamos la capacidad de poder trabajar con 16 elementos por matriz y con precisión de 16 bits cada elemento. La actual Compute Units de las GCN es de 4 unidades SIMD16.

El problema es que cada unidad SIMD16 no puede operar con las demás porque se encargan de una ola/wavefront distinto y si quieren compartir datos escriben los datos en la Local Storage Share que esta «Shared»/Compartida entre todas las unidades SIMD.. En el caso de Nvidia para no complicar lo que han hecho es colocar los Tensor Core aparte, el tema es que en el caso de AMD tenemos una cosa que es el Rapid Packet Math que es lo que permite que una ALU y su registro se pueda comportar como varias a menor precisión. 

Esto lo vimos en la primera AMD Vega, pero en la Vega a 7nm han renovado sutilmente las SIMD de la Compute Unit. Lo que han hecho es que en vez de colocar de manera natural una SIMD16 con precisión FP32 para poder alcanzar las cifras en FP64 de Volta, en vez de añadir ALUs en FP64 que ocupan un gran espacio adicional han hecho que cada SIMD sea SIMD8 en FP64 que se puede subdividir en SIMD16 FP32, por lo que a nivel aparente no hay cambios.

Pero hay una patente es que la de la unidad Super-SIMD donde se nos explica que pasamo de una ALU SIMD asignada a los registros…

… A tener unas dos ALUs SIMD con una Operand Destinacion Cache que es ideal para comunicar ambas SIMD internas.

Como no podemos superar la cantidad de ALU en FP32 en toda la Compute Unit para no romper la compatibilidad  en cuanto a arquitectura GCN pienso que en el caso que esto sirva para el GFX10 (Navi) entonces tenemos 2 SIMD8 a FP32 reemplazando una 1 SIMD16 en FP32 en el viejo esquema, en modo retrocompatible ambas funcionarían como 1 SIMD16 en FP32 por lo que su funcionamiento no difereria en nada para el software ya existente y el diagrama de la Compute Unit y su organización sería casi el mismo.

El caso es que una configuración SIMD8 a FP32 es una configuración SIMD16 a FP16 y necesitamos 16 elementos para las matrices. Ya podemos con esto hacer funcionar las SIMD de la Compute Unit de manera conmutada (en Nvidia también ocurre) como Tensor Cores haciendo que ambas unidades SIMD en modo FP16 operan entre ellas, se que es algo cogido con pinzas pero tengo muy claro que vamos a ver algo así en AMD por el tema del Raytracing más que nada y porque la pasada primavera… Ejem…

Esto es de una presentación de AMD y el «Denoising» donde es verdadero efectivo ejecutarlo es en núcleos tipo Tensor Cores, pero este tipo de núcleos estarán solo disponibles en la Navi (GFX10) y no en la que inicialmente veremos en PC.

El cuento de las dos Navi

Hace unos días vi un video en Youtube de un tal Coreteks muy bien trabajado donde especulaba sobre la gama AMD Navi en PC de la que se supone que será la base para la GPU de la siguiente generación de consolas.

En el video habla de Navi y de Navi+, en parte coincide con la especulación de la que os comente el pasado mes de Septiembre donde Navi Lite en el caso del video que nos ocupa es conocida como Navi y lo más seguro que sea lanzada como tal por motivos de marketing mientras que la Full Navi será conocida como Navi+. ¿La diferencia entre ambas? Que una será GFX9 y por tanto una Vega encubierta y la otra será la GFX10 que es lo que permitirá hacer todo lo que he hablado antes en esta misma entrada.

Por lo que en resumen:

  • Existen dos GPUs Navi que no son una la versión reducida de la otra.
  • Internamente a la Navi menos poderosa se la conocia hasta hace poco como «Navi Lite» en realidad es una GFX9 (Vega) con algunos elementos de Navi. La otra era la verdadera Navi (GFX10) pero por motivos de marketing se la va a llamar Navi+ mientras que Navi Lite saldra Navi a secas.
  • Navi Lite tiene 40 NCUs, originalmente se la conocia como Navi 14 (Fourteen) por una mala transliteración cuando realmente debería ser Navi 40 (Fourty).
  • Ambos modelos de Navi descartan la cara memoria HBM2  a favor de memoria GDDR6.
  • El High Bandwidth Cache Controller ha sido eliminado.
  • Soporte PCI-Express 4.0 e Infinity Fabric en ambos chips.
  • El Tape Out (Diseño finalizado y primer prototipo funcional) se produjo dos meses de finalizar el de la actual Vega 7nm, por lo que para el CES de este año AMD podría presentarlas.
  • El rendimiento de Navi 40 sería equivalente a una GeForce 1070, su velocidad de reloj y ancho de banda son más altos que la actual RX 590.

En realidad Navi/Navi Lite no es otra cosa que una Vega donde la memoria HBM2 se ha visto reemplazada por memoria GDDR6 para reducir costes. AMD hace tiempo que la tenia en la trastienda de sus laboratorios para lanzarla este año en vez de la RX 590/Polaris 30. ¿Que ha ocurrido? El alto precio de las obleas bajo el proceso N7 de TSMC que no ha llegado a la madurez en rendimiento, lo que hace que por el momento se este utilizando para chips de tamaño pequeño como son los SoC de Smartphone o el chiplet CCX del Ryzen de tercera generación que presentaron hace unas semanas. Esto ha provocado que AMD no pueda vender al publico a la Vega 7nm, la cual no solo es cara por la memoria HBM2 sino que además extremadamente cara por el proceso de 7nm que aún no ha alcanzado la madurez. ¿Que tiene que ver esto con Navi 40? Esta construida bajo el mismo nodo y su coste era demasiado alto cuando AMD se planteo la fabricación el pasado verano por lo que la han movido al año siguiente. ¿Y porque no la llaman Vega? Pues por el hecho de que Vega tiene mala prensa y porque AMD va a relacionar sus GPUs utilizando GDDR6 con Navi aunque sean dos arquitectura distintas de manera interna (GFX9 vs GFX10).

Pero por lo visto Navi tiene otro secreto, AMD desde hace un tiempo que dice que va a hacer MCM al estilo Epyc pero utilizando al menos una GPU, el modelo Chiplet es contraproducente para una GPU por lo que harán sera fusionar el IO-Core que hemos visto en el AMD Rome con la GPU, obviamente este IO-Core no tendrá que comunicar uno 64 núcleos Ryzen y será mucho más simple, tampoco estara fabricado a un nodo diferente de los 7nm… ¿Y para que servira esto? Pues para poder montar MCM en el que solo seria necesario colocar 1 o 2 Chiplets CCX como los del AMD Rome en el mismo interposer y conectarlos via Infinity Fabric… ¿Os acordáis del MCM de Wii U? Pues esteticamente quedaría algo parecido.

La separación de la CPU del resto de componentes permitiría que no hubiese el ahogamiento termal. ¿Pero va a hacer esto AMD con Navi o con Navi+? El caso es que lo podrá hacer con cualquier GPU que tenga el IO Core integrado, aunque eso si, AMD a nivel de tarjetas de PC no lo va a integrar por lo que al final tendremos:

  • Navi40
  • Navi con IO Core integrado con menos Compute Units debido al espacio ocupado por el IO Core.
  • Navi+/Full Navi (Cantidad de Compute Units desconocida), 
    este ira para los sistemas de siguiente generación.
  • Navi+/Full Navi (Cantidad de Compute Units desconocida) con menos Compute Units debido al espacio ocupado por el IO Core, este ira para los sistemas de siguiente generación.

Obviamente la integración de Navi con el IO Core vendrá después y es que si lo que se comenta entre bambalinas es cierto entonces la «Navi Lite» al ser un derivado de las GFX9 sin HBCC (Por el uso de la GDDR6) habría estado terminado a principios de verano por completo y llevaría unos meses en pruebas de fabricación para lanzarse el primer semetre de 2019, el video de Coreteks comenta que Navi+ es la que se encontraba en los laboratorios el pasado Septiembre, pero Navi+ como ya he comentado es otra arquitectura, es la GFX10 que implementa la unidad Super-SIMD que os he comentado antes y que va a permitir el uso de dichas unidades tanto como shaders como el equivalente a las Tensor Cores de Nvidia.

¿Y el Raytracing pa cuando?

Una de las cosas en las que Nvidia parece haberle tomado la delantera es en la inclusión de los RT Cores en Turing, los cuales son unidades de función fija que tienen el trabajo de calcular la intersección entre un rayo y un objeto en la escena. Se trata de una operación recursiva que incluso tirando de una GPU más potente (Volta) se obtienen resultados peores que utilizando dicha unidad para el Raytracing.

Es Nvidia la que esta colocando el uso de los Tensor Cores para el Denoising pero su uso esta más allá de la especificación de Microsoft para el DXR, es decir, se puede realizar un sistema compatible con el DXR sin el uso de los Tensor Cores. Pero en el caso del RT Core no existe una especificación cerrada y general sino que cada fabricante puede crear su RT Core como quiera con total libertad mientras realice la función.

Fijaos como la estructura de datos espacial es construida al vuelo por la GPU en cada fotograma.

Ahora mismo AMD para lo que es el calculo de la intersección de lo rayos utiliza la libreria Radeon Rays.


Radeon-Rays es una librería de la GPU para la aceleración de la intersección con soporte básico para sistemas hetrogeneos. AMD ha desarrollado Radeon-Rays para sacar el máximo de las GPUs de AMD y sus CPUs y APUs, así como de evitarles de mantener código dependiente del código. Radeon-Rays expone una bien definida API en C++ para la construcción de la escena y para realizar las peticiones asincronas de los rayos. La implementación actual se basa en OpenCL, lo cual significa que Radeon Rays soporta la ejecucion en todas las plataformas compaibles con el estandar OpenCL 1.2. No esta limitado al hardware de AMD o a un sistema operativo especifico. Radeon-Rays puede ser facilmente distribuido y a través de su API asegura compatibilidad y el mejor rendimiento a través de un amplia gama de plataformas de hardware.

Pero tiene el problema que a nivel de software no se adapta muy bien a la naturaleza de las Compute Units de la arquitectura GCN. En todo caso perdón por coger cosas de otra entrada.

Le he echado un vistazo a más kernels de RadeonRays, pero mis impresiones no cambian. Basicamente los descarte todos tempranamente por el hecho de que utilizan un arbol binario, lo cual resulta en ir saltando por la memoria locamente y GCN rinde mal con esto, Nvidia es más permisiva con los malos patrones de acceso a la memoria. (Info no relacionada: Nvidia es también más permisiva con el código no optimizado o si lo preferís, AMD premía más la optimización del código).

No digo que el código sea malo o poco optimizado, pero en mi opinion los arboles binarios es la peor solución. Utilizarun arbol con mayor cantidad de ramas (por ejemplo de 8, 16… hijos por nodo) permite leer los los nodos hijos desde la memoria coherente y procesarlos en paralelo si se quiere. Aparte que el arbol tiene muchos menos niveles, lo cual limita la divergencia.

Es decir, la forma que AMD ha escogido para ordenar la geometría de la imagen en una estructura del tipo BVH es un arbol binario, en el Raytracing una de las BVH más utilizadas es un tipo de arbol binario llamado KD-Tree.

kdtree

El problema es que hacer esto en las unidades SIMD de las GPU es sumamente ineficiente por el hecho que solo podemos utilizar como mucho dos ALUs de cada unidad SIMD, de ahí a que en la cita se hable del uso de estructuras en arbol con más ramas.

Octree-subdivision

Pero en el caso de que estemos hablando de un RT Core para realizar la intersección entonces puede estar operando con un KD-Tree perfectamente porque opera en paralelo y completamente aparte de los shaders. ¿Que es lo que pienso? Recuerdo como hace unas semanas el actual máximo responsable del RTG Group dejo caer en una conferencia en Japón que iban a implementar el Raytracing en todas las gamas. ¿Sabéis que pienso? AMD es consciente que no puede lanzar Navi40 vs RTX 2060 y no tener soporte para Raytracing que es la palabra de moda en estos momentos, pienso que vamos a ver Navi40 con RT Cores a la AMD siendo presentada en el CES y que se va a estandarizar en todas las gamas futuras, solo que AMD hará al revés que Nvidia, en vez de empezar de arriba a abajo empezará de abajo a arriba, obviamente la Navi 40 no tendra el equivalente a los Tensor Cores.

Pero el añadido de los RT Cores vendría a ser algo reciente y desde el momento que es una actualización importante en lo que es la unidad GFX por lo que a nivel técnico habría dejado de ser una Vega con GDDR6 para ir a un nivel más alla y habría pasado a ser una «GFX10» en la nueva nomenclatura. Navi+ en cambio sería la antigua GFX10 pero que por el uso de unidades Super-SIMD sería llamado GFX10+ o GFX11, pero AMD tiene que llamar GFX11 a lo que desde hace tiempo se llama Next Gen.  Por lo que utilizando la lógica y las palabras de David Wang entonces Navi 40 no llevara los RT Cores y lo veremos directamente en lo que es Navi+.

Lo gracioso es ver a la prensa con una incapacidad de reflexión sobre el tema y con esto termino y vuelvo al inicio del video. El aumento de resolución no soluciona ciertos problemas visuales que el Raytracing si que soluciona, siendo lo primeros problemas en ser solucionados tanto los reflejos como las sombras.

El compotamiento correcto del transporte de la luz no se puede representar bien con el rasterizado y con ello la generación de las sombras es incorrecta por completo llegando al punto de ser imposible generar sombras suaves bajo el rasterizado convencional.

El otro ejemplo son los reflejos que en el fondo es la refracción de luz sobre los objetos, esto en la rasterización tampoco se puede representar de manera fidedigna con la rasterización.

Es decir que hemos llegado a un punto en que aumentar la resolución en la rasterización no nos lleva a mejora en la calidad de imagen que es lo que deberíamos esperar de cara a una siguiente generación y no solo un aumento de resolución. Obviamente no creo que veamo a corto plazo el hardware para la siguiente generación dado que lo que son los chips finales con el IO Core y la GPU integrados en un mismo chip aún están en fase de diseño y no en el laboratorio de pruebas. AMD deberá primero terminar la integración del IO Core en Navi Lite (GFX9) para poder crear un nuevo SoC que en el fondo será un SoC de «Vega»+Ryzen y aquí entramos en algo del mapa de ruta que es curioso.

AMD llama a la versión de «12nm» del Raven Ridge  bajo el nombre de Picasso, no tiene nada de especial excepto una muy segura subida en la velocidad de reloj como ocurre con Polaris 30/RX 590 pero el diseño es el mismo, lo que llama la atención y siguiendo con la lógica de los nombres de pintores es Renoir.

Renoir va a ser la integración en un SoC en formato MCM de lo que es la primera Navi (la más simple) con uno o dos chiplets CCX Ryzen. Obviamente para ello hará falta la integracíón del IO Core junto a la GPU como he dicho antes.

Y ahora os voy a decir algo que os va a sorprender, creo que vamos a ver 2 SKUs diferentes de cara a la siguiente generación, una con Raytracing integrado y la otra sin. Ambas con una capacidad de calculo muy superior incluso a las versiones mejoradas de la actual y en el caso de PS5 con la capacidad de que ambos modelos muevan los juegos de PS4 a 4K nativos pero con el primer siendo más barato, posiblemente unos $399 de salida o un precio así mientras que la versión con Raytracing acabaría teniendo un valor posiblemente de $499 en ambos casos, en ninguno de ellos se incluiría como es obvió la unidad VR y sus accesorios y tambien es posible que no se lancen al mismo tiempo pero si en un tiempo menor de distancia que la que hubo entre PS4 y PS4 Pro.

Y con esto termino, tenéis los comentarios de esta misma entrada y el Discord para comentarla.