En la entrada «¿Donde iría la unidad RT en RDNA?» comente que la unidad RT sería cliente junto a la unidad de texturas de la cache de idem (L0). Voy a autocitarme…

… en el caso de RDNA2 y mirando las diapositivas… Esto…

… entonces en RDNA evolucionaría en esto:

No he puesto el diagrama completo pero se entiende… ¿Como es que pienso así? Hay algo raro en el caso de la cache L0 del RDNA que me hace sospechar que falta una pieza.

Las unidades de texturas suelen organizarse de 4 en 4 porque se trabajan con fragmentos de 2×2 que es lo que se necesita para hacer el filtro bilineal, para el bilineal la unidadd de texturas necesita 4 muestras por pixel y de ahí que en GCN hayan 16 unidades L/S entre las unidades de texturas y la cache L1.

Pero AMD en otra diapositiva nos dice que el número de accesos por cache L0 es el doble por lo que aparte de la unidad de texturas tiene que haber otro cliente por cojones.

Es decir, tenemos 32 unidades L/S realmente pero AMD no habla de ellas en ningún momento en las diapositivas pero se intuyen lo que me hace pensar dada la organización que es para conectar las unidades para el Raytracing. Aparte que el desequilibrio de lectura/escritura de la cache L0 a la Cache L1 hace pensar que ahí puede haber espacio para algo.

Y si, puede que me equivoque pero no creo que RDNA2 difiera mucho de RDNA1, excepto en este detalle y la evolución completa a ser un Tile Renderer como os he ido comentando en las últimas entradas y que se intuye de la organización general del chip.

El otro dia cuando se publico la organización interna del chip pude observar como la parte referente a la unidad de texturas y la cache de idem (L0) están dentro de un mismo bloque y si utilizamos la lógica con lo que explique hace unos días entonces la única posibilidad que nos queda es que el «RT Core»/Traversal Unit de AMD, se encuentre dentro del bloque de la cache L0 donde esta también la unidad de texturas al completo.

La parte marcada como TMU es donde esta también la cache L0 (TCP) y la unidad de texturas además esta compuesta por lo general además de dicha cache por las unidades Load/Store (Texture Address) y las unidades de filtrado de texturas (Texture Filter) y el cambio obvió es que se le añadiría el hardware para el calculo de la intersección de rayos a dicho bloque.

Pues bien, como era de esperar así ha sido y por fin hemos podido ver la patente de AMD respecto al Raytracing por hardware, por si desaparece del enlace oficial os la dejo aquí:

La patente se basa un buen rato explicando lo que es un arbol BVH por un lado y por otro la comunicación entre la unidad encargada de la intersección y el resto de la Compute Unit, en la patente AMD llama Compute Unit a esta menos la unidad de texturas, hay que tener en cuenta que Compute Unit es un entro abstracto para especificar un grupo de elementos que trabajan en conjunto para una tarea específica. Aunque las CUs las dibujamos como bloques unitarios realmente están compuestos por varios bloques, esta pequeña aclaración será importante para aclarar un punto más adelante.

Un procesador de texturas basado en un método y sistema de aceleración del raytracing. El sistema incluye un shader, una procesador de texturas (TP) y una cache, los cuales están interconectados. El TP incluye una unidad de direccionamiento de texturas (TA) y un procesador de cache de texturas (TCP), un pipeline de filtraje y un motor de intersección de rayos. El shader envia una instrucción de textrua que incluye lo datos del rayo y un puntero al nodo del BVH al TA. El TCP utiliza la dirección proveída por el TA para tomar datos del nodo del BVH dede la cache. El motor de intersección de rayo realiza una intersección del tipo rayo-nodo bvh para testear utilizando los datos del rayo y del nodo BVH. Los resultados del testeo de intersección y las indicaciones para la travesía del BVH son devueltos al shader via al camino de retorno de los datos de textura. El shader analiza los resultados de la intersección y decide como atravesar el siguiente nodo BVH.

Se entiende como Shader las unidades SIMD dentro de la Compute Unit, estas no están cableadas directamente al TCP (cache L0) y se le llama así porque toda cache para funcionar como cache necesita un pequeño procesador especializado realizando su tarea. Para acceder a la cache es necesaria la unidad llamada TA en la patente que son las unidades Load/Store que comunican en ambos sentidos los shaders (unidades SIMD) con la unidad de texturas. Cuando la patente dice » Los resultados del testeo de intersección y las indicaciones para la travesía del BVH son devueltos al shader via al camino de retorno de los datos de textura» en realidad esta diciendo que la unidad de intersección de rayos/traversal unit/rt core esta donde dije yo hace unos días, conectado a la unidades L/S de la Compute Unit.

Dicha organización se puede ver bien en la FIG.10

Y en efecto la vieja unidad TF ha sido englobada junto al motor de intersección y ahora ha paado a llamarse TD que según la patente corresponden a las siglas de «Textura Data Unit». El Shader Unit corresponde a las unidades SIMD, el planificador de las mismas y la memoria LDS. ¿Y que es la cache? Pues la unidad de cache L1 que esta fuera de la Compute Unit pero que forma parte del conjunto común que reune las Workgroup Units/Dual Compute Unit (compuesta por 2 CUs cada uno), los RBE y la unidad de rasterizado, todo alrededor de la Cache L1.

En AMD, como he comentado muchas veces, a partir de Vega se añadio una nueva unidad de rasterizado, la cual rasteriza la escena por tiles que significa subdividir la pantalla en pequeños bloques para ello, esto le permite tener la geometría de la escena ordenada según su posición de pantalla. El caso es que el resultado lo copia en la Cache L1 y de esta se puede pasar a la cache L2 y con ello acabamos teniendo de manera ordenada y según su posición de pantalla un mapa de la geometría de la escena en la cache que nos va a servir para crear el arbol BVH.

La patente empieza haciendo referencia al arbol BVH de la escena en la FIG. 1

La patente no nos dice como se genera el BVH, solo que los datos de cada nodo en concreto de cada AABB u OBB (la patente no nos describe que tipo de BVH se utiliza) que forman el BVH no se encuentran como es obvió en la cache L0/TCP sino en la cache L1 que es donde la unidad de rasterizado vuelca los datos, dado que es una memoria interna de la GPU a la que la CPU no tiene acceso podemos concluir que es la unidad de rasterizado la encargada de generar el BVH. En realidad dado que tenemos varias unidades de rasterizado funcionando en paralelo y se asignan cada una a una cache L1, podemos concluir que los datos puede ser volcados si la cache lo necesita a la cache L2 que es global de la GPU y ser rescatados desde allí, tened en cuenta que el mecanismo de busqueda de texturas es L0←→L1 ←→L2 ←→RAM externa.

El resto de la patente no lo explicare porque lo que quiero es que sea accesible a todos la explicación de la entrada y no quiero que…

Todo esto además significa que la narrativa de los fanboys de Microsoft de que la unidad encargada del Raytracing es una a medida queda completamente destruida y dado que es una unidad de la propia AMD podemos dar confirmado que el Raytracing por hardware va a estar disponible en ambas consolas y AMD solo tiene que cambiar la unidad que engloba la cache L0 y la unidad para el texturizado por una nueva unidad dejando el resto del chip intacto tal y como esta actualmente y sin tener que hacerlo desde cero. Esto explica además el rápido cambio de GPU en Gonzalo/Ariel dado que el resto de la organización no tiene que ser cambiada y se mantiene intacta.

La unidad de texturas en GCN podía realizar filtro bilineal en un ciclo para 4 pixeles, dado que el filtro bilineal necesita los datos de 4 pixeles para funcionar (matriz de 2×2) , entonces necesitamos los datos de 16 pixeles (matriz de 4×4).

Suponiendo que cada pixel son 4 bytes de informacion entonces esto significa que las unidades L/S puede leer de la cache de texturas unos 64 bytes/ciclo, recordad que esta en GCN era llamada Cache L1.

En RDNA esa cache L1 ha pasado a llamarse cache L0 y hemos pasado a tener unas 32 unidades L/S por lo que el ancho de banda con la cache L0 ha pasado de ser de 64 bytes/ciclo a 128 bytes/ciclo. Donde los 64 bytes/ciclo adicionales respecto a GCN son utilizados para alimentar la unidad de intersección. Al mismo tiempo la unidad de intersección es capaz de enviar los datos del resultado a las unidades SIMD y aquí entramos en un punto importante que se ha de aclarar.

RDNA puede funcionar con dos tipos de olas, de 64 o de 32. AMD en el marketing no lo ha aclarado por en el documento de los drivers tenemos dos formas de distribuir las olas. En los comentarios del driver se puede leer…

En modo WGP (Workgroup) las olas del Workgroup pueden ser ejecutadas en una u otra CU del WGP. Por lo tanto, es necesario hacer bypasss a la L0 que se encuentra por CU. De lo contrario, en el modo CU y todos los Wavefronts de un Workgroup están en la misma CU, por lo que no es necesario omitir L0.

Dado que la cache L0 es donde esta la unidad de texturas entonces la conclusión es que el modo Workgroup no se puede utilizar para el raytracing ni tampoco para los fragment/pixel shaders. El modo Workgroup es el modo Wave32, donde la cache L1 envia un Wavefront/Ola de 64 elementos a un WGP y este internamente en dos grupos de 32 elementos. Por lo que podemos deducir que cuando la unidad de intersección devuelve los resultados envia una ola en modo CU con 64 elementos como mínimo, uno por cada elemento de la ola.

Hemos de tener en cuenta que las ALUs de la unidades SIMD de las GPU de AMD a partir de Vega soportan el llamado «SIMD dentro de un registro» que les permiten operar no solo como una unidad FP32 cada una sino como dos unidades FP16 o cuatro unidades Int8 por la misma instrucción. En el Raytracing realmente es posible realizar la intersección con solo 8 bits de datos por rayo. En realidad este metodología es utilizada por Nvidia en Turing, ya que pese a que las unidades RT realizan una cantidad ingente de operaciones por ciclo a nivel interno, Nvidia no las cuenta en el total de FLOPS las operaciones de los RT Cores, lo que da que pensar que realmente están realizadas por enteros y muy posiblemente en Int8.

En AMD no creo que sea diferente por lo que tecnicamente podemos enviar el resultado de la intersección de hasta 256 rayos por Compute Unit/ciclo. Suponiendo un hipotetico RX 5700 xT con la unidad de texturas cambiada esto son unos 10.000 rayos ciclo por ciclo de reloj como máximo y teniendo en cuanta la velocidad de dicha tarjeta entonces… una hipotética RX 5700 XT debería ser capaz como máximo téórico de…

10.000 rayos ciclo por ciclo de reloj *(1755*10^6) ciclos de reloj= 17.5 Gigarayos/seg.

La cifra es muy superior a lo esperado a su equivalente en Nvidia que es la RTX 2070, no es que sea así sino que la conclusión que podemos sacar es que se necesitan varios ciclos por rayo. Viendo las Nvidia Turing la conclusión es que se necesitan entre 3 o más ciclos por rayos y es posible que en el hardware de AMD ocurra lo mismo, esto nos dejaría el resultado de la siguiente manera:

10.000 rayos ciclo por ciclo de reloj *(1755*10^6) ciclos de reloj/ 3 ciclos por rayo= 5.5 Gigarayos/seg.

Lo cual lo colocaría al nivel de la RTX 2070, que es con lo que AMD compara dicha tarjeta.

Una de las hipotesis existentes es que en el hardware de Nvidia las unidades RT son en realidad Tensor Cores pero especializadas en dichas tareas y operando bajo una precisión mucho más baja que los Tensor Cores, los cuales en Volta operaban en FP32 y FP16. En realidad los tensor cores no son más que procesadores para el calculo de matrices realmente dado a como están organizadas las ALUs. Pues bien, las GPUs llevan años con este tipo de unidades… ¿Desde cuando? Pues desde antes de ser GPUs, desde…

Y si, se que muchos estaréis ahora en modo…

Pe… pero Urian… ¿Las Voodoo Graphics ya podían hacer Raytracing?

No bonitos no, me refiero a que la unidad de texturas es una unidad del tipo matricial desde lo tiempos de la Voodoo Graphics y no ha cambiado. Es por ello que todo el mecanismo de acceso a la cache de texturas es universal y esta organizado para un tipo de unidad de este tipo. Hay que tener en cuenta que las unidades de función fija tienen una unidad de control muy simplificada que solo pueden realizar un tipo de programa o una secuencia fija. Tanto las unidades de texturas como los RT Cores son unidades de función fija donde el programa que ejecutan es dispar. Tanto en Turing de Nvidia en adelante como en RDNA con Raytracing (Navi 2x) tenemos que la unidad encargada de calcular la interseccíón de los rayos comparte junto a la unidad de texturas el acceso a la cache de datos dentro de la CU/SM.

Y con esto terminamos la explicación de la patente y todo lo que rodea el Raytracing a tiempo real en la GPUs de AMD, las cuales se utilizarán en la siguiente generación de consolas.

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