Blog Personal.

Uncategorized

PS5 y XSX: Rasterizado por Tiles

Uno de los cambios que no se han comentado en los foros, artículos y demás medios de la generación actual a la siguiente son los cambios en la unidad de rasterizado que AMD en PC realizo con las AMD Radeon Vega en su día aunque previamente implementados por Nvidia en su arquitectura Maxwell, me estoy refiriendo al rasterizado por tiles, el cual no se debe confundir con el Tile Rendering.

Pero antes de nada tenemos que saber cual es el problema que soluciona dicho planteamiento y voy a ser lo más conciso y claro en este aspecto. Las GPUs antes del rasterizado por Tiles renderizaban los triángulos de la escena en sus diferentes etapas del pipeline gráfico sin tener en cuenta cual es su posición de pantalla y solamente los ordenaban en la étapa de texturizado, a este planteamiento se le llama Last Sort.

El problema de esto es que la unidad de rasterizado envia triangulos convertidos en fragmentos de manera indiscriminada a los Pixel/Fragment Shaders que son la étapa que más nivel de procesamiento necesita de todas.

¿Y cual es el problema? Pues como los triangulos/fragmentos de la escena no están ordenados según su posición de pantalla se acaba provocando un efecto que es el overdraw, es decir, que se pinten diferentes pixeles en una misma posición, para ello antes de hablar de lo que aporta el cambio de planteamiento en la unidad de rasterizado voy a rescatar un clásico del antiguo blog y ponerlo al día.

#1 El Overdraw y Solución

La forma ideal de renderizar una escena es hacerlo de delante hacía atrás y descartar los polígonos que se encuentran detrás de los que ya tenemos en pantalla y son opacados por los que está por delante. ¿Pero que ocurre cuando no tenemos ordenados los diferentes fragmentos que componen la escena? Pues que la unidad de rasterizado va a rasterizar toda la geometria que le llegue del pipeline geométrico sin cesar y la va a enviar a los Pixel/Fragment Shaders sin control alguno.

Normalmente calculamos las escenas en teoría como si el overdraw no existiese y desgraciadamente existe. La gente confunde el overdraw con los pasos múltiples por pixel visible para hacer ciertos efectos pero el overdraw va sobre calcular los pixeles no visibles en una misma posición.

¿Pero como medimos el impacto del overdraw realmente?

Hemos de tener en cuenta lo que llamamos serie harmónica en matemáticas.

H(n)=1+1/2+1/3+1/4… 1/n

La logica detrás de esto es que el primer polígono en la misma posición se dibuja durante el primer dibujado de la escena, el segundo en el segundo paso pero tiene un 50% de posibilidades de tenerse que dibujar, el tercer polígono tiene 1/3 de posibilidades de existir…

Al final esto no es más que una  Constante de Euler-Mascheroni.

limn→∞ H(n) = ln(n) + γ,

Si tenemos «d» polígonos cubriendo un pixel entonces la cosa se convierte en:

limn→∞ O(d) = ln(n) + γ

Dado que es la seríe harmónica entonces dependiendo del nivel de overdraw en la escena incluso teniendo la misma carga teórica por pixel la carga en el ancho de banda primero y en la computación después crecerá como la gráfica de la serie harmónica que es la siguiente:

¿Y cual es el número de d? No olvidemos que el búfer Z almacena la posición de los pixeles según la profundidad y hoy en día es de 24 bits por lo que el valor máximo teórico sería 2^24, obviamente esto es un limite teórico nada realista pero el nivel de overdraw dependerá de cada juego y de la cantidad de elementos en escena pero es un factor variable dependiendo no solo de cada motor gráfico, ni tan siquiera de cada juego sino a nivel de cada escena porque cada juego puede diferentes escenas con un nivel de overdraw distinto. ¿Y cual es el valor de d ideal Pues 1, porque si es 1 esto significa que todos los pixeles no visibles por el espectador no se renderizan.

Por otro lado no podemos confundir el Overdraw con el multitexturizado, el multitexturizado es el hecho de realizar varias operaciones concatenadas o no sobre cada uno de los pixeles de un búfer de imagen y no olvidemos que hay casos como el renderizado en diferido donde se trabaja con varios búfers de imagen. Es importante tener en cuenta dicha diferenciaciación antes de irnos directamente a los cálculos.

¿Que limitación tiene esto? Pues lo tiene con los elementos que son transparentes o semi-transparentes, para ello es importante colocar un tag en cada poligono que es enviado a la unidad de rasterizado para marcarle que es transparente y que actua en consecuencia,si lo es entonces el pixel que esta detrás será el que se tomara como referencia para eliminar los pixeles posteriores a este pero habrá un overdraw con valor 2.

Pe… pero Urian, ya existén tecnicas para eso.

Si, es cierto, pero la forma más eficiente de hacerlo es la de los Tile Renderers y Nvidia primero y después AMD decidieron pasar a la configuración Middle Sort de estos que consiste en ordenar la geometría antes del rasterizado, pero no para renderizar al estilo Tile Renderer pero si para ordenar por Tiles antes del rasterizado, esto le permite a la unidad de rasterizado realizar lo que es el HSR (Hidden Surface Removal) y retirar por completo los pixeles de los objetos no visibles en la escena, provocando que haya menos overdraw disminuyendo la carga de los Pixel/Fragment Shaders para conseguir la misma escena.

Esto lo hace el hardware automáticamente, pero no se debe confundir con el Culling de la geometría, en este caso la eliminación de los pixeles que no son realmente visibles en el fotograma se realiza después del rasterizado y por tanto se trabaja con fragmentos y no con la geometría, por lo que son dos casos distintos pero que ayudan al rendimiento global del sistema eliminando durante el proceso elementos superfluos cuyo procesamiento no aporta nada a la escena.

Todo esto además aporta dos ventajas importantes que antes no eran posibles:

  1. El trazado de rayos requiere hacer un mapa de la geometría en una estructura de datos espacial en forma de árbol. Gracias a que la geometría de la escena es ordenada antes del rasterizado en el planteamiento middle sort dicha estructura de datos es formado, la cual es necesaria para poder saber el recorrido de los rayos en la escena y con que objetos «impactan» los rayos y con cuales no, por lo que este cambio en el hardware era necesario hacerlo de cara a la implementación eventual del trazado de rayos o más bien la transición hacía este que es lo que estamos viviendo en estos momentos.
  2. El problema del overdraw es que cada pixel que sea calculado por el pixel/fragment shader va a ser enviado por los ROPS a la memoria a la que este conectado, en la generacion actual de consolas los ROPS/RBE se encuentran cableados a controlador de memoria y acaban requiriendo un ancho de banda brutal ya que cada pixel incluidos los no visibles se escriben continuamente en el búfer de imagen, reduciendo el valor de d a 1 o cercano a 1 el impacto sobre el ancho de banda disminuye.

Es por ello que

0 0 vote
Article Rating
1 Comment
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Big crunch

Vaya, así que por fin han solucionado el viejo problema de la vegetación (texturas alfa) destruyendo el rendimiento desde far cry 1 en bosques y selvas.