Blog Personal.

Conceptos Básicos

Nanite (UE5), SSD, GPU y desinformadores

He visto un post en NeoGAF que me ha parecido sumamente interesante, pero no por lo bueno sino por lo desinformador que resulta ser y dado que creo que vamos a ver este post siendo citado continuamente he creído que lo mejor es desmontar el nivel de desinformación existente en dicho post.

Va a resultar chocante para algunos y para otros como yo no tanto, debido a que llevo meses diciendolo. Odio tener que desmontaros a algunos de voostors pero el streaming de datos de la demo (del Unreal Engine 5) lo soporta un SSD SATA de hace 5 años.

768MB el requerimiento a la vista en el hardware para poder ejecutar esa demo, 768 MEGABYTES… COMPRIMIDOS. ¿Y cual es el coste de esto en la parte del renderizado?

Esto confirma todo lo que he dicho, no que esos SSD sean inutiles debido a que no los on al 100%. Ese (volumen) de caudal de datos sería imposible con los discos mecanicmos. Sin embargo, y esto es un gran sin embargo. La canidad de datos visuales y el caudal de de assets ya se encuentran provocando un cuello de botella en el renderizador. Esta colocando de rodillas a la PGU. Hay un coste muy pequeño para la CPU como se puede ver abajo, pero como se ha dichjo 100 veces distintas en este sitio web y que ha sido motivo de burla por los detractores: La GPU será siempre el factor delimitante.

He mantenido esto desde la primera casilla. Tanto Microsoft como Sony han ido a lo exagerado con sus SSD. Ese aumento en la E/S no es capaz de alinearse con el pipeline de renderizado (GPU) en terminos de la demanda en el volumen de datos respecto a los que permiten esos SSD.

¿Cual es el punto aquí? Tenemos dos sistemas con SSDs mucho más capaces que su utilidad, per uno de lleos viene con un alto coste en todas las partes del sistema. Os dejo pensar acerca de cual de ellos es y donde.

Toda esta información se refiere a la parte dedicada a la tecnología Nanite en el video de la propia Epic donde dan una explicación detallada del mismo y en que consiste.

En realidad Nanite no es una tecnología sino varias que se agrupan bajo dicho nombre, realice una introducción hace un par de meses con la poca información que teníamos por aquel entonces y creo que es hora de actualizarla y de paso romper las afirmaciones de las que habla el creador del post en NeoGAF, las cuales son puro FUD y no hace falta que digamos de que lado cojea.

Veamos lo que dice primero la diapositiva de la polémica…

Nos dice que el streaming de datos en Nanite corresponde a la actual visión o punto devista… ¿A que se refiere? Pues al hecho que los datos tienen que ver con la perspectiva que tengamos en cada momento de la escena, es decir, con los objetos que vemos con la cámara en ese momento y no toda la escena entera.

Por ejemplo, si tuviesemos un angulo de vision de 90º todo aquello que estuviese fuera del campo de visión no se renderizaría.

Ahora bien… ¿Que es eso del Streaming Pool? Tened en cuenta que desde la GPU no hay acceso directo al SSD de la misma manera que con la GDDR6 y el contenido se ha de copiar a una parte de la GDDR6. Esos 768MB de los que hablan es la cantidad de RAM (GDDR6) que es reservada para hacer de cache del SSD en la RAM misma, por el hecho que ni la GPU ni la CPU acceden al SSD de manera directa ya que este aunque es mucho más rápido que un disco duro mecánico y mejor tiene un ancho de banda que lo hace inutilizable de manera directa.

El proceso de petición de datos es el siguiente:

  • La MMU del procesador en cuestión que requiere el acceso a una dirección de memoria, página o conjunto de páginas del SSD hace una petición al controlador del SSD.
  • El controlador del SSD los busca en los chips de memoria del SSD y una vez ha encontrado el dato lo copia en la RAM.
  • En medio del proceso de copia puede haber un proceso de descompresión de los datos al vuelo.

Lo que se hace normalmente es tomar no los datos de una dirección de memoria en concreto sino de una página de memoria e incluso de una Page Table o más si es necesario. Cuando la MMU de la CPU, la GPUMMU de la GPU o el IOMMU hacen una petición a memoria, según cual sea la dirección de memoria lo buscará en todo el espacio de la RAM o en el espacio de la RAM asignado a la cache del SSD. ¿El motivo? Cada una de las MMU sabe en que dirección de memoria física acaba la RAM y empieza el SSD, pero primero antes de realizar la petición al SSD comprobara si ese dato se encuentra en la parte de la RAM asignada como cache para el SSD y si no lo encuentra realizará el proceso de petición de datos para copiarlo en la RAM.

Ahora bien, ese pozo de 768MB no se actualiza en cada fotograma, para que se actualizará en cada fotograma necesitaríamos como mínimo un ancho de banda entre el SSD y la RAM de unos 23GB/s de ancho de banda total para actualizar todos los datos con el juego funcionando a unos 30 fotogramas por segundo y la solución en cuanto al SSD más rápida que es PlayStation 5 no llega a esa velocidad. ¿Pero que se almacenan en esos 768MB? Pues se almacena la geometría, la cual esta ordenada en la escena según su posición en la escena. Esto impica que se encuentra en una estructura de datos que no se puede modificar, pensad en ello en el mismo concepto que las Virtual Textures pero con la geometría. El hecho de que por el momento Nanite funcione con geometría estática lo deja muy claro Epic en la presentación.

Es decir, por el momento no se puede utilizar Nanite para geometría dinámica y por tanto deformable ya que esto significaría tener que actualizar la estructura de datos donde esta almacenada dicha geometría en la escena (posiblemente un BVH) ye eso es un proceso muy pero que muy lento.

Hay que tener en cuenta además que Nanite soporta LODs dinámicos de los diferentes objetos, cada objeto tiene una ID asociada así como los diferentes niveles de detalle. El caso es que el motor si tiene que renderizar un objeto fijo con el mismo nivel de detalle que otro que esta ya en memoria simplemente lo copia y no tiene que volver a calcular la geometría y a eso se le llama instanciación. Y es un truco utilizado en muchos juegos desde ya la generación de PS2/GCN/Xbox, tradicionalmente no esta limitado solo a objetos estáticos en general sino también a objetos dinámicos pero no es el caso de Nanite y el motivo de ello es el tiempo de actualización del BVH para objetos estáticos.

si le haceis un vistazo a la arquitectura del nivel de la demo veréis que los objetos se repiten de manera recursiva en la arquitectura del nivel de la demo.

El motivo de que la geometría es estática y no puede ser cambiada es por el hecho de que para el rendimiento es sumamente importante no tener que actualizar el BVH para los objetos estáticos de la escena. Según Epic más del 90% de la geometría en los juegos es estática y por tanto no sufrirá ninguna modificación en su naturaleza de un fotograma a otro. Esto le permite al sistema tener la geometría ordenada en un BVH enorme para la escena que mantiene en el SSD y con ello lo tiene fácil para tomar la geometría estática necesaria en cada momento.

¿Y que ocurre con la geometría dinámica? Tienen su propio BVH y se renderizan en paralelo pero no entran dentro de Nanite debido a que hacer algo como Nanite para la geometría dinámica sería sumamente complejo de realizar y es algo que esta fuera del alcance de la tecnología actual.

En el video de Epic además afirman que 1 millón de polígonos ocupan lo mismo que una textura de resolución 4K (4096*4096) de mapas de normales. Este tipo de texturas en memoria (debido a la compresión) suelen ocupan unos 0.5 bytes/pixel por lo que si hacemos el calculo rápido entonces 8MB= 1 millón de polígonos y por tanto Nanite almacena una escena de 96 millones de polígonos por fotograma (768/8).

Esto significa que la GPU ha de poder rasterizar esa cantidad de polígonos a través de sus unidades de rasterizado que es el paso entre la geometria y la rasterización. Tanto Xbox Series X como PlayStation 5 tienen GPUs que pueden rasterizar hasta 4 triángulos por ciclo a tiempo real. Xbox Series X por ejemplo puede rasterizar unos 7300 millones de triangulos/s. A una velocidad de 30 fps esto son 243 millones de triangulos/frame, a unos 60 fps son unos 121 millones/frame. Nanite toma unos 96 millones, pero es que hay que tener en cuenta que esos 96 millones solo son geometría estática y no se tienen en cuenta los objetos dinámicos en la escena, los cuales quedan fuera de Nanite y se procesan de forma normal.

La otra diapositiva es la de los 4.5 ms…

El G-Buffer es la primera etapa del renderizado en diferido, el renderizado en diferido lleva utilizandose desde la generación PS3/360 y la idea consiste en aplazar o posponer la mayor parte del renderizado pesado (como la iluminación) a una etapa posterior. El sombreado diferido consta de dos pasadas: en la primera pasada, llamada pasada de geometría, renderizamos la escena una vez y recuperamos todo tipo de información geométrica de los objetos que almacenamos en una colección de texturas llamada G-buffer; información como los vectores de posición, vectores de color, vectores normales y / o valores especulares. La información geométrica de una escena almacenada en el G-buffer se usa luego para cálculos de iluminación (más complejos) que se realizan en una étapa posterior.

Es decir, lo que nos dice la presentación es que generar el G-Buffer para toda la información de la escena toma unos 4.5ms, a esto se le ha de añadir el tiempo de calcular la iluminación de la escena y otros elementos del renderizado que vienen después que no discuten en esa parte de la presentación y de los que no vamos a entrar en esta entrada.

¿Y que tiene que ver todo esto con lo del SSD? Nada, absolutamente nada… Bueno si, que Nanite no sería posible bajo el mismo rendimiento bajo un disco duro mecánico. Pero creo que con esta explicación es suficiente para enviar ese post lleno de desinformación directamente a la papelera de la historia.

Y una cosa, eso de que la GPU no puede gestionar los datos del SSD es un sinsentido enorme, estamos hablando de procesadores que están acostumbrados a gestionar centenares de Gigabytes/s sin problemas e internamente e incluso Terabytes/s… ¿Y me tengo que creer que se ahogan con el ancho de banda de un SSD PCIe? Es que lo peor de todo es que ni tan siquiera utilizan el SSD de manera directa como memoria como ya os he comentado antes.

Las GPUs en general, tanto discretas como integradas, nunca se diseñan de cara a tener en cuenta la latencia del almacenamiento masivo y bien que en los SSD resulta en una enorme mejora respecto al disco mecánico, pero hay que tener en cuenta que todo deriva del PC donde nadie compra tarjetas gráficas con un SSD integrado y por tanto las GPUs no están realmente optimizadas para el uso del SSD como memoria directa claro esta porque su ancho de banda es demasiado bajo como para poderse utilizar.

Las Compute Units de las GPUs pueden paliar la latencia con el método Round-Robin que consiste en que si una instrucción no tiene su dato correspondiente y por tanto no se soluciona en x ciclos entonces la envía atrás en la lista. Esto significa que si los datos están en los registros entonces se solventa la instrucción pero si no lo están y los datos no llegan suficientemente rápidos entonces la unidad SIMD se queda una eternidad intentando procesar una ola determinada debido a que se pasa una eternidad esperando a los datos afectando a datos posteriores a procesar. Cuando la Compute Unit necesita acceder a un dato que no esta en sus registros realiza un viaje buscando estos en toda la jerarquia, pero si el dato se encuentra más allá de la RAM entonces la latencia es mayor por el proceso derivado.

La idea del SSD es con el intercambio de datos entre el SSD y la RAM tener un pozo de RAM cuasi infinito, pero el método no es tan fácil como un chasquido de dedos a la hora de realizar ese intercambio de datos. El cual han conseguido que sea transparente de cara al desarrollador y que no se tenga que manejar de manera maual, lo cual es de agradecer. Pero de cara a la latencia, esta es inevitable y acaba afectando al rendimiento ya que lo ideal sería tener una memoria con el ancho de banda de la GDDR6 y la densidad de un SSD pero eso no existe. En todo caso el mecanismo de captación de datos del SSD de adelanta a la ejecución y busca los datos de antemano para copiarlos en el espacio de la GDDR6 por lo que nunca ocurre que la GPU accede al SSD de manera directa.

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

5 3 votes
Article Rating
2 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Steven

Hola sería como diferentes búfer así entiendo y una parte que elimina polígonos no visible

Drakengard

Ps5 farà la differenza è tu non hai ancora capito ssd Ps5 se credi xbox xerie x possa uguagliarlo.
La gpu Ps5 non è veloce per niente.
Tutto serve sia veloce con un ssd veloce.