Blog Personal.

Uncategorized

Creación del BVH vía hardware y otros cosas.

Comentario Original:

Muy interesante el post Urian. Parece ser que estamos en una nueva generación en la que se experimentará con varias soluciones para generar una iluminación realista en los videojuegos, y será interesante ver que técnicas se imponen al final.

Además me ha despertado mucha curiosidad como funciona esa unidad de función fija que crea el BVH en las nuevas gráficas, y que es una gran desconocida.

Uno de los problemas básicos supuestaente «aún» no resueltos de cara al trazado de rayos en un hardware doméstico es la incorporación de una unidad capaz de construir la estructura de datos en arboil que almacena la información geométrica que contiene la escena.

Y digo aún entre comlllas por el hecho que este tipo de unidad especializado ya fue incluida en el PowerVR Wizard de Imagination hace unos años.

El SCG es una unidad de función fija que toma los datos que le llegan de la geometria de la escena y a partir de la información de este construye dos arboles BVH, una para la geometría estática y otro para la geometría dinámica (objetos con animación).

Ahora bien, no tenemos referencia alguna de manera oficial acerca de la existencia de este tipo de unidades tanto en Turing como en RDNA 2 ya que se suele hablar de la unidades de intersección y las unidades de intersección no crean el arbol BVH, lo crean pero no lo recorren. Es más, en la patente de las unidades de intersección del RDNA 2 nos deja bien claro que los nodos del arbol se almacenan en la cache.

Es decir, la unidad de intersección recorre el arbol BVH pero… ¿Que es lo que construye dicho arbol BVH? No tenemos referencia de ello en ningún momento, es más, hay que tener en cuenta que la geometría ya procesada por el pipeline geométrico que va a rasterizar va a parar momentaneamente a la Cache L2 para ser leida por la unidad de rasterizado desde alli, la cual al igual que en el caso de Nvidia utiliza el Tile Caching pero AMD le llamo al uso de este tipo de unidad de rasterizado como «Draw-Stream Binning Rasterizer» o DSBR.

Es algo que incluyo AMD a partir de Vega en adelante y por tanto esta en RDNA y RDNA 2, en el white paper de Vega se puede leer.

El Draw-Stream Binning Rasterizer (DSBR) es una innovación importante a destacar. Ha sido diseñado parareducir el procesamiento innecesario y la transferencia de datos en la GPU, que ayuda tanto a aumentar el rendimiento como a reducir el consumo de energía. La idea era combinar los beneficios.
de una técnica ya ampliamente utilizada en las GPUS de productos de bolsillo (representación en tiles) con los beneficios de
representación de gráficos en modo inmediato para PCs con gráficos de alto rendimiento.

El renderizado en modo inmediato estándar funciona rasterizando cada polígono como se presenta hasta que toda la escena esté completa, mientras que la representación en mosaico funciona dividiendo la pantalla en una cuadrícula de tiles y luego renderizar cada mosaico de manera independiente.

El DSBR funciona dividiendo primero la imagen que se representaráen una cuadrícula de contenedores o tiles en el espacio de la pantalla y luego recolectando un lote de primitivas para rasterizar.

Como podéis ver hasta ahora se trata de exactamente lo mismo que el Tile Caching de Nvidia que os comente en la entrada de hace unos días para explicaros uno de los handicaps de la Nintendo Switch. Pero las similitudes no terminan ahí sino que van más allá.

Los tamaños de los contenedores y lotes se pueden ajustar dinámicamente para optimizar el contenido que se representa.

Es decir, que al igual que la solucíón de Nvidia, la de AMD ajusta el tamaño de los Tiles según el volumen de información a procesar y el espacio que tengamos disponible en la Cache L2… ¿Y como sabemos que lo almacena en la Cache L2? El propio paper nos lo dice más adelante.

Este diseño economiza el ancho de banda de la memoria o -chip al
mantener todos los datos necesarios para rasterizar la geometría para un contenedor (tile) en memoria rápida en chip (es decir, el caché L2).

Justo lo mismo que en Nvidia con el Tile Caching.

Por lo que Nvidia y AMD utilizan el mismo mecanismo de rasterizado y por tanto podemos realizar una explicación común ya que en ambos casos tenemos una Tiling Unit y la explicación para las GPUs de una marca sirven para la otra marca.

Lo que hace la Tiling Unit es ordenar la geometría según su posición y la agrupa en tiles, luego la unidad de rasterizado lo que hace es traer de la RAM principal hacía la Cache L2 todas las poligonos/triangulos que caben en la «cache de primitivas» pero no se trata de una cache aparte sino que es un espacio de la propia Cache L2 donde se almacena un numero limitado de primitivas, dicho número dependerá de la cantidad de atributos por primitiva por lo que el tamaño del Tile será más grande o más pequeño ya que es se trata de un búfer circular o en anillo.

El contenido del Anillo se envía como una lista FIFO a la unidad de rasterizado, pero podemos invalidar partes del anillo, como inciso esto nos sirve en casos como la aplicación de técnicas como el Backface Culling y el Frustum Culling donde eliminamos la geometría no visible.

Simplemente se marca como no válido esa parte del ring buffer y la unidad de rasterizado lo ignorara, es más, cuando se añada un nuevo poligono a la lista no lo hará en la cola sino reemplazando la información del previamente invalidado y tras ello el bit de invalidación se pondrá de nuevo a 0. Relacionado con ello una de las unidades que por ejemplo AMD ha integrado en RDNA (y obviamente veremos en RDNA 2) es el mal llamado Geometry Processor/Geometry Engine…

… Y digo mal llamado porque este procesador no calcula la geometria, tampoco es la unidad de teselación que es la Primitive Unit. El Geometry Engine es una unidad de culling que puede determinar la visibilidad de 8 poligonos por ciclo, es decir, puede marcar como visibles o no visibles estos y marcar en el ring buffer cuales se ven sin necesidad de tener que utilizar un programa vía shaders para ello. En cuanto al Occlusion Culling esto es llevado a cabo por la unidad de rasterizado y con los polígonos ya rasterizados,

¿Y todo esto que tiene que ver con el Trazado de Rayos? Bueno, aquí entramos en una paradoja, necesitamos que algo construya el BVH a través de la información de la geometría, donde la geometría de cada Tile es traida hacía la cache L2. Aquí tenemos dos escenarios posibles:

  • La unidad de generación del arbol BVH se encuentra entre el controlador de memoria y la Cache L2 y genera el arbol en la RAM, luego los nodos de este son enviados hacia las unidades según son necesarios.
  • La unidad de generación del arbol BVH comunica con la Cache L2, no genera un arbol BVH de toda la escena sino solamente del tile actual a partir de la información de la geometria en el tile actual.

El siguiente diagrama es de la unidad RT Core de Turing…

El RT Core no solamente necesita recorrer el árbol sino también tener la capacidad de ordenarlo por lo que tiene que tener acceso a los nodos del arbol BVH, en el caso de la patente de AMD al igual que en esta nos dicen que es en la cache de datos/texturas del SM/CU donde se encuentran esos datos y en ambos casos es de donde están comunicadas estás unidades. Pero lo que nos interesa realmente es la parte de dicha patente que esta marcada con el número 1002 y lo dice de dicha parte del pipeline es:

El pipeline mostrado en la FIG. 10B muestra que la creación del BVH 1002 puede realizarse antes de tiempo por un sistema de desarrollo.

Pero no nos dice ni que no como se hace…

Pero buscando un poco más nos encontramos con otra patente de Nvidia que precisamente habla de la unidad encargada de crear el arbol BVH a partir de la información de la geometría, donde precisamente se habla de dicha unidad y por tanto nos la confirma y podemos concluir que ese problema ya ha sido resuelto por completo.

¿Y acaso no se puede ordenar a través el arbol BVH a través de un Compute Shader? Poder se puede pero es mucho más lento y es una carga para los programadores, dado que es una tarea recursiva y repetitiva es mucho mejor que haya una unidad de función fija encargada de ello. ¿Entonces como es que no sabemos nada de ella? Pues por el hecho que hablarle a la gente de arboles como estructuras de datos es algo que el departamento de marketing de Nvidia no ha encontrado necesario y llega a sobrecomplicar las cosas.

Por otro lado y para terminar, si el proceso se realiza sobre la Cache L2 esto daría sentido al hecho de que Nvidia haya decidido aumentar enormemente la Cache L2 en Ampere ya que el tamaño de la Cache L2 disponible afecta el rendimiento del Tile Caching y… ¿Es posible un cambio similar en RDNA 2? Creo que si pero no se en que grado en el caso de AMD lo desconozco. Lo que si que estoy seguro es que un aumente en la Cache L2 de Turing a Ampere va a ampliar las capacidades en la serie RTX 30×0 de cara al trazado de rayos y no solo eso sino también de cara a la rasterización ya que el sistema podrá operar con una mayor cantidad de primitivas por tile.

¿Y en que me baso que va a haber sobretodo un aumento en la cantidad de Cache L2 de ambas GPUs? Primero lo hemos visto en la GA100, segundo los transitores para la SRAM tienen una densidad mucho mayor que los transistores lógicos y han escalado con cada nodo de mucha mejor manera que estos últimos.

Este el motivo por el cual AMD cuando dio el salto de los Zen+ a Zen 2 lo que hizo fue duplicar la Cache L3 por el hecho que hacerlo aumentaba el rendimiento respecto a Zen+ y el coste de hacerlo era realmente marginal. Nvidia en el salto de Turing a Ampere ha visto que existe el mismo aumento de rendimiento y hemos de suponer que AMD tiene el mismo tipo de solución por lo que hemos visto en esta entrada por lo que se va a ver afectada por el rendimiento de la Cache L2.

En el whitepaper de RDNA 1.0 se puede leer como cada partición de Cache L2 puede ser de hasta 512KB, actualmente son de 256KB por lo que es posible que tengamos RDNA 2 con 8MB de memoria en un bus de 256 bits GDDR6 por ejemplo, aunque podría ser algo más, quien sabe.

Esto es todo, tenéis los comentarios de esta misma entrada para comentar y no olvideis que tenemos Discord.

4.5 2 votes
Article Rating
1 Comment
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Set

Hay un juego de tanques, que incorporo el ray tracing de la mano de Intel y usaban el CPU para crear el árbol, que no es mala opción teniendo en cuenta las CPU de las proximas consolas.

El GA100 tiene 40mb L2 si no mal recuerdo, se habla de un entre 10% mas de IPC que le proporcionaria la L2 a Ampere.