Llevo unos días haciendo internamente una serie de articulos que voy ampliando y revisando pero no completando pero tengo la cabeza en otras cosas que me parecen en estos momentos más interesantes desde mi punto de vista. No olvidéis que esto es un blog personal y no un blog de noticias por lo que el contenido va hacía lo que el propietario del blog, que soy yo, le apetece y muchas veces entradas que son la mar de interesantes quedan en stand-by por la apatia.

En estos días donde se ha celebrado el SIGGRAPH el tema ha vuelto a ser el Raytracing a tiempo real de dos manera distintas. La primera es con el renderizado de toda una escena utilizando dicho algoritmo, algo que no vamos a ver en videojuegos por la tradición que tiene la rasterización y su mayor velocidad. ¿La segunda? Utilizar la rasterización para renderizar la escena con iluminación directa para luego utilizar el Raytracing para la iluminación indirecta.

De manera resumida… La rasterización es dibujar triangulos en un búfer de imagen para ver que pixeles cubren. En el caso del Raytracing es enviar pixeles/rayos a un búfer de triangulos para ver cuales de ellos cubren. Son diametralmente opuestos pero al mismo tiempo son perfectamente combinables porque al fin y a cabo el búfer de imagen que acabamos teniendo en el fondo y dada la definición de la rasterización tenemos en el fondo un búfer de triangulos aunque colocados en un espacio 2D pero que gracias al Z-Buffer tenemos además la información de su posición tridimensional. El problema es que el Raytracing necesita una estructura de datos espacial para interpretar el viaje de los rayos a través de la escena de manera fiable y como he comentado alguna vez, las GPUs son extremadamente lentas recorriendo una estructura de datos por la naturaleza de los shaders.

Las estructuras de datos utilizadas para ello se llaman Bounding Volume Hierarchy y su complejidad depende de la geometria de la escena.

  • Su tiempo de construcción es O(N Log N) donde N es la cantidad de triangulos.
  • Su tiempo de actualización es O(N) donde N es la cantidad de triangulos.
  • Atravesar el BVH para encontrar un dato y actualizarlo tiene una complejidad de O(Log N).

Bajo esta premisa nos encontramos que a medida que los juegos iban a haciendose con la rasterización más y más complejos en geometría, más y más compleja se hacía la capacidad de aplicar el Raytracing a tiempo real por simples razones matemáticas.

graph_complexity

Durante el Siggraph se ha revelado que el pipeline del DirectX Raytracing es el mismo pipeline que creo para el Raytracing híbrido la gente de Caustic Graphics y que luego compro Imagination Technologies para sus PowerVR Wizard, de la misma manera que Direct3D utiliza el mismo pipeline que OpenGL de base, esto significa que el mitmo tipo de cambios que realizo Silicon Graphics en su día y que influenciaron en las GPUs basadas en la rasterización y APIs como Direct3D ahora lo vamos a ver con el pipeline de Imagination/Caustic Graphics.

En dicho pipeline común primero se rasteriza…

RasterizacionDXR.PNG

Fijaos como las unidades de función fija, las no programables están en verde y fijaos como se puede encadenar con el pipeline para la raytracing.

RaytracingDXR

Tenemos ahora una unidad de función fija que lo que hace es interseccionar los rayos con la escena. Esta unidad que va separada de los shaders, es de función fija porque siempre hace lo mismo de manera recursiva y es la encargada de atravesar todo el BVH e ir actualizandolo. Cuando llega a una parte determinada del BVH se pueden ejecutar los shaders correspondientes, Microsoft los ha subdivido en cinco tipos de shaders distintos divididos en dos grupos, los dos primeros ocurren antes del calculo de la intersección de los rayos con la escena.

  • Ray Shader: Es el Shader que sirve para generar los rayos, se hace impactar cada rayo por cada pixel en la escena o por cada triangulo en la misma.
  • Intersection Shader: Nos marca como ha de interseccionar el rayo cuando impacte sobre el objeto.

El segundo es muy importante porque nos permite diferenciar entre diferentes tipos de objetos y hacer que el comportamiento de los rayos cambie una vez han impactado sobre el objeto. En la vida real cada tipo de material tiene un comportamiento distinto respecto a las fuentes de luz.

En cuanto a los que se realizan después de comprobar la intersección tenemos tres tipos que se activaran uno u otro según como haya ido la intersección con cada objeto.

  • Miss Shader: Cuando en esa parte de la escena no hay geometría este shader nos sirve para definir lo que va a ocurrir con el rayo.
  • Closest-Hit Shader: Se ejecuta una vez por rayo y nos permite definir el comportamiento del rayo sobre el objeto. Es el shader más importante porque la naturaleza de cada tipo de rayo y su función se ven aquí definidos.
  • Any-Hit Shader: Se utiliza para determinar si el objeto es transparente o no. Es importante porque los objetos transparentes no absorben nada de luz y su comportamiento es especial.

Obviamente lo que hacemos es interseccionar con el BVH y es aquí donde entramos ante un tema que os comente ya en su día pero que es esencial repetir. Hasta ahora esto solo se ha generado con los Tile Renderers porque estos por el comportamiento de su pipeline crean de manera ordenada un Triangle Buffer después del cálculo de la geometria donde se especifica donde se encuentra cada triangulo y esto se hace ordenando la escena antes de la rasterización.

sortmiddle

Para crear una lista de pantalla de la geometría por cada tile y poder renderizarlos de manera independiente.

TileIndependent

El tener dicha lista en memoria es lo que facilita enormemente esto en los PowerVR Wizard pero en la rasterización tradicional no tenemos la creación de dicha lista de la geometría o mejor dicho esa lista se descarta por completo incluso en la rasterización por tiles que no es lo mismo que el renderizado por tiles. Las GPUs hasta hace poco lo que hacían era ordenar la geometría de la escena al final del proceso.

sortlast

¿Cual es el problema? Aunque la imagen final la montemos de triangulos lo qu tenemos después de la rasterizacion ya no son triangulos sino fragmentos de nxn pixeles o pixeles… El hecho de tener una lista de triangulos definida es mucho mejor porque los triangulos siempre son más grandes que los pixeles de manera unitaria y por tanto el proceso de recorrer la escena calculando la intersección no necesita tantos cálculos que haciendo esto pixel por pixel.

El otro elemento que ayuda enormemente a los PowerVR Wizard y demas Tile Renderers para el renderizado en diferido y es sumamente útil para la combinación de la rasterización con el raytracing en ese tipo de GPUs es…

PixelLocalStoragePixelLocalStorage2

La idea del Pixel Local Storage es muy simple, en vez de escribir sobre los ROPS el resultado de los shaders escribimos sobre una memoria interna que es el PLS que nos va a permitir recuperar el dato inmediatamente en el mismo shader en vez del framebuffer. Esto va de maravilla para el renderizado en diferido, pero también para ejecutar el Ray Shader a nivel de Tile de manera inmediata y calcular el Raytracing a nivel de tile. Pero Microsoft no hace mención alguna en el DXR de los PLS y para mi son una idea genial porque permiten combinar etapas de manera muy flexible.

Lo curioso es que esto es algo que vamos a ver en Navi por parte de AMD… ¿Como lo se? Pues por los anunciados pero nunca implementados Primitive Shaders que son la combinación de varios shaders de geometria y computación utilizando precisamente el PLS. El el AMD Vega pese a anunciarse al final fueron descartados pero tenemos la famosa patente de la unidad Super-SIMD donde dicha memoria recibe el nombre de Destination Operand Cache.

super-simd.png

De momento el DXR es un affair entre Nvidia y Microsoft. Pero si os fijáis bien Microsoft en su pipeline para el DXR no menciona jamás los Tensor Cores ni el Deep Learning para el Raytracing por lo que en el fondo no se encuentran dentro de la especificación general del DXR. Dicho de otra manera, se puede construir una GPU para el DXR prescidiendo por completo de los Tensor Cores que realmente no son Cores sino que son multiplicadores de matrices incluidos en el SM.

Y es aquí donde me dispongo a comer cuervo.

eating-crow.jpg

Veamos, las unidades SM de Turing derivan de las de Volta, siendo las de Volta de la siguiente manera.

VoltaSMDiagram.png

El Chip Turing que han presentado esta semana añade los RT Cores, que son las unidades de función fija para calcular la intersección que antes he comentado, mirando las especificaciones técnicas nos damos cuenta que no tienen un rendimiento fijo sino que depende de la cantidad de SM en el sistema. Nvidia no lo ha confirmado pero diría que los RT Cores se encuentran dentro de los SM en el Turing para las Nvidia Quadro.

TuringSM.png

Hemos eliminado las unidades FP64 y a cambio se han añadido los RT Cores, pero se mantienen los Tensor Core por su utilidad en el mercado profesional. ¿Que puede ocurrir con las GeForce? Pues teniendo en cuenta que los Tensor Cores no forman parte de la especificación DXR entonces el cambio en los SM esta bien claro para la GeForce SM.

20x0SM.png

¿A que viene esa contradiccion por mi parte? Información, durante el SIGGRAPH hemos visto como Microsoft ha aclarado la naturaleza del DirectX Raytracing (DXR) y por fin hemos tenido bien claro que para los escenarios de cara a los videojuegos los Tensor Cores no son necesarios y…

Pe, pero Urian… Nvidia ha hecho una presentación en el que han hablado del UE4 Real Time Raytracing… ¿Eso son videojuegos no?

Han hecho una presentación de las Quadro que son tarjetas profesionales y no de las GeForce y la han hecho en el SIGGRAPH que NO es una feria para videojuegos. En realidad todo esto se intuía cuando la propia Nvidia informo que las funciones de los Tensor Cores via Gameworks se encontraban fuera de la especificación para ciertas funciones pero ahora Microsoft nos lo ha re-confirmado definitivamente por lo que ahora tenemos las ideas completamente claras sobre el tema y si que aparece la posibilidad de las nuevas GeForce, al menos en la gama alta.

¿Y que hay de la gama media?

Nvidia tiene que tirar del proceso 16FF mejorado (llamado 12FF) por un motivo bien simple, todos los slots de fabricacion de TSMC para los 7nm están ocupados por Apple y otros fabricantes de móviles durante los próximos meses. Eso deja los slots para las GPUs a 7FF ciertamente limitados y entre ellos esto a afectado a Turing que va a ser lanzada como arquitectura en la gama alta doméstica seguramente con el chip GT104.

Pero la gama media correspondería al chip GT106, la versión para 192 bits GDDR6 de la GT104 y muy posiblemente con el 50% de las unidades CUDA de la GT104 (1536), dicho chip Nvidia se lo esta guardando para no se sabe cuando pero diría que tiene todos los números de ser la primera GPU fabricada bajo el proceso 7FF de Nvidia. ¿El motivo? Tiene más sentido probar los nuevos nodos de fabricación con chips pequeños. ¿Lo particular? Los 7FF permiten una densidad más alta, por lo que es posible que veamos una configuración no de 1536 núcleos CUDA sino de 2304 núcleos CUDA. ¿Para finales de este año? No lo sabemos, pero pese a los 7FF será menos potente que la GT104.

Por otro lado el tema de la GDDR6 por el momento es polémico. la GDDR6 es una memoria muy nueva y sus costes de fabricación deberían ser mucho más bajas que las de la HBM2. ¿Entonces como se explican los altos precios de las Quadro? Pues porque en el mercado profesional se marcan esos márgenes muy altos que van a servir además para pagar la infraestructura de la GDDR6, a medida que vayan apareciendo productos en el mercado. Pero hay un motivo por el cual Nvidia va a lanzar la GT106 bajo el proceso de 7FF que es la GPU AMD Navi que AMD situara en la gama media cuando sea lanzada el año que viene, de la misma manera que la RX 480/Polaris la situaron en la misma gama. Nvidia en estos momentos tiene un dominio absoluto de la gama media donde AMD ha sido cuasi borrada del mapa.

La idea de sabotear Navi con una GT106 a 7FF no es descabellada en absoluto, ahora bien, como he comentado antes tanto AMD como Nvidia de momento no pueden fabricar GPUs a 7FF porque TSMC tiene sus cadenas de producción de chips ocupadas para otros clientes, precisamente para los fabricantes de smartphones que tienen chips pequeños y son los ideales para probar un nuevo nodo e ir escalando. AMD como los slots en la cadena de montaje son limitados han decidido ir con Vega 20 que es supuestamente para la gama profesional. Nvidia por el momento ha pasado y es muy posible que pase del proceso de 7FF en la GT104/2080 porque la cantidad de chips que conseguirían sería más bajo que la demanda que esperan tener.

Por otro lado, el lanzar una GPU basada en el Raytracing contra otra que no lo soporta es un impacto de marketing bastante grande. Para toda la gama GeForce 20×0 los juegos tienen que tener soporte para el Raytracing, por suerte con el Raytracing híbrido no se han de volver a re-programar los juegos de nuevo pero si hacerles algunos retoques. ¿Vamos a ver para PC o más bien para DXR versiones de juegos ya existentes y parcheadas para DXR y por tanto para el pipeline híbrido? Pues yo creo que si y eso va a pesar muy negativamente en contra de AMD a nivel de PC al menos el año que viene. AMD piensa cogerle ventaja a Nvidia en a gama media utilizando el proceso de 7FF, les han revelado sus planes delante de todo el mundo y AMD tomara ventaja de ello.

El DXR trastoca hasta a las consolas

Microsoft no perdera la oportunidad de colocar el DXR como API natural en Xbox Scarlett… ¿El problema? Dependen de AMD que no tiene la tecnología desarrollada por lo que es muy posible que hayan hecho una joint venture en la que AMD va a integrar los RT Cores en las Compute Units de la GPU de Scarlett en un cambio muy parecido al de Nvidia (Las CU son el equivalente a las SM). ¿Y que hay de Sony? Pues…

tobey-maguire-crying

Pero eso es otra historia que no tiene nada que ver con esta entrada y que ya comentare en una entrada aparte.