Comentario Original:

Ante todo muchas gracias por la info.

Aunque a mi no me sorprende lo del hardware raytracing por parte de AMD. En una diapositiva de su hoja de ruta decía bien clarito que RDNA2 iba a llevar incorporado los rayitos dichosos.

Hay que ser un completo borrego el pensar que solo Xbox iba a tener tal cosa, como si fuese Microsoft el inventor y no AMD. Se sabía también que iba a llegar al PC en el 2020. Todo es cuestión de tiempo. Software, consolas, optimizacion y luego PC.

Aunque yo pienso igual con el dichoso Ray Tracing. Marketing made by Nvidia para justificar sus precios y que su última arquitectura no tiene un salto de rendimiento tan grande.

Fíjate como es el marketing que ya he leído a gente sorprendiendose de que AMD consiga lo mismo que los verdes si Nvidia son los inventores del Ray Tracing. Como mala persona que soy quiero que el chaquetas se la siga pegando con RTX y que por una vez AMD pueda con su solución de Ray Tracing hacer morder un poco el polvo a Nvidia. Aunque viendo los precios de Radeon.. no me quiero imaginar sus precios cuando lleven RT. Al final me veo rezando para que Intel saque algo decente con sus GPU y a buen precio.

En fin.. que espero ver alguna vez por parte de AMD hacer lo mismos tanto en precios como en calidad del producto con sus GPUs y no sólo con sus CPUs.

Bueno, Nvidia dice ser la inventora de la GPU pese a existir ya de antemano hardware que realizaba la geometría en el propio chip gráfico de antemano, el ejemplo que se me ocurre ahora es el RCP de Nintendo64 salvando las distancias de potencia con la primera GeForce y el R1000-Pro de 3DLabs/Lockhead Martin utilizado en la placa recreativa Model 3.

Lo del Raytracing en Radeon es un parche de ultima hora viendo la organización del RDNA y donde han colocado la unidad de interseccion, por eso he comentado lo del espacio en el chip ya que viendo la organización del mismo no parece que haya mucho espacio para colocar dicha unidad en el hardware.

Los rumores que aparecieron hace unos meses es que va a ser Navi «20» la que va a llevar este cambio, lo cual es raro porque normalmente las versiones «20» son el mismo chip bajo un nuevo nodo de fabricacíón y sin cambios arquitecturales, pero resulta que existe una «Navi 21 y una Navi 21 Lite» según los drivers de AMD.

Por lo visto vamos a tener cuatro series de tarjetas RDNA en el mercado:

  • RX 59×0: 100% seguro que van a ser Navi21.
  • RX 57×0: Basadas en Navi 10, es el primer chip que han lanzado.
  • RX 56×0: ¿Navi 12 o Navi 14?
  • RX 55×0: ¿Navi 12 o Navi 14?

Las GPUs por debajo del RX 57×0 parecen no tener soporte Raytracing y diría que son versiones que escalan con el controlador de memoria, teniendo en cuenta el concepto de Cluster alrededor de la Cache L1…

Y viendo como cuatro particiones de cache L2 están asignadas a un controlador de memoria de 64 bits, lo que se me ocurre es la siguiente configuración:

  • RX 57×0: 4 Controladores de memoria de 64 bits (GDDR6 256 bits), 40 CUs en total, 4MB Cache L2.
  • RX 56×0: 3 Controladores de memoria de 64 bits (GDDR6 192 bits), 30 CUs en total, 3MB Cache L2.
  • RX 56×0: 2 Controladores de memoria de 64 bits (GDDR6 192 bits), 20 CUs en total, 2MB Cache L2.

¿Y que hay del chip que falta que va a ser la gama RX 59×0?

Pienso que la implementación de los RT Cores pillo con los pantalones bajados a AMD por completo y de ahí que lo hayan implementado a última hora en «Navi 21» que es la que tiene que reemplazar a Radeon VII. ¿Y como pienso que será la tal RX 5900? Pues no me extrañaría que algo así:

  • RX 59×0: 6 Controladores de memoria de 64 bits (GDDR6 384 bits), 60 CUs en total, 2MB Cache L2.

¿En que me baso? Primero de ello en la forma en la que han integrado su solución, hay una pista enormemente importante en la misma patente que todo el mundo esta comentando y es algo que sinceramente me ha dejado…

¿El que precisamente? Bueno, dado que AMD no tenía espacio en RDNA, la solución de la patente es tomar un camino hibrido entre el shader (unidades SIMD) y la Intersection Unit, haciendo que a la hora de atravesar el arbol BVH difiera de la solución de Nvidia.

En cuanto al recorrido del BVH, lo que hace el motor de intersección es comprobar si hay intersección en el actual nodo solamente y el recorrido del arbol BVH ha de ser llevado a cabo por los Shaders. La solución de Nvidia por lo visto y según los expertillos delos medios es que el propio RT Core tiene dos unidades, una para recorrer el arbol y otra para comprobar si hay intersección o no. En el caso de Nvidia si hay un «miss» en la intersección entonces el RT Core sigue recorriendo los siguientes nodos esta que se encuentra con un «hit» total o parcial, entonces devuelve el resultado pero en el caso de la de AMD no ocurre lo mismo y cada nodo del arbol sea un miss o un hit se tiene que continuar realizando.

La especificación de DXR no indica como de recorrerse la estructura de datos espacial ni de que tipo ha de ser.

De ahí a que sea opaca por completo al pipeline, pero hay una trampa en todo esto y por eso incluí un addendum en la anterior entrada que parece no tener sentido, cuando os hable de la naturaleza de las unidades de texturas que desde los tiempos de la Voodoo Graphics son unidades de cálculo matricial. El caso es que en Nvidia lo que es el recorrido no no especifica como esta realizado y la sospecha que yo y mucha gente tenemos es que esa tarea no la realizan los RT Cores que realizan la intersección sino los Tensor Cores.

En el caso de AMD el motivo de incluir la unidad de intersección al lado de la unidad de texturas me parecio curioso ya que si lo pensamos bien podemos convertir dicha unidad de texturas en algo más complejo de lo que es actualmente y que esta no tenga el nivel de complejidad que los Tensor Cores pero que al ser una ALU matricial pueda realizar el trabajo de los tensor cores de cara a atravesar el arbol… ¿El problema? El arbol BVH se encuentra en un nivel de cache más allá al que las unidades de texturas no tienen acceso directo a no ser que hagan una petición. ¿Es posible que la unidad de filtrado de texturas doble su función? La patente no habla de ello pero hay una cosa que desde que presentaron RDNA al público me tuvo un poco…

El primero es el Radeon Image Sharpening…

AMD lo separa del llamado FidelityFX que presentaron al mismo tiempo, ambos son soluciones que Nvidia a día de hoy enviaría a los Tensor Cores al ser soluciones de post-procesado de imagen. En el siguiente video oficial de AMD la descripción para el Image Sharpening parece ser muy parecida a la del DLSS de Nvidia.

El ingeniero de AMD comenta que cuando aplicamos cosas como un upscaling de resolución, efectos como el Temporal Antialiasing… La imagen se vuelve «blanda» y esto me ha dejado en modo…

Y no porque sea un concepto erroneo porque no lo es en absoluto sino que no me explico como veréis más adelante que diferencias hay entre el Image Sharpening y el FidelityFX que presentaron al mismo tiempo. Por lo que son lo mismo.

El llamado FidelityFX parece ser exactamente lo mismo que el DLSS de Nvidia a simple vista, pero en RDNA no tenemos los Tensor Cores por el medio. FidelityFX de AMD es un kit de herramientas de software que contiene algo llamado CAS. CAS es una característica que los desarrolladores pueden incorporar en sus juegos para mejorar la calidad de la nitidez en resoluciones más altas, con una desventaja mínima en el rendimiento. El llamado FidelityFX por lo tanto a simple vista parece ser exactamente lo mismo que el DLSS de Nvidia pero sin los Tensor Cores por el medio.

Pero la solución de AMD parece funcionar utilizando los shaders, de ahí lo de «Compute» en la siguiente diapositiva:

Y esta última diapositiva nos lo confirma:

Es decir, no hay Tensor Cores en RDNA porque si así fuera dicha funcionalidad caeria en ellos en vez de las unidades SIMD/Shader por lo que la unidad de texturas no ha sido modificada y sigue siendo igual de siempre y al no haber el Tensor Core para atravesar el arbol BVH entonces dicha tarea recaé sobre el shader y la conclusión es que la solución de AMD es peor que la de Nvidia y la aplicación del Raytracing en este va a tener un impacto mucho mayor en el rendimiento total, quizas sea por esto que AMD haya decidido que la RX 59×0 sea la que tenga Raytracing al fin y al cabo y no las gamas inferiores. Esto significa que a no ser que haya algo que no sepamos entonces la solución de AMD en RDNA debería hacer que con Raytracing una hipotética RX 57×0 con esta unidad rindiera peor que la RTX 2070.

En realidad AMD esta cumpliendo la especificación mínima del DirectX Raytracing, dondo la estructura de datos y la forma de atraversarla no es descrita bajo la especificación minima de la patente. Entiendo que la solución de Nvidia es que el RT Core puede continuar atravesando el arbol BVH mientras se aplica el shader correspondiente en paralelo. mientras que en la solución de AMD no y tiene que el propio shader recorra el siguiente nodo del arbol BVH . En todo caso en DXR se ha de devolver al shader el resultado de cada intersección para que actue en consecuencia.

Hay que tener en cuenta que los Tensor Core en Nvidia son ALUs que utilizan la misma unidad de control que los «núcleos» CUDA y realmente el núcleo es el SM en si mismo. Es por ello que muchas veces digo que los Tensor Cores funcionan de manera conmutada porque no se pueden utilizar «ambos» a la vez. Bueno, no es 100% así sino que cada una de las cuatro subsecciones del SM en Turing se encarga de una ola distinta y podemos utilizar los núcleos CUDA o los núcleos Tensor.

En RDNA, los núcleos Tensor no existen y en AMD en concreto han colocado a Vega 20 en el mercado HPC y el mercado del Deep Learning. Un mercado necesita ALUs en FP64 que RDNA no tiene y ALUs soportando Int8 que RDNA tampoco (solo soporta FP32 y FP16). En realidad Navi 21 tiene que traer consigo ese soporte con tal de reemplazar por un lado la MI50 y Mi60 en dichos mercados y no solo la Radeon VII en el mercado doméstico. Pero AMD no parece muy metida en el hecho de añadir dichas unidades. Lo curioso es que en cuento a la cantidad de transistores y especificaciones en general, Navi 10/RDNA/RX 5700 compite contra la TU106 que tiene la misma cantidad de transitores y 36 SM en vez de 40 CUs, más bien la no-inclusión de los Tensor Cores y su no-uso para atravesar el arbol BVH cargando el trabajo a los shaders diria que es por la falta de espacio en el chip y el hecho que ha sido un parche de última hora ha afectado a esto.

¿Que nos podemos esperar a futuro en PC? Pues que de cara a un enventual RDNA2 en PC veamos que la unidad de texturas evoluciona para ser más versatil y convertirse en un «Tensor Core» de AMD o que la propia AMD añade este tipo de unidades en el pipeline. El caso es que existe una confusión porque AMD diferencia Next Gen RDNA y RDNA2 en el mapa de ruta y diría que «Next Gen» RDNA y RDNA2 no son lo mismo.

«Next Gen RDNA» parece ser Navi 2x que veremos en unos meses y que incluye la unidad de la patente y pareces ser la arquitectura de GPU que se va a incluir en PS5 y Scarlett estando fabricada bajo 7nm FinFet. RDNA2 en cambio es un paso más adelante que se lanzará en PC bajo el proceso de 7nm+ (EUV) que requiere para su implementación un re-diseño de los chips.

¿En que se puede traducir esto? Pues que el soporte Raytracing en PS5 y Scarlett va a ser limitado en comparación lo que hay en PC en estos momentos y no renderírá lo esperado por lo que esperaos para recortes de resolución al aplicar el Raytracing o una aplicación más simplificada de este por la poca información que tenemos.

La única solución a este problema sería que AMD añadiese fuera de la Compute Unit una nueva unidad que paradojicament este donde dije que estaría exactamente el RT Core y tendría que estar fuera con tal de poder atravesar el arbol BVH que se encuentra en la cache L1, dado que la unidad de intersección solo puede leer de la cache L0. ¿Y donde iría esta unidad? Es decir, la nueva unidad sería la encargada de recorrer el arbol BVH o la parte de este en la Cache L1 y liberaría al shader de ello, pero no hay espacio. ¿La única solución? Los 7nm+ obligan a re-hacer el chip pero TSMC recientemente presento un nodo llamado N6 que no deja de ser un nodo N7 pero con mayor densidad.

Esta semana, TSMC presentó su nueva tecnología de fabricación de 6 nm (CLN6FF, N6), que se establece para ofrecer una densidad de transistor considerablemente mayor en comparación con el proceso de fabricación de la compañía de 7 nm (CLN7FF, N7). Una evolución del nodo de 7 nm de TSMC, N6 continuará utilizando las mismas reglas de diseño, lo que facilitará a las empresas comenzar el nuevo proceso. La tecnología se utilizará para la producción de riesgo de chips a partir del primer trimestre de 2020.

TSMC afirma que su tecnología de fabricación de N6 ofrece una densidad lógica 18% más alta en comparación con el proceso N7 de la compañía (1ª generación 7 nm, solo DUV), pero ofrece el mismo rendimiento y consumo de energía.

Ese 18% de densidad adicional podria servir para añadir la unidad que falta al Raytracing de AMD, la unidad encargada de recorrer el arbol BVH y que sea independiente a los shaders. ¿El problema? Por lo visto el SoC de las consolas ya esta terminado y por ello Ariel/Gonzalo ya esta en la etapa del QS, es decir, no va a volver al laboratorio y sea para la consola que sea que termine y a no ser que ignoremos algo su suporte para el Raytracing es peor que Turing por lo que he explicado antes al basarse en Next Gen RDNA/Navi 2x.

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