Blog Personal.

Uncategorized

Xbox Series X (II): RAM y Almacenamiento (Cont)

Ya os dije que tuvierais paciencia conmigo y he de agradecer a Nitupensis por el tirón de orejas ya que ayer cuando hice la entrada anterior no había visto la siguiente imagen.

Nitupensis nos recuerda que es una unidad del tipo m.2 2230, la cual sabemos que esta conectada via PCI Express. Este tipo de tarjetas utilizan 2 lineas PCI Express para comunicarse, hemos de recordar que el IO Hub de AMD asigna hasta unas 4 lineas PCI Express, por lo que asignaría unas 2 lineas al SSD externo y 2 lineas al SSD interno.

Y ya que hablamos del almacenamiento, hay una tecnología nueva que no comente que es el Direct Storage. Microsoft oficialmente lo define de la siguiente manera:

DirectStorage es un nuevo sistema de E/S diseñado especificamente para el gaming para sacar todo el rendimiento de la SSD y la descompresión de hardware. Este es uno de los componentes que forman parte de la Xbox Velocity Architecture. Los juegos modernos realizan streaming de assets en segundo plano para cargar continuamente las siguientes partes del mundo en el que juegas y DirectStorage peude reducir la sobrecarga de la CPU para estas operaciones de E/S de necesitar múltiples núcleos a utilizar una pequeña fracción de un sol núcleo. Por lo tanto liberando una potencia considerable de la CPU para que pueda utilizarse en areas como mejores físicas o más NPCs en una escena. El nuevo miembro de la familia DirectX ha sido introducido con Xbox Series y planeamos llevarlo a Windows también.

Cuando hablamos de descomprimir uno datos estamos aplicando un algoritmo que permiten descifrar unos datos de entrada para sacar unos datos de salida. Esto requiere una capacidad de proceso y por tanto si se quiere obtener una velocidad de descompresión en concreto vas a necesitar una mayor potencia.

La idea del hardware con el DirectStorage es que se puedan transmitir lo datos desde el Disco Duro a la suficiente velocidad aunque sean comprimidos con un ratio de 2:1. ¿El motivo? El coste por unidad de almacenamiento del SSD en estos momentos es alto y es además de agradecer que se pueda mantener el ancho de banda que da el PCIe con el SSD sin cuellos de botella en la compresión/descompresión de datos permitiendo la carga instantánea de los datos sin un cuello de botella.

Por regla general las tareas de descompresión se realizan a través de función fija especializada, el motivo de ello es:

  • Consumen una parte minúscula del espacio en comparación con núcleos programables.
  • Su rendimiento es fijo y permite por tanto controlar el tiempo en que tardan en realizar la tarea.

En Xbox One, Microsoft añadio los Move Engines, unidades DMA encargadas de trasladar datos de una banda a la otra, dos de estas unidades tenian una particularidad.

El compresor LZ y el descompresor LZ en Xbox One no funcionan al ratio de los Move Engines… En realidad son mucho más lentos que van a unos 200MB/s de tasa y el decodificador JPEG no va a más de 250MB/s. Por lo que que de haberlos mantenido tal cual hubiesen sido un enorme cuello de botella de cara al streaming de texturas a tiempo real desde la SSD, algo que ya ampliare dentro de esta serie cuando lleguemos a la GPU. Lo que es importante es la utilidad de cara a las instalaciones, en Xbox One cuando se instala un juego se comprime en formato LZ con tal de que no ocupe espacio, la contrapartida de esto es que las instalaciones se hacen eternas por culpa de esto y van a una porción de la velocidad.

La otra utilidad de este cambio es el hecho de pode hacer swapping a tiempo real de las texturas necesarias en cada fotograma y poder aplicar el Virtual Texturing de manera 100% eficiente. En Xbox One ya teniamos las texturas parcialmente residentes que consiste en colocar las texturas no enteras sino en pequeños bloques de 64KB por lo que estas se tenían que subidividir en tiles de este tamaño.

El motivo de ello es que cada página de la memoria virtual soportada por la MMU es de ese tamaño. Es decir, la GPU en Xbox One referencia la memoria a través de su MMU a través de paginas de 64KB cada una. Esto nos permite aplicar el Virtual Texturing que consiste en la idea de que de un fotograma a otro hay pocos o casi ningún cambio en las texturas, por ello se crea un atlas de texturas donde cada tile corresponde a una zona de la pantalla y se reemplazan solo los Tiles necesarios de una textura a otra.

La teoría básica es que si tenemos una imagen de a 4K (3840×2160) podemos almacenar las texturas necesarias para la escena en varios atlas de texturas de 4096×4096 pixeles cada uno. El motivo de que no sea 4096×2048 es que necesitamos almacenar los Mip Maps de cada textura dentro del mismo atlas.

Por lo que con esto podéis pensar… Bueno, puedo tirar con esto del Disco Duro y tomar las texturas. El problema con ello es que los archivos están comprimidos en LZ entonces tienes que tirar de la unidad de decompresión y es demasiado lenta para el Virtual Texturing, esto obliga a que si queremos tener una tasa suficientemente rápida tenemos que tirar de la CPU y en las Xbox One, los Jaguar como que no son muy rápidos que digamos. Al final en Xbox One se tienen que transmitir los datos sin comprimir desde el Disco Duro a la RAM.

Lo que permite es que las texturas se envien con la suficiente velocidad como para realizar el swapping de texturas de un fotograma a otro tomando como origen los discos SSD. En las actuales consolas esto no es posible y pese a que se utiliza el Virtual Texturing la gran mayoría de texturas están en memoria. ¿El motivo? Nunca os ha pasado que un juego en una determinado superficie carga una textura digna de…

Esto es porque en tiempo de fotograma el Disco Duro no ha cargado la textura con la suficiente velocidad y no ha dado tiempo a mostrarla, es por ello que muestra un placeholder de menor calidad. Con los cambios implementados en Xbox Series X esto no debería ocurrir, aparte que permite dejar una parte importante de las texturas en la SSD y no tener que precargarlas en memoria, ahorrando en chips de memoria RAM y haciendo que esos 10GB de almacenamiento para la GPU sean más eficientes.

¿Pero que es lo que ha implementado exactamente Microsoft a nivel de hardware ? Recientemente os comente como Microsoft (y Sony) suelen crear unidades de función fija utilizando la tecnología de sintetización de hardware de Cadence para ello.

¿En que consiste el proceso?

  1. Crean el algoritmo en C o C++
  2. Un compilador especial genera el código VHDL o Verilog del algoritmo en forma diferente soluciones de hardware, los ingenieros escogen el que ven mas adecuado.
  3. Con un FPGA programado con el archivo VHDL o Verilog prueban la solución escogida y su rendimiento.
  4. La solución definitivamente escogida es incoporada como una unidad de función fija en el SoC del sistema.

Todos y cada uno de los aceleradores de las Xbox que ha hecho Microsoft en exclusiva están hechos de esta manera. En realidad lo hacen todos los diseñadores de chips a la hora de diseñar estas unidades de función fija. Utilizar estas herramientas de proveedores como Cadence, Mentor Graphics, Synopsis… Las cuales ahorran tiempo en el diseño de estos componentes de hardware.

El otro tema del que me gustaría hablar es de la contención, especialmente por este comentario de Set.

¿¿El Ancho de banda no esta relacionado a temas de Bus y rops urian??.

Se me viene a la mente el caso tan polemico de la GTx 970 que tenia 4GBVram, pero luego se descubrio que al pasar de 3.5GB de Vram el ancho de banda disminuía drasticamente. Esto me recuerda a esto de la xbox que al pasar de 10gb el ancho disminuye a 336 gb/s.

o es diferente?

El tema del ancho de banda y los ROPS lo comentare cuando lleguemos a la GPU, de lo que me gustaría hablar es de la contencion que se da cuando tienes dos clientes del controlador de memoria.

En los SoC habitualmente todo pasa por un uncore/northbridge común que es el que se encarga de acceder a la RAM para todos sus clientes. Es decir, las peticiones a memoria no la hacen sus clientes sino que el uncore hace de representante con tal de no crear contención. En los SoC para PC de AMD no hay contención por el hecho que hasta la GPU accede a la memoria a través del uncore/Northbridge/Data Fabric

La contrapartida de esto es que limita enormemente el ancho de banda y se requiere construir un uncore/data fabric más grande para ir añadiendo las interfaces Infinity Fabric que son el enchufe con el que los diferentes componentes se comunican con el Northbridge/Uncore/Data Fabric. Esto hace que el tamaño del SoC no solamente aumente con los componentes adicionales más complejos sino también el uncore y cuando tienes un espacio limitado… Pues tienes que tomar una decisión sobre ello.

El problema viene cuando aparte del Northbridge/Uncore/Data Fabric tienes otro cliente para el controlador de memoria, en este caso la GPU que tiene un acceso directo a la RAM. Esto no es nuevo y ya ocurría con las consolas de la actual generacion donde ambas tienen un acceso directo. Lo que yo no me esperaba y seguramente AMD tampoco es este nivel de contención en los nuevos SoC. Microsoft se ha visto forzada a reservar del direccionamiento unos 10GB de memoria solo para la GPU para evitar la contención sin tener que sobrecomplicar el sistema de memoria teniendo que tirar de un complejo sistema de memoria no unificada con dos pozos distintos y el sobrecoste asociado.

Uno puede pensar… ¿A que viene no utilizar DDR4 para la CPU y olvidarse de esto? El motivo de ello es la retrocompatibilidad donde las consolas funcionan en un sistema de memoria unificado. Romperlo es romper la compatibilidad hacía atrás, es por ello que se ven obligados a utilizar un solo pozo de memoria aunque en modo de compatibilidad hacía atrás haya un recorte del rendimiento de la RAM, pero dicho recorte no coloca el ancho de banda por debajo del de la consola original, especialmente en el modo Xbox One X.

La configuración de 320 bits puede parecer extraña de entender a primera vista, pero teniendo en cuenta la contención queda claro el motivo, aunque esto se ve con una tabla.

Si el bus hubiese sido de 256 bits entonces…

Bus Gbps Total Data Fabric Contención GPU
256 12 384 48 192 192
256 14 448 56 224 224
256 16 512 64 256 256

El ancho de banda para la GPU seria menor de los 326 GB/s y en modo Xbox One X esto hubiese sido un problema, en cambio con un bus de 320 bits…

Bus Gbps Total Data Fabric Contención GPU
320 12 480 48 192 288
320 14 560 56 224 336
320 16 640 64 256 384

Los 12Gbps no son suficientes, pero los 14Gbps si para conseguir ese ancho de banda requerido para que el modo Xbox One X funcione sin problemas de rendimiento en la nueva consola.

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

0 0 vote
Article Rating
3 Comments
Oldest
Newest Most Voted
Inline Feedbacks
View all comments
Nitupensis

no se cuanto tendra de cierto, pero lo que están diciendo, aunque la series X mostrada solo tiene chip en un laado del pcb, el pcb esta pensado para permitir el montaje de memorias en clamshell, no se supongo que sera para las unidades para desarrollo que usaran el doble de memoria como pasa en las actuales xdk de microsoft, si me extraña es porque… no seria mas fácil duplicar la densidad de cada chip de memoria, que no montar el doble de chips usando ambos lados del pcb?

Nicco

Supongo que es menos costoso poner chip con más memoria que no poner el doble de chips. Aunque si permiten este montaje puede que sea un as que se guarden por si Sony anuncia que su consola monte más memoria.

[…] ¿Significa esto que la Cache L2 ha de aumentar? No tiene porque y tenemos un precedente de esto en forma de Xbox One X donde el bus es de 384 bits GDDR5 pero la Cache L2 de la GPU es la misma que las AMD Polaris con bus de 256 bits. Es más, ya comente el motivo por el cual Microsoft ha optado por esta configuración y tiene que ver con la … […]