Blog Personal.

PlayStation 5, PS5, Xbox Series X, XSX

PS5 y XSX: Streaming de Texturas.

La idea básica de cualquier sistema de streaming de texturas desde el almacenamiento masivo (como el Virtual Texturing por ejemplo) es que solo necesitas un solo texel de datos de texturas por cada pixel en pantalla (si el filtraje no es tenido en cuenta). Así que si tienes el más optimo sistema de streaming, solo vas a necesitas una textura de la resolución de pantalla.

Si quieres reproducir a 4K que son 3840*2160 te va a bastar con un textura de 4096*2048 pixeles para tener toda la información en pantalla, menos de 32MB de datos dependiendo del formato de texturas que utilices. El problema es que mantener un solo texel por pixel en pantalla no es posible cuando se retransmiten los datos desde un disco óptico o desde un disco duro normal, los enormes tiempos de búsqueda hacen que se acabe optando por reducir las búsquedas haciendo peticiones a bloques de datos enteros. Fue a partir de la actual generación que se implemento en las unidades de manejo de memoria de las GPUs el uso de memoria virtual y la visión de la memoria por paginación.

La manera tradicional de acceder a la memoria es que esta se organiza como una tabla con celdas donde la mitad de la dirección de memoria corresponde a la columna correspondiente y la otra mitad a la fila:

En la memoria virtual por paginación no tenemos una sola tabla sino varias tablas ordenadas siendo cada una de una página. En las GPUs de AMD desde la salida de la arquitectura GCN se implementaron las texturas parcialmente residentes cuya base es la de subdividir las texturas en bloques de 64KB y acceder a cada uno de estos bloques de manera directa.

Cuando se requiere un pixel, en vez de cargarse de manera unitaria con tal de reducir la cantidad de accesos y las búsquedas acumuladas se carga todo el tile entero, dado que es habitual necesitar los texeles alrededor de otro texek y estos se encuentran asociados a los objetos en pantalla, es completamente lógico cargar con todo el paquete de texeles que se encuentran en la misma página, sobretodo de cada a reducir las búsquedas.

El problema que tienen las GPUs es con el acceso a memoria, los shaders utilizan el metodo Round-Robin de hacer rotar las instrucciones que carecen del dato para ganar velocidad y no estar paradas. Pero si aumentamos enormemente la cantidad de accesos a memoria entonces tanto la MMU como el controlador de memoria se saturan ante tal cacofonía de peticiones, no solo eso sino que en un formato de medio giratorio como un disco duro convencional los tiempos de espera se acumulan uno tras otro y el tiempo acumulado convierte en inutilizable el Virtual Texturing.

Es por ello que entre otras cosas, la reducción a 0 de los tiempos de búsqueda del SSD es cuanto menos uno de las mejoras más importantes en comparación con el Disco Duro.

Volviendo al tamaño de la textura necesaria para tener toda la informacion en pantalla, no nos basta con unos 4096×2048, el motivo de ello es que necesitamos almacenar todos los Mapas Mip de la textura.

En las texturas de los gráficos 3D por computadora, los mapas MIP (comúnmente llamados mipmaps), son colecciones de imágenes de mapas de bits que acompañan a una textura principal para aumentar la velocidad de renderizado y reducir sus artefactos.

Cada imagen de mapa de bits del conjunto es una versión reducida de la textura principal. El renderizador utiliza la textura principal cuando se renderiza a todo detalle, y cambia al mipmap adecuado cuando renderiza la textura desde cierta distancia o en un tamaño menor. 

Por ejemplo, si la textura principal tiene un tamaño de 256 por 256 píxeles (típicamente las texturas son cuadradas y el largo de su lado es una potencia de dos), el conjunto de mipmaps asociados podría ser de ocho imágenes, cada una de un cuarto del tamaño de la anterior: 128×128 pixels, 64×64, 32×32, 16×16, 8×8, 4×4, 2×2, 1×1 (un único píxel).

El espacio de almacenamiento necesario para estos mipmaps es de un tercio más que el de la textura original, porque la suma de estas áreas 1/4 + 1/16 + 1/64 + 1/256 + … converge a 1/3 (asumiendo que no se hace ningún tipo de compresión).

Es decir, el tamaño sería de (4096*2048*4/3) en total pero dado que las texturas utilizan potencias de 2 hemos pasado de tener un mapa de 4096*2048 a tener uno de 4096*4096. Pero este no es el único problema, hay otra que nos va exigir una textura para almacenar todas las texturas de la escena mucho mayor.

Para hacerlo bien simple, supongamos que el campo de visión que te da la cámara del juego es de 90º de la visión completa de 390º.

Por lo tenemos 4 vistas completas (360º/90º) que almacenar para evitar que un giro de cámara retrase el sistema. Nuestra textura que almacena todas las texturas ha pasado a ser una de 8192*8192 pixeles en total, es decir, unos 64 millones de pixeles.

Pero alto, nos falta algo… Los texeles carecen de color.

Dado que todas las GPUs se piensan principalmente para la API mayoritaria que es Direct3D, todos ellos tienen soporte por hardware para la compresion/descompresión en bloque o mejor dicho de bloques de texeles, a estos se le llama formatos BCn y funcionan con bloques de 4×4 texeles, teniendo cada bloque un tamaño máximo de 16 bytes. Esto se traduce en 1 byte por texel y por tanto solo necesitaremos almacenar un atlas de 64MB de tamaño para almacenar todas las texturas necesarias para el fotograma actual, lo que teniendo en cuenta que el tamaño por página de texturas es de 64KB esto son un total de 1000 páginas de texturas a la que acceder por segundo en el caso de que se necesite cambiar toda la informacion del atlas de texturas.

En realidad en un juego en 3D y dentro de una misma zona es muy difícil que se hagá el cambio repentino de todas las texturas de golpe sino que de un fotograma a otro la cantidad de texturas que cambían es muy poca. Pero claro, con un disco duro convencional cuando necesitamos cambiar todas las texturas de golpe de una escena es normal que hayan tiempos de carga.

En realidad aunque el Virtual Texturing suene muy bien, por motivos de rendimiento se suelen almacenar todas las texturas necesarias en todo el nivel en memoria o incluso de todo el juego. La idea es que si tenemos una comunicación con el sistema de almacenamiento masivo lo suficientemente rápida como para cambiar las texturas al vuelo no necesitamos ingentes cantidades de RAM para almacenarlas y podemos almacenarlas en un disco SSD y copiarlas a la memoria principal solo cuando son necesarias y si se puede hacer a tiempo de fotograma mejor que mejor.

El HBCC 2.0

El HBCC es una mejora que implemento AMD en las AMD Vega para PC y cuya particularidad es que le permite a la GPU acceder a cualquier dispositivo PCIe conectado al sistema, obviamente desde entonces AMD ha mejorado el funcionamiento de este.

Una GPU tiene en realidad dos unidades MMU distintas que puede utilizar.

  • IOMMU: Esta MMU se utiliza cuando necesitamos acceder al Northbridge/Data Fabric para comunicarnos con la CPU, el espacio de la RAM de la CPU (accediendo a través del UMC) y con los periféricos, por lo que va a ser utilizado para acceder al SSD.
  • GPUMMU: Esta MMU es utilizada cuando necesitamos acceder de manera directa a la memoria sin pasar por el Northbridge/Data Fabric por lo que la visión de la memoria en principio no es coherente.

Una de las cosas que AMD ha incluido en PS5 y no sabemos si en Xbox Series X también es el Coherency Engine, esto es importante porque le permite acceder a la GPU a ambos espacios de memoria de manera directa sin tener que mover datos de un espacio a otro a través de la GPUMMU, es decir, deja de ser necesario copiar del espacio visto por la IOMMU al de la GPUMMU ahorrando ciclos moviendo datos de un espacio de memoria a otro ya que toda la visión del espacio de memoria se unifica al ser 100% coherente.

El HBCC lo que hace es colocar dentro del espacio de memoria de la GPU el direccionamiento hacía el SSD de tal manera que de cara a la GPU todo el proceso se automatiza. No necesitamos decirle que vuelque los datos de la memoria SSD a la RAM, simplemente el mecanismo incorporado hace todo el trabajo sin que los desarrolladores se tengan que preocupar en programar el streaming de texturas desde el SSD ya que lo hace automaticamente y con ello lo hace compatible con todos los juegos.

Esto hace que no necesitemos una cantidad ingente memoria para texturas y los fabricantes de consolas, puedan reemplazar GB adicionales por una mayor cantidad de memoria en SSD y virtualmente tener una cantidad de texturas disponibles en el juego y una mayor variedad.

Esto es todo, tenéis el Discord y los comentarios de esta entrada para comentarla.

0 0 vote
Article Rating
4 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Snake128

Muy interesante, entiendo que es difícil explicar esto en ejemplos, pero no estaría de más.

Para mí este es el gran avance, imaginaos que puedes ir cambiando estas texturas casi al vuelo, lo que pued hacer que todas ellas sean a la máxima calidad y puedas tener menos texturas en ram, pero más detalladas.

Set

Fue el problema que tuvo Carmack con el juego Rage haya por el 2010, con la Megatexturas, el hardware no estaba preparado para el streaming de texturas y paso esto:
https://youtu.be/I1k_Dv46bBw
Supungo que esto en PC no sera problema por la RAM y Vram en grandes cantidades, no hay necesidad de hacer el streaming desde SSD.

Pero me queda una duda, que solucion uso Microsoft con dx11.1?? los Tile resoucer se aplica en juegos pasados como gear of war 4 , y el juego no tenia poping, una implementacion mixta y no 100% streming?

nolgan

que velocidad de SSD nesesitas para lo ultimo que comnetas?? teniendo en cuenta lo 2,5gb a 4,8bgb usando el compresor de xsx, y ps5 sus 5,5gb y 9gb usando el kraken

creo que sp5 si puede ya que desde dev han comentado eso que dices, y que ps5 soporta de sobras texturas 4096*4096 sin problemas…, segun comnetarios de varios dev…

pero XSX??? me imagino que si.. no? o tendran que usar mas pequeñas? o algun truco?

Dani

Bueno, la Xbox Series X será capaz de transferir a memoria 2 GB de datos en 0,75 segundos, seguro que es suficiente.

Por otra parte, relacioné el Sampler Feedback Streaming de la Xbox Velocity Architecture con lo que dijo Cerny del Coherency Engine. Creo que es lo mismo, pero no estoy seguro.