Blog Personal.

Ampere, GeForce, Nvidia

RTX 30×0 (II): RT Core

La segunda parte a comentar es más confusa, debido a que Nvidia ha cambiado por completo la métrica a la hora de medir el rendimiento del RT Core respecto a Turing, pasando de una métrica basada en la cantidad de rayos por segundo a una métrica basada simplemente en la supuesta potencia de cálculo que tienen los RT Cores.

Lo del Concurrent RT+Graphics/Compute tiene que ver con el Inline Ray tracing y es una especificación mínima de DX12 Ultimate. En realidad se basa en que cualquier tipo de Shader puede invocar los RT Cores si lo necesita ne vez de verse estos limitados a ser invocados solo por el Ray Generation Shader como ocurría en Turing y la versión preliminar de DXR pero sinceramente no creo que las RTX 20×0 estén limitadas en ese aspecto.

Lo que llama la atención es que han duplicado la cantidad de intersecciones rayo/triangulo respecto a Turing pero el problema es que Nvidia nunca dijo la cantidad de intersecciones rayo/triangulo podía realizar sino que dejo ir una cifra de Rayos por Segundo… ¿Pero de donde la obtuvo?

La obtuvo testeando de los modelos de abajo que son ampliamente utilizados para el benchmarking de los algoritmos gráficos. Fijaos que son más que modelados con una gran cantidad de geometría pero carecen por completo de texturas y otros elementos.

Los Primary Rays son también llamados Camera o Eye Rays por el hecho que son emitidos por la cámara respecto al objeto para testear la visibilidad de los objetos en la escena. Si en esa parte de la imagen hay un objeto entonces generará los rayos de sombras, reflejos y otros más complejos correspondientes.

La trampa del benchmark de Nvidia con Turing era que no generaba rayos secundarios producto de la intersección, en realidad lo único que hacía era devolver el color a la cámara y nada más. Los rayos secundarios ni tan solo son invocados pero… ¿Y si os digo que el trazado de rayos a tiempo real ni tan siquiera testea sobre la escena? Pues si, lo que hace es testear sobre el BVH que es una representación en forma de arbol de la organización de la geometría de la escena en el espacio.

La idea es muy simple, se organiza la geometría por cajas según su posición en la escena. La ventaja de esto es que si en una zona de la escena no hay nada con lo que interseccionar no haces perder a la unidad tiempo en comprobar pixel por pixel si allí hay un objeto o no. Simplemente lo que hace es comprobar primero la intersección por caja (Ray/Box) y esto lo hace recursivamente en cada nodo hasta que encuentra un triangulo con el que intersecciona.

Esto esta sacado de la patente de Nvidia titulada WATERTIGHT RAY TRIANGLE INTERSECTION que hace referencia al RT Core y a su funcionamiento, la FIG. 4 que es bastante simple nos explica de forma resumida como el RT Core atraviesa el arbol BVH.

Cuando el arbol deja de bifurcarse (sub-divisiones) entonces significa que se ha llegado al último nivel y lo que tenemos es la primitiva a la que se le hace el test de intersección rayo/primitiva donde una primitiva gráfica es un triangulo. La unidad de intersección no genera los rayos secundarios sino que lo que hace es informar al resto del SM/CU que hay una intersección y dependiendo del resultado se aplicara un shader u otro sobre el área o simplemente ninguno.

Y es aquí donde esta la trampa de todo, el hardware para calcular la interseccion rayo/caja no es el mismo que el hardware para calcular la intersección rayo/primitiva. El primero a nivel de hardware es mucho más simple que el segundo y por tanto más fácil de implementar pero la utilidad en el trazado de rayos esta en el segundo.

El otro punto importante es como se organiza el BVH, cuantos nodos puede tener como máximo y por tanto cuantos nodos pueden atravesar las unidades de intersección del arbol BVH.

En el caso del BVH2 cada nodo tiene unos 2 sub-nodos mientras que en el BVH4 tenemos unos 4 sub-nodos. Cada nodo le va a devolver el resultado a la unidad SM/CU donde tenemos unas 4 olas ejecutandose al mismo tiempo cada una en un subgrupo, recordad lo que comente en la entrada de ayer donde vimos que cada SM tiene unos 4 sub-grupos. Cada uno de ellos puede enviar una petición a una de las 4 unidades de intersección rayo/caja pero la contrapartida de ello en Turing es que solo hay una unidad de intersección rayo/triangulo.

Y el caso es que si hacemos caso a la patente de AMD sobre el Raytracing RDNA2 veremos que tiene el mismo rendimiento que Turing y eso viene confirmado por la presentación de la Xbox Series X de hace unas semanas.

¿Que ha hecho Nvidia con Ampere entonces? Pues lo que han hecho es duplicar la cantidad de unidades encargadas de la intersección rayo/triangulo pero ha dejado intactas las de la intersección rayo/caja. La desventaja de la solución de AMD respecto a la de Nvidia es que comparte el camino de datos con la Cache de datos del SM/CU con la Compute Unit. Tanto una unidad de intersección como la otra recorrerán el arbol BVH hasta devolver un resultado en forma de primitiva para que luego se hagá la intersección con la primitiva que es la que realmente vale para el trazado de rayos. Dicho de otra manera, Nvidia ha duplicado el rendimiento de cara al trazado de rayos para la unidad de intersección sin tener que duplicar el RT Core al completo.

En todo caso queda mucho por hacer todavía, el RT Core solo puede testear con triangulos y no otro tipo de primitivas gráficas. Por ejemplo si quisieramos hacer una escena formada por curvas Bezier y testear entonces el RT Core fallaría irremediablemente por el hecho que su unidad de intersección no funciona con ese tipo de superficies. Por otro lado hemos de tener en cuenta que las intersecciones son una parte más de todo el pipeline gráfico y no todo el pipeline gráfico al completo y que otras partes pueden ser un lastre para la velocidad del renderizado. Esto es debido a que las unidades de rasterizado son el cuello de botella para los juegos que utilizan el planteamiento híbrido (rasterización+trazado de rayos) por el hecho que su rendimiento no se ha duplicado en el caso de las unidades de función fija relacionadas con el rasterizado. Es por ello que un juego 100% planteado para un renderizado a través de un algoritmo de trazado de rayos como es Quake 2 RTX va a duplicar el rendimiento mientras otros no lo hacen y se quedan a medio camino.

Esta claro que el futuro esta en quitarse de encima el rasterizado pero aún queda un tiempo para ello y Nvidia da como escenario más optimista el 2023 para empezar a ver los cambios, por aquel entonces ya tendremos a las GeForce Hooper en el mercado.

Es decir, aunque el salto de Ampere a Turing es espectacular (2X en la capacidad de los RT Cores) aún queda un largo camino que recorrer en este periodo de transición.

4.7 3 votes
Article Rating
3 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Hideto

Como siempre muchas gracias Urian. No lo pillo todo pero aprendo un monton. Y me divierte que es lo importante.

Acronys

Una pasada de articulos, gracias de nuevo.

steven

Hola, y si ponen doble rasterizador según sé siempre es cuello de botella por ejemplo en la gamecube.